Best o f

E Y R O L L E S

GEORGES GARDARI N

Bases de
donnes

Best o f
E Y R O L L E S

Bases de donnes
La rfrence en langue franaise
sur les bases de donnes

Les bases de donnes jouent un rle sans cesse croissant dans les
systmes dinformation dentreprise, quil sagisse dapplications de
gestion traditionnelles (comptabilit, ventes, dcisionnel) ou dapplications intranet, e-commerce ou de gestion de la relation client.
Comprendre les principes des bases de donnes, les langages dinterrogation et de mise jour, les techniques doptimisation et de contrle
des requtes, les mthodes de conception et la gestion des transactions devient une ncessit pour tous les professionnels et futurs
professionnels de linformatique.
Complet et didactique, louvrage se caractrise par des dfinitions
prcises des concepts, une approche clairante des algorithmes et
mthodes, de nombreux exemples dapplication, une bibliographie
commente en fin de chaque chapitre et un recueil dexercices en fin
douvrage. Il traite aussi bien des bases de donnes relationnelles, que
des bases de donnes objet et objet-relationnelles.

Georges Gardarin
Chercheur renomm
dans le domaine des bases
de donnes et professeur
luniversit Paris 6 puis
luniversit de Versailles
Saint-Quentin, Georges Gardarin
a cr et dirig successivement
un projet de recherche INRIA
sur les BD relationnelles
parallles (1980-89),
le laboratoire PRiSM de Versailles
(1990-99), qui regroupe
une centaine de spcialistes
en rseaux, bases de donnes
et paralllisme, et enfin la socit
e-XMLmedia (2000-2002),
diteur de composants XML.
Il est aujourdhui professeur
luniversit de Versailles
et participe des projets
de recherche europens
en mdiation de donnes
htrognes.

Les fondements. Principes et architecture des SGBD (systmes de gestion de bases de donnes) Fichiers, hachage et indexation Bases de
donnes rseau et hirarchiques Logique et bases de donnes. Bases
de donnes relationnelles. Le modle relationnel : rgles dintgrit
et algbre relationnelle Le langage SQL2 Contraintes dintgrit et
dclencheurs Gestion des vues Optimisation des requtes. Bases de
donnes objet et objet-relationnelles. Le modle objet et la persistance des objets Le standard de lOMG : ODL, OQL et OML Lobjetrelationnel et SQL3 Optimisation des requtes objet. Au-del du
SGBD. Bases de donnes dductives Gestion des transactions
Conception des bases de donnes : schmas conceptuel et logique
avec UML, dpendances fonctionnelles, formes normales Bases de
donnes et dcisonnel, Web et bases de donnes, bases de donnes
multimdias.

Conception Nord Compo

Au sommaire

Code diteur : G11281

ISBN : 2-212-11281-5

Bases
de donnes

Bases
de donnes

Georges Gardarin

5e tirage 2003

EYROLLES

EDITIONS EYROLLES
61, bd, Saint-Germain
75240 Paris cedex 05
www.editions-eyrolles.com

Cet ouvrage a fait lobjet dun reconditionnement loccasion

de son 5e tirage (format semi-poche et nouvelle couverture).
Le texte de louvrage reste inchang par rapport aux tirages prcdents.

En application de la loi du 11 mars 1957, il est interdit de reproduire intgralement ou

partiellement le prsent ouvrage, sur quelque support que ce soit, sans autorisation de lditeur ou du
Centre Franais dExploitation du Droit de Copie, 20, rue des Grands-Augustins, 75006 Paris.

Groupe Eyrolles 1999

Groupe Eyrolles 2003, pour la nouvelle prsentation, ISBN 2-212-11281-5

 ma petite fille, Marie, ne la fin de la gestation de ce livre,

avec lespoir que les Bases de Donnes laideront mieux vivre et comprendre.

REMERCIEMENTS
Je tiens exprimer mes vifs remerciements tous ceux qui, par leurs travaux, leurs
ides, leurs prsentations, leurs collaborations ou leurs relectures, ont particip de prs
ou de loin la ralisation de cet ouvrage, en particulier :
Catherine Blirando, Christophe Bobineau, Luc Bouganim, Mokrane Bouzeghoub,
Tatiana Chan, Jean-Luc Darroux, Thierry Delot, Franoise Fabret, Batrice Finance,
Dana Florescu, lisabeth Mtais, Philippe Pucheral, Fei Sha, ric Simon, Tuyet Tram
Dang Ngoc, Patrick Valduriez, Yann Vimont, Fei Wu, Karine Zeitouni.
Une mention particulire Hlne qui ma support pendant tous ces nombreux
week-ends et vacances passs rdiger.

AVANT-PROPOS
Jai commenc travailler dans le domaine des bases de donnes en 1968 luniversit de Paris VI (non, pas en lanant des pavs), alors que le modle rseau pointait
derrire les fichiers squentiels puis indexs. Sous la direction de Michel Rocher qui
fut plus tard directeur dOracle France, avec Mireille Jouve, Christine Parent, Richard
Gomez, Stefano Spaccapietra et quelques autres, nous avions dvelopp une famille
de Systmes de Fichiers pour Apprendre Les Autres : les SFALA. Nous enseignions
essentiellement les mthodes daccs squentielles, indexes, haches, et surtout le
systme. Bientt (en 1972), nous avons introduit les Systmes de Donnes pour
Apprendre Les Autres (SDALA). Il y eut un SDALA bas sur le modle rseau, puis
bientt un bas sur le modle relationnel. Aujourdhui, on pourrait faire un SDALA
objet, multimdia, et bientt semi-structur...
Le premier systme de gestion de donnes que jai construit lHopital Necker grait
un disque SAGEM ttes fixes de 256 K octets ! Ceci me semblait norme par rapport au 8 K de mmoire. Le systme grait les dossiers des malades avec des fichiers
hachs. Ctait en 1969 alors que jtais encore lve lENSET et stagiaire TITN.
Le deuxime le fut OrdoProcesseurs, une socit franaise qui vendait des miniordinateurs franais. Ctait en 1974 et les disques atteignaient dj 10 mga-octets.
Le troisime le fut lINRIA au dbut des annes 1980 : ctait lun des trop rares
systmes relationnels franais commercialiss, le SGBD SABRE. Les disques dpassaient dj 100 M octets ! Aujourdhui, les disques contiennent plusieurs giga-octets
et lon parle de ptabases (10 puissance 15 octets). Demain, et demain est dj l,
avec lintgration des rseaux et des bases de donnes, tous les serveurs de donnes
du monde seront interconnects et lon grera des volumes inimaginables de donnes
en ligne par des techniques plus ou moins issues des bases de donnes...
Alors que les bases de donnes semblaient au dbut rserves quelques applications
sophistiques de gestion, toute application moderne utilise aujourdhui une base de
donnes sous une forme ou sous une autre. Certes, il y a encore beaucoup de donnes
dans des fichiers, mais lquilibre o plutt le dsquilibre se dplace. Toute

IV BASES DE DONNES : OBJET ET RELATIONNEL

application de gestion non vieillotte utilise une BD relationnelle, les BD objets percent dans les applications donnes complexes, et les serveurs Web sappuient de
plus en plus sur des bases de donnes. Pourquoi ? Car les BD offrent le partage, la fiabilit, les facilits de recherche et bientt la souplesse et lintelligence avec le support
de donnes multimdia et semi-structures, et de techniques venues de lintelligence
artificielle, telles le data mining. Les BD sont de plus en plus distribues, intgres
avec les rseaux Intranet et Internet. Do leur gnralisation.
Voil donc un domaine que jai eu la chance de traverser depuis sa naissance qui a
cr beaucoup demplois et qui va continuer en crer dans le millnaire qui vient. Le
vingt et unime sicle devrait tre celui des sciences et techniques de linformation, au
moins son dbut. Certains mobjecteront que lon a cr beaucoup de formulaires,
alourdi la gestion et plus gnralement la socit, et aussi dtruit les petits emplois.
Peut-tre, mais ce nest pas lobjectif, et ceci devrait tre corrig (notamment avec les
formulaires en ligne). Dautres objecteront que nous crons (avec Internet notamment)
une civilisation deux vitesses : je le crains malheureusement, et voil pourquoi il est
trs ncessaire de simplifier et dmystifier, par exemple en crivant des livres essayant
de mettre ces techniques la porte de tous.
Dans le domaine des bases de donnes, comme dans beaucoup dautres, la France a
gch beaucoup de chances, mais reste encore trs comptitive, au moins en comptences sinon en produits. En fait, depuis septembre 1997, lindustrie franaise ne possde plus de SGBD important. Auparavant, elle avait possd SOCRATE, IDS II,
SABRE (un SGBD important pour lauteur), et enfin O2. vrai dire, le seul bien
vendu fut IDS.II, un produit issu des tats-Unis. Mais enfin, nous avions la matrise
de la technologie...
Ce livre prsente une synthse des principes et des techniques actuelles en matire de
base de donnes. Il traite des bases de donnes relationnelles et des bases de donnes
objet. Ces paradigmes sont au cur des systmes dinformation daujourdhui. Ils
sont essentiels pour les entreprises et mritent dtre connus de tout tudiant
lUniversit ou en cole dingnieur.
Ce livre est accompagn dun compagnon plus petit traitant des nouvelles techniques :
data warehouse, data mining, BD Web et BD multimdia. Il sagit l des nouveaux
thmes en vogue du domaine, qui vont sans doute profondment rvolutionner linformatique de demain. Nous avons choisi de ne pas intgrer ces sujets ce livre mais
un volume spar, car ils ne sont pas encore stabiliss, alors que le relationnel et
lobjet ainsi que le mlange des deux, connu sous le nom objet-relationnel le sont
beaucoup plus.
En rsum, cet ouvrage est le fruit dune exprience de trente ans denseignement, de
formation et de conseil luniversit et dans lindustrie. Il aborde tous les sujets au
cur des systmes dinformation modernes. Chaque chapitre traite un thme particulier. laide de notions prcisment dfinies une technique denseignement inven-

Avant-propos V

te par Michel Rocher dans les annes 1970, procdant par dfinitions informelles ,
nous clarifions des concepts souvent difficiles.
En annexe de cet ouvrage, vous trouverez une cinquantaine de textes dexercices qui
drivent de sujets dexamens proposs aux tudiants Paris VI ou Versailles depuis
1980, adapts et moderniss.
Avec cet ouvrage, nous esprons mettre entre les mains des gnrations actuelles et
futures denseignants, dingnieurs et de chercheurs une exprience pratique et thorique exceptionnelle en matire de bases de donnes.

NOTATIONS
Afin de prsenter la syntaxe de certains langages, nous utiliserons les notations suivantes :
[a] signifie que llment a est optionnel ;
[a]... signifie que llment a peut-tre rpt 0 n fois (n entier positif) ;
{a b} signifie que les lments a et b sont considrs comme un lment unique ;
{a | b} signifie un choix possible entre lalternative a ou b ;
< a > signifie que a est un paramtre qui doit tre remplac par une valeur effective.

SOMMAIRE
PARTIE 1 LES BASES
CHAPITRE I INTRODUCTION ............................................................................................................

1. QUEST-CE QUUNE BASE DE DONNES ? ..................................................................

2. HISTORIQUE DES SGBD ....................................................................................................................

3. PLAN DE CET OUVRAGE ..................................................................................................................

4. BIBLIOGRAPHIE..........................................................................................................................................

10

CHAPITRE II OBJECTIFS ET ARCHITECTURE DES SGBD ..........................

13

1. INTRODUCTION...........................................................................................................................................

13

2. MODLISATION DES DONNES...............................................................................................

2.1 Instances et schmas ........................................................................................................................
2.2. Niveaux dabstraction .....................................................................................................................
2.2.1. Le niveau conceptuel ........................................................................................................
2.2.2. Le niveau interne .................................................................................................................
2.2.3. Le niveau externe.................................................................................................................
2.2.4. Synthse des niveaux de schmas ..........................................................................
2.3. Le modle entit-association.....................................................................................................

15
15
16
17
18
18
19
20

3. OBJECTIFS DES SGBD ..........................................................................................................................

3.1. Indpendance physique..................................................................................................................
3.2. Indpendance logique .....................................................................................................................
3.3. Manipulation des donnes par des langages non procduraux ....................
3.4. Administration facilite des donnes .................................................................................

23
24
25
26
26

X BASES DE DONNES : OBJET ET RELATIONNEL

3.5.
3.6.
3.7.
3.8.
3.9.

Efficacit des accs aux donnes ...........................................................................................

Redondance contrle des donnes .....................................................................................
Cohrence des donnes ..................................................................................................................
Partage des donnes ..........................................................................................................................
Scurit des donnes ........................................................................................................................

27
28
28
28
29

4. FONCTIONS DES SGBD .......................................................................................................................

4.1. Description des donnes ...............................................................................................................
4.2. Recherche de donnes.....................................................................................................................
4.3. Mise jour des donnes ................................................................................................................
4.4. Transformation des donnes ......................................................................................................
4.5. Contrle de lintgrit des donnes .....................................................................................
4.6. Gestion de transactions et scurit .......................................................................................
4.7. Autres fonctions ...................................................................................................................................

29
30
32
33
35
37
37
38

5. ARCHITECTURE FONCTIONNELLE DES SGBD .....................................................

5.1. Larchitecture trois niveaux de lANSI/X3/SPARC .........................................
5.2. Une architecture fonctionnelle de rfrence ................................................................
5.3. Larchitecture du DBTG CODASYL ................................................................................

39
39
42
44

6. ARCHITECTURES OPRATIONNELLES DES SGBD ...........................................

6.1. Les architectures client-serveur ..............................................................................................
6.2. Les architectures rparties ...........................................................................................................

45
45
49

7. CONCLUSION .................................................................................................................................................

50

8. BIBLIOGRAPHIE..........................................................................................................................................

51

CHAPITRE III FICHIERS, HACHAGE ET INDEXATION.....................................

55

1. INTRODUCTION...........................................................................................................................................

55

2. OBJECTIFS ET NOTIONS DE BASE ........................................................................................

2.1. Gestion des disques magntiques..........................................................................................
2.2. Indpendance des programmes par rapport
aux mmoires secondaires...........................................................................................................
2.3. Utilisation de langages htes ....................................................................................................
2.4. Possibilits daccs squentiel et slectif .......................................................................
2.5. Possibilit dutilisateurs multiples .......................................................................................
2.6. Scurit et protection des fichiers .........................................................................................

57
57
60
61
62
63
64

Sommaire XI

3. FONCTIONS DUN GRANT DE FICHIERS ...................................................................

3.1. Architecture dun gestionnaire de fichiers ....................................................................
3.2. Fonctions du noyau dun gestionnaire de fichiers ..................................................
3.2.1. Manipulation des fichiers .............................................................................................
3.2.2. Adressage relatif...................................................................................................................
3.2.3. Allocation de la place sur mmoires secondaires ...................................
3.2.4. Localisation des fichiers sur les volumes .......................................................
3.2.5. Classification des fichiers en hirarchie .........................................................
3.2.6. Contrle des fichiers.........................................................................................................
3.3. Stratgie dallocation de la mmoire secondaire .....................................................
3.3.1. Objectifs dune stratgie ...............................................................................................
3.3.2. Stratgie par granule ( rgion fixe) ..................................................................
3.3.3. Stratgie par rgion ( rgion variable) .........................................................

64
64
66
66
66
67
68
69
71
71
71
72
72

4. ORGANISATIONS ET MTHODES DACCS PAR HACHAGE .................

4.1. Organisation hache statique ....................................................................................................
4.2. Organisations haches dynamiques.....................................................................................
4.2.1. Principes du hachage dynamique .........................................................................
4.2.2. Le hachage extensible......................................................................................................
4.2.3. Le hachage linaire ...........................................................................................................

73
73
76
76
77
79

5. ORGANISATIONS ET MTHODES DACCS INDEXES ..............................

5.1. Principes des organisations indexes .................................................................................
5.1.1. Notion dindex ........................................................................................................................
5.1.2. Variantes possibles .............................................................................................................
5.1.3. Index hirarchis .................................................................................................................
5.1.4. Arbres B .......................................................................................................................................
5.1.5. Arbre B+ .....................................................................................................................................
5.2 Organisation indexe IS3 .............................................................................................................
5.3. Organisation squentielle indexe ISAM.......................................................................
5.3.1. Prsentation gnrale......................................................................................................
5.3.2. tude de la zone primaire ............................................................................................
5.3.3. tude de la zone de dbordement ..........................................................................
5.3.4. tude de la zone index ....................................................................................................
5.3.5. Vue densemble......................................................................................................................
5.4. Organisation squentielle indexe rgulire VSAM ............................................
5.4.1. Prsentation gnrale......................................................................................................
5.4.2. tude de la zone des donnes ...................................................................................
5.4.3. tude de la zone index ....................................................................................................
5.4.4. Vue densemble......................................................................................................................

81
81
81
82
84
84
88
89
91
91
92
92
93
94
95
95
95
97
98

6. MTHODES DACCS MULTI-ATTRIBUTS...................................................................

6.1. Index secondaires ................................................................................................................................

99
99

XII BASES DE DONNES : OBJET ET RELATIONNEL

6.2. Hachage multi-attribut ....................................................................................................................

6.2.1. Hachage multi-attribut statique ..............................................................................
6.2.2. Hachages multi-attributs dynamiques ...............................................................
6.3. Index bitmap............................................................................................................................................

101
101
101
104

7. CONCLUSION ................................................................................................................................................. 106

8. BIBLIOGRAPHIE.......................................................................................................................................... 107

CHAPITRE IV BASES DE DONNES RSEAUX

ET HIRARCHIQUES .......................................................................................................................................... 111
1. INTRODUCTION........................................................................................................................................... 111
2. LE MODLE RSEAU.............................................................................................................................
2.1. Introduction et notations ...............................................................................................................
2.2. La dfinition des objets ..................................................................................................................
2.3. La dfinition des associations ..................................................................................................
2.4. Lordonnancement des articles dans les liens .............................................................
2.5. La slection doccurrence dun type de lien ................................................................
2.6 Les options dinsertion dans un lien ...................................................................................
2.7. Le placement des articles .............................................................................................................
2.8. Exemple de schma...........................................................................................................................

112
112
113
115
119
121
122
122
125

3. LE LANGAGE DE MANIPULATION COBOL-CODASYL .................................

3.1. Sous-schma COBOL .....................................................................................................................
3.2. La navigation CODASYL ...........................................................................................................
3.3. La recherche darticles ...................................................................................................................
3.3.1. La recherche sur cl ..........................................................................................................
3.3.2. La recherche dans un fichier .....................................................................................
3.3.3. La recherche dans une occurrence de lien ....................................................
3.3.4. Le positionnement du curseur de programme ............................................
3.4. Les changes darticles ..................................................................................................................
3.5. Les mises jour darticles ...........................................................................................................
3.5.1. Suppression darticles .....................................................................................................
3.5.2. Modification darticles ...................................................................................................
3.5.3. Insertion et suppression dans une occurrence de lien .........................
3.6. Le contrle des fichiers ..................................................................................................................
3.7. Quelques exemples de transaction .......................................................................................

127
127
128
129
130
130
131
132
132
132
133
133
133
134
134

4. LE MODLE HIRARCHIQUE ...................................................................................................... 136

4.1. Les concepts du modle ................................................................................................................ 136

Sommaire XIII

4.2. Introduction au langage DL1 .................................................................................................... 138

4.3. Quelques exemples de transactions ..................................................................................... 141
5. CONCLUSION ................................................................................................................................................. 143
6. BIBLIOGRAPHIE.......................................................................................................................................... 144

CHAPITRE V LOGIQUE ET BASES DE DONNES ..................................................... 147

1. INTRODUCTION........................................................................................................................................... 147
2. LA LOGIQUE DU PREMIER ORDRE......................................................................................
2.1. Syntaxe de la logique du premier ordre ...........................................................................
2.2. Smantique de la logique du premier ordre .................................................................
2.3 Forme clausale des formules fermes ...............................................................................

148
148
150
151

3. LES BASE DE DONNES LOGIQUE ....................................................................................... 153

3.1. La reprsentation des faits ........................................................................................................... 153
3.2. Questions et contraintes dintgrit..................................................................................... 155
4. LE CALCUL DE DOMAINES ...........................................................................................................
4.1 Principes de base .................................................................................................................................
4.2. Quelques exemples de calcul de domaine .....................................................................
4.3. Le langage QBE ...................................................................................................................................

156
156
157
158

5. LE CALCUL DE TUPLES ..................................................................................................................... 166

5.1. Principes du calcul de tuple ....................................................................................................... 166
5.2. Quelques exemples de calcul de tuple .............................................................................. 167
6. LES TECHNIQUES DINFRENCE ...........................................................................................
6.1. Principe dun algorithme de dduction ............................................................................
6.2. Algorithme dunification ..............................................................................................................
6.3. Mthode de rsolution ....................................................................................................................

168
168
169
170

7. CONCLUSION ................................................................................................................................................. 172

8. BIBLIOGRAPHIE.......................................................................................................................................... 173

PARTIE 2 LE RELATIONNEL
CHAPITRE VI LE MODLE RELATIONNEL..................................................................... 179
1. INTRODUCTION : LES OBJECTIFS DU MODLE .................................................. 179
2. LES STRUCTURES DE DONNES DE BASE ................................................................. 181

XIV BASES DE DONNES : OBJET ET RELATIONNEL

2.1. Domaine, attribut et relation ...................................................................................................... 181

2.2. Extensions et intentions ................................................................................................................. 184
3. LES RGLES DINTGRIT STRUCTURELLE ...........................................................
3.1. Unicit de cl ..........................................................................................................................................
3.2. Contraintes de rfrences .............................................................................................................
3.3. Valeurs nulles et cls ........................................................................................................................
3.4. Contraintes de domaines...............................................................................................................

185
185
186
188
188

4. LALGBRE RELATIONNELLE : OPRATIONS DE BASE.............................

4.1. Les oprations ensemblistes ......................................................................................................
4.1.1. Union .............................................................................................................................................
4.1.2. Diffrence ...................................................................................................................................
4.1.3. Produit cartsien..................................................................................................................
4.2. Les oprations spcifiques ..........................................................................................................
4.2.1. Projection ...................................................................................................................................
4.2.2. Restriction..................................................................................................................................
4.2.3. Jointure.........................................................................................................................................

189
190
190
191
192
193
193
194
195

5. LALGBRE RELATIONNELLE : OPRATIONS DRIVES ........................

5.1. Intersection ...............................................................................................................................................
5.2. Division .......................................................................................................................................................
5.3. Complment ............................................................................................................................................
5.4. clatement.................................................................................................................................................
5.5. Jointure externe.....................................................................................................................................
5.6. Semi-jointure ..........................................................................................................................................
5.7. Fermeture transitive ..........................................................................................................................

198
198
199
200
201
202
203
204

6. LES EXPRESSIONS DE LALGBRE RELATIONNELLE ................................. 206

6.1. Langage algbrique ........................................................................................................................... 206
6.2. Arbre algbrique .................................................................................................................................. 207
7. FONCTIONS ET AGRGATS ........................................................................................................... 209
7.1. Fonctions de calcul ............................................................................................................................ 209
7.2. Support des agrgats ........................................................................................................................ 210
8. CONCLUSION ................................................................................................................................................. 211
9. BIBLIOGRAPHIE.......................................................................................................................................... 212

CHAPITRE VII LE LANGAGE SQL2 ............................................................................................. 217

1. INTRODUCTION........................................................................................................................................... 217

Sommaire XV

2. SQL1 : LA DFINITION DE SCHMAS ...............................................................................

2.1. Cration de tables ...............................................................................................................................
2.2. Expression des contraintes dintgrit ..............................................................................
2.3. Dfinition des vues ............................................................................................................................
2.4. Suppression des tables ....................................................................................................................
2.5. Droits daccs .........................................................................................................................................

219
219
220
221
222
222

3. SQL1 : LA RECHERCHE DE DONNES ..............................................................................

3.1. Expression des projections .........................................................................................................
3.2. Expression des slections.............................................................................................................
3.3. Expression des jointures ...............................................................................................................
3.4. Sous-questions .......................................................................................................................................
3.5. Questions quantifies.......................................................................................................................
3.6. Expression des unions.....................................................................................................................
3.7. Fonctions de calculs et agrgats .............................................................................................

223
223
224
226
227
228
230
230

4. SQL1 : LES MISES JOUR ...............................................................................................................

4.1. Insertion de tuples ..............................................................................................................................
4.2. Mise jour de tuples ........................................................................................................................
4.3. Suppression de tuples ......................................................................................................................

232
232
233
233

5. SQL1 : LA PROGRAMMATION DE TRANSACTIONS..........................................

5.1. Commandes de gestion de transaction..............................................................................
5.2. Curseurs et procdures ...................................................................................................................
5.3. Intgration de SQL et des langages de programmation .....................................

234
234
235
236

6. SQL2 : LE STANDARD DE 1992 ...................................................................................................

6.1. Le niveau entre ...................................................................................................................................
6.2. Le niveau intermdiaire .................................................................................................................
6.2.1. Les extensions des types de donnes...................................................................
6.2.2. Un meilleur support de lintgrit ........................................................................
6.2.3. Une intgration tendue de lalgbre relationnelle ...............................
6.2.4. La possibilit de modifier les schmas .............................................................
6.2.5. Lexcution immdiate des commandes SQL ..............................................
6.3. Le niveau complet ..............................................................................................................................

238
238
239
239
240
241
242
242
242

7. CONCLUSION ................................................................................................................................................. 243

8. BIBLIOGRAPHIE.......................................................................................................................................... 244

CHAPITRE VIII INTGRIT ET BD ACTIVES ................................................................ 247

1. INTRODUCTION........................................................................................................................................... 247

XVI BASES DE DONNES : OBJET ET RELATIONNEL

2. TYPOLOGIE DES CONTRAINTES DINTGRIT ...................................................

2.1. Contraintes structurelles................................................................................................................
2.2. Contraintes non structurelles.....................................................................................................
2.3. Expression des contraintes en SQL .....................................................................................

249
249
250
251

3. ANALYSE DES CONTRAINTES DINTGRIT..........................................................

3.1. Test de cohrence et de non-redondance ........................................................................
3.2. Simplification oprationnelle ...................................................................................................
3.3. Simplification diffrentielle .......................................................................................................

254
254
255
256

4. CONTRLE DES CONTRAINTES DINTGRIT.....................................................

4.1. Mthode de dtection ......................................................................................................................
4.2. Mthode de prvention...................................................................................................................
4.3. Contrles au vol des contraintes simples........................................................................
4.3.1. Unicit de cl ..........................................................................................................................
4.3.2. Contrainte rfrentielle ..................................................................................................
4.3.3. Contrainte de domaine ...................................................................................................
4.4. Interaction entre contraintes ......................................................................................................

258
258
259
262
262
262
263
263

5. SGBD ACTIFS ET DCLENCHEURS......................................................................................

5.1. Objectifs ......................................................................................................................................................
5.2. Types de rgles ......................................................................................................................................
5.3. Composants dun SGBD actif..................................................................................................

264
264
264
266

6. LA DFINITION DES DCLENCHEURS............................................................................

6.1. Les vnements.....................................................................................................................................
6.1.1. vnement simple................................................................................................................
6.1.2. vnement compos ..........................................................................................................
6.2. La condition .............................................................................................................................................
6.3. Laction ........................................................................................................................................................
6.4. Expression en SQL3 .........................................................................................................................
6.4.1. Syntaxe..........................................................................................................................................
6.4.2. Smantique ................................................................................................................................
6.5. Quelques exemples ............................................................................................................................
6.5.1. Contrle dintgrit...........................................................................................................
6.5.2. Mise jour automatique de colonnes ................................................................
6.5.3. Gestion de donnes agrgatives .............................................................................

267
267
268
269
269
269
270
270
271
271
271
272
273

7. EXCUTION DES DCLENCHEURS .....................................................................................

7.1. Procdure gnrale ............................................................................................................................
7.2. Priorits et imbrications ................................................................................................................
7.3. Couplage la gestion de transactions ...............................................................................

273
274
275
276

Sommaire XVII

8. CONCLUSION ................................................................................................................................................. 276

9. BIBLIOGRAPHIE.......................................................................................................................................... 277

CHAPITRE IX LA GESTION DES VUES ................................................................................... 281

1. INTRODUCTION........................................................................................................................................... 281
2. DFINITION DES VUES ....................................................................................................................... 283
3. INTERROGATION AU TRAVERS DE VUES .................................................................... 285
4. MISE JOUR AU TRAVERS DE VUES ................................................................................
4.1. Vue mettable jour............................................................................................................................
4.2. Approche pratique ..............................................................................................................................
4.3. Approche thorique ...........................................................................................................................

288
288
288
289

5. VUES CONCRTES ET DCISIONNEL ...............................................................................

5.1. Dfinition ...................................................................................................................................................
5.2. Stratgie de report ..............................................................................................................................
5.3. Le cas des agrgats ............................................................................................................................

290
290
292
294

6. CONCLUSION ................................................................................................................................................. 296

7. BIBLIOGRAPHIE.......................................................................................................................................... 297

CHAPITRE X OPTIMISATION DE QUESTIONS ............................................................. 301

1. INTRODUCTION........................................................................................................................................... 301
2. LES OBJECTIFS DE LOPTIMISATION ................................................................................
2.1. Exemples de bases et requtes .................................................................................................
2.2. Requtes statiques ou dynamiques ......................................................................................
2.3. Analyse des requtes ........................................................................................................................
2.4. Fonctions dun optimiseur...........................................................................................................

303
303
304
305
308

3. LOPTIMISATION LOGIQUE OU RCRITURE ........................................................

3.1. Analyse et rcriture smantique ..........................................................................................
3.1.1. Graphes support de lanalyse...................................................................................
3.1.2. Correction de la question .............................................................................................
3.1.3. Questions quivalentes par transitivit ............................................................
3.1.4. Questions quivalentes par intgrit ..................................................................
3.2. Rcritures syntaxiques et restructurations algbriques....................................
3.2.1. Rgles de transformation des arbres ..................................................................
3.2.2. Ordonnancement par descente des oprations unaires ......................

310
310
310
312
312
314
315
315
319

XVIII BASES DE DONNES : OBJET ET RELATIONNEL

3.3. Ordonnancement par dcomposition .................................................................................

3.3.1. Le dtachement de sous-questions .......................................................................
3.3.2. Diffrents cas de dtachement..................................................................................
3.4. Bilan des mthodes doptimisation logique .................................................................

320
321
322
325

4. Les Oprateurs physiques .........................................................................................................................

4.1. Oprateur de slection ....................................................................................................................
4.1.1. Slection sans index ..........................................................................................................
4.1.2. Slection avec index de type arbre-B .................................................................
4.2. Oprateur de tri .....................................................................................................................................
4.3. Oprateur de jointure .......................................................................................................................
4.3.1. Jointure sans index .............................................................................................................
4.3.2. Jointure avec index de type arbre-B....................................................................
4.4. Le calcul des agrgats .....................................................................................................................

325
325
326
327
328
329
330
334
334

5. LESTIMATION DU COT DUN PLAN DEXCUTION ..................................

5.1. Nombre et types de plans dexcution ..............................................................................
5.2. Estimation de la taille des rsultats intermdiaires ................................................
5.3. Prise en compte des algorithmes daccs .......................................................................

335
335
337
339

6. LA RECHERCHE DU MEILLEUR PLAN ............................................................................

6.1. Algorithme de slectivit minimale ....................................................................................
6.2. Programmation dynamique (DP) ..........................................................................................
6.3. Programmation dynamique inverse .....................................................................................
6.4. Les stratgies de recherche alatoires ...............................................................................

340
341
341
342
343

7. CONCLUSION ................................................................................................................................................. 344

8. BIBLIOGRAPHIE.......................................................................................................................................... 344

PARTIE 3 LOBJET ET LOBJET-RELATIONNEL

CHAPITRE XI LE MODLE OBJET .............................................................................................. 353
1. INTRODUCTION........................................................................................................................................... 353
2. LE MODLE OBJET DE RFRENCE ..................................................................................
2.1. Modlisation des objets .................................................................................................................
2.2. Encapsulation des objets...............................................................................................................
2.3. Dfinition des types dobjets.....................................................................................................
2.4. Liens dhritage entre classes...................................................................................................
2.5. Polymorphisme, redfinition et surcharge.....................................................................

354
354
357
358
361
365

Sommaire XIX

2.6. Dfinition des collections dobjets....................................................................................... 367

2.7. Prise en compte de la dynamique.......................................................................................... 370
2.8. Schma de bases de donnes objets................................................................................ 371
3. LA PERSISTANCE DES OBJETS .................................................................................................
3.1. Quest-ce-quune BD objets ? .............................................................................................
3.2. Gestion de la persistance ..............................................................................................................
3.3. Persistance par hritage .................................................................................................................
3.4. Persistance par rfrence ..............................................................................................................
3.5. Navigation dans une base dobjets .......................................................................................

373
373
375
377
378
380

4. ALGBRE POUR OBJETS COMPLEXES............................................................................

4.1. Expressions de chemins et de mthodes .........................................................................
4.2. Groupage et dgroupage de relations ................................................................................
4.3. Lalgbre dEncore ............................................................................................................................
4.4. Une algbre sous forme de classes ......................................................................................
4.4.1. Les oprations de recherche ......................................................................................
4.4.2. Les oprations ensemblistes.......................................................................................
4.4.3. Les oprations de mise jour...................................................................................
4.4.4. Les oprations de groupe .............................................................................................
4.4.5. Arbres doprations algbriques ...........................................................................

382
382
385
386
387
388
389
390
391
392

5. CONCLUSION ................................................................................................................................................. 394

6. BIBLIOGRAPHIE.......................................................................................................................................... 395

CHAPITRE XII LE STANDARD DE LODMG : ODL, OQL ET OML ....... 401

1. INTRODUCTION........................................................................................................................................... 401
2. CONTEXTE.........................................................................................................................................................
2.1. L ODMG (Object Database Management Group)...............................................
2.2. Contenu de la proposition ............................................................................................................
2.3. Architecture .............................................................................................................................................

401
402
403
404

3. LE MODLE DE LODMG ..................................................................................................................

3.1. Vue gnrale et concepts de base ..........................................................................................
3.2. Hritage de comportement et de structure.....................................................................
3.3. Les objets instances de classes ................................................................................................
3.4. Proprits communes des objets ............................................................................................
3.5. Les objets structurs .........................................................................................................................
3.6. Les collections .......................................................................................................................................

406
406
408
409
409
410
410

XX BASES DE DONNES : OBJET ET RELATIONNEL

3.7. Les attributs ..............................................................................................................................................

3.8. Les associations (Relationships) ............................................................................................
3.9. Les oprations ........................................................................................................................................
3.10.Mta-modle du modle ODMG...........................................................................................

412
412
413
414

4. EXEMPLE DE SCHMA ODL......................................................................................................... 415

5. LE LANGAGE OQL ....................................................................................................................................
5.1. Vue gnrale ............................................................................................................................................
5.2. Exemples et syntaxes de requtes .........................................................................................
5.2.1. Calcul dexpressions.........................................................................................................
5.2.2. Accs partir dobjets nomms..............................................................................
5.2.3. Slection avec qualification .......................................................................................
5.2.4. Expression de jointures ..................................................................................................
5.2.5. Parcours dassociations multivalues
par des collections dpendantes.............................................................................
5.2.6. Slection d une structure en rsultat ................................................................
5.2.7. Calcul de collections en rsultat ............................................................................
5.2.8. Manipulation des identifiants dobjets .............................................................
5.2.9. Application de mthodes en qualification et en rsultat ...................
5.2.10. Imbrication de SELECT en rsultat .................................................................
5.2.11. Cration dobjets en rsultat..................................................................................
5.2.12. Quantification de variables .....................................................................................
5.2.13. Calcul dagrgats et oprateur GROUP BY.............................................
5.2.14. Expressions de collections........................................................................................
5.2.15. Conversions de types appliques aux collections.................................
5.2.16. Dfinition dobjets via requtes ...........................................................................
5.3. Bilan sur OQL .......................................................................................................................................

417
417
418
419
419
420
420

6. OML : LINTGRATION C++, SMALLTALK ET JAVA ....................................

6.1. Principes de base .................................................................................................................................
6.2. Contexte transactionnel .................................................................................................................
6.3. Lexemple de Java ..............................................................................................................................
6.3.1. La persistance des objets ..............................................................................................
6.3.2. Les correspondances de types ..................................................................................
6.3.3. Les collections........................................................................................................................
6.3.4. La transparence des oprations ..............................................................................
6.3.5. Java OQL ...................................................................................................................................
6.3.6. Bilan ...............................................................................................................................................

427
427
428
429
429
430
430
430
431
431

421
421
422
422
422
423
423
424
424
425
426
427
427

7. CONCLUSION ................................................................................................................................................. 432

8. BIBLIOGRAPHIE.......................................................................................................................................... 433

Sommaire XXI

CHAPITRE XIII LOBJET-RELATIONNEL ET SQL3 ................................................ 435

1. INTRODUCTION........................................................................................................................................... 435
2. POURQUOI INTGRER LOBJET AU RELATIONNEL ? ....................................
2.1. Forces du modle relationnel ....................................................................................................
2.2. Faiblesses du modle relationnel ...........................................................................................
2.3. Lapport des modles objet .........................................................................................................
2.4. Le support dobjets complexes................................................................................................

436
436
437
438
439

3. LE MODLE OBJET-RELATIONNEL ..................................................................................... 440

3.1. Les concepts additionnels essentiels .................................................................................. 441
3.2. Les extensions du langage de requtes ............................................................................. 442
4. VUE DENSEMBLE DE SQL3 .........................................................................................................
4.1. Le processus de normalisation.................................................................................................
4.2. Les composants et le planning .................................................................................................
4.3. La base .........................................................................................................................................................

444
444
444
445

5. LE SUPPORT DES OBJETS ................................................................................................................

5.1. Les types abstraits ..............................................................................................................................
5.1.1. Principes .....................................................................................................................................
5.1.2. Syntaxe..........................................................................................................................................
5.1.3. Quelques exemples .............................................................................................................
5.2. Les constructeurs dobjets complexes...............................................................................
5.3. Les tables....................................................................................................................................................
5.4. Lappel de fonctions et doprateurs dans les requtes ......................................
5.5. Le parcours de rfrence...............................................................................................................
5.6. La recherche en collections ........................................................................................................
5.7. Recherche et hritage ......................................................................................................................

446
446
446
447
448
449
450
450
452
453
454

6. LE LANGAGE DE PROGRAMMATION PSM .................................................................

6.1. Modules, fonctions et procdures .........................................................................................
6.2. Les ordres essentiels .........................................................................................................................
6.3. Quelques exemples ............................................................................................................................
6.4. Place de PSM dans le standard SQL ..................................................................................

454
454
455
456
457

7. CONCLUSION ................................................................................................................................................. 457

8. BIBLIOGRAPHIE.......................................................................................................................................... 459

CHAPITRE XIV OPTIMISATION DE REQUTES OBJET .................................. 463

1. INTRODUCTION........................................................................................................................................... 463

XXII BASES DE DONNES : OBJET ET RELATIONNEL

2. PROBLMATIQUE DES REQUTES OBJET ..................................................................

2.1. Quest-ce quune requte objet ? ...........................................................................................
2.2. Quelques exemples motivants ..................................................................................................
2.2.1. Parcours de chemins .........................................................................................................
2.2.2. Mthodes et oprateurs ..................................................................................................
2.2.3. Manipulation de collections.......................................................................................
2.2.4. Hritage et polymorphisme ........................................................................................

465
465
466
466
467
468
468

3. MODLE DE STOCKAGE POUR BD OBJET ..................................................................

3.1. Identifiants dobjets...........................................................................................................................
3.2. Indexation des collections dobjets .....................................................................................
3.3. Liaison et incorporation dobjets...........................................................................................
3.4. Groupage dobjets ..............................................................................................................................
3.5. Schma de stockage ..........................................................................................................................

469
469
471
472
474
476

4. PARCOURS DE CHEMINS .................................................................................................................

4.1. Traverse en profondeur dabord ..........................................................................................
4.2. Traverse en largeur dabord.....................................................................................................
4.3. Traverse lenvers...........................................................................................................................
4.4. Traverse par index de chemin ................................................................................................

477
478
479
480
481

5. GNRATION DES PLANS QUIVALENTS ...................................................................

5.1. Notion doptimiseur extensible ...............................................................................................
5.2. Les types de rgles de transformation de plans ........................................................
5.2.1. Rgles syntaxiques .............................................................................................................
5.2.2. Rgles smantiques ............................................................................................................
5.2.3. Rgles de planning .............................................................................................................
5.3. Taille de lespace de recherche................................................................................................
5.4. Architecture dun optimiseur extensible .........................................................................

481
481
483
484
484
486
487
489

6. MODLE DE COT POUR BD OBJET ..................................................................................

6.1. Principaux paramtres dun modle de cot ...............................................................
6.2. Estimation du nombre de pages dune collection groupe..............................
6.3. Formule de Yao et extension aux collections groupes .....................................
6.4. Cot dinvocation de mthodes ..............................................................................................
6.5. Cot de navigation via expression de chemin ............................................................
6.6. Cot de jointure ....................................................................................................................................

489
490
491
493
494
495
496

7. STRATGIES DE RECHERCHE DU MEILLEUR PLAN ...................................... 497

7.1. Les algorithmes combinatoires ............................................................................................... 497
7.2. Lamlioration itrative (II) ........................................................................................................ 497

Sommaire XXIII

7.3.
7.4.
7.5.
7.6.

Le recuit simul (SA) ......................................................................................................................

Loptimisation deux phases (TP) ...........................................................................................
La recherche taboue (TS) .............................................................................................................
Analyse informelle de ces algorithmes ............................................................................

498
499
500
500

8. UN ALGORITHME DOPTIMISATION GNTIQUE ............................................

8.1. Principe dun algorithme gntique ....................................................................................
8.2. Bases de gnes et population initiale .................................................................................
8.3. Oprateur de mutation ....................................................................................................................
8.4. Oprateur de croisement ...............................................................................................................

501
501
503
504
505

9. CONCLUSION ................................................................................................................................................. 507

10. BIBLIOGRAPHIE.......................................................................................................................................... 508

PARTIE 4 AU-DEL DU SGBD

CHAPITRE XV BD DDUCTIVES .................................................................................................... 517
1. INTRODUCTION........................................................................................................................................... 517
2. PROBLMATIQUE DES SGBD DDUCTIFS ..................................................................
2.1. Langage de rgles ...............................................................................................................................
2.2. Couplage ou intgration ? ............................................................................................................
2.3. Prdicats extensionnels et intentionnels ..........................................................................
2.4. Architecture type dun SGBD dductif intgr ........................................................

518
518
519
520
521

3. LE LANGAGE DATALOG ....................................................................................................................

3.1. Syntaxe de DATALOG ...................................................................................................................
3.2. Smantique de DATALOG .........................................................................................................
3.2.1. Thorie de la preuve .........................................................................................................
3.2.2. Thorie du modle ..............................................................................................................
3.2.3. Thorie du point fixe.........................................................................................................
3.2.4. Concidence des smantiques ...................................................................................

522
522
526
526
528
529
531

4. LES EXTENSIONS DE DATALOG ..............................................................................................

4.1. Hypothse du monde ferm .......................................................................................................
4.2. Ngation en corps de rgles .......................................................................................................
4.3. Ngation en tte de rgles et mises jour......................................................................
4.4. Support des fonctions de calcul ..............................................................................................
4.5. Support des ensembles ...................................................................................................................

532
532
533
534
537
539

XXIV BASES DE DONNES : OBJET ET RELATIONNEL

5. VALUATION DE REQUTES DATALOG ......................................................................... 541

5.1. valuation bottom-up ...................................................................................................................... 541
5.2. valuation top-down ........................................................................................................................ 543
6. LA MODLISATION DE RGLES PAR DES GRAPHES .....................................
6.1. Arbres et graphes relationnels..................................................................................................
6.2. Arbres ET/OU et graphes rgle/but.....................................................................................
6.3. Autres Reprsentations ..................................................................................................................

545
546
548
550

7. VALUATION DES RGLES RCURSIVES ....................................................................

7.1. Le problme des rgles rcursives........................................................................................
7.2. Les approches bottom-up .............................................................................................................
7.2.1. La gnration nave...........................................................................................................
7.2.2. La gnration semi-nave .............................................................................................
7.3. Difficults et outils pour les approches top-down ..................................................
7.3.1. Approches et difficults ..................................................................................................
7.3.2. La remonte dinformations via les rgles ....................................................
7.3.3. Les rgles signes ...............................................................................................................
7.4. La mthode QoSaQ ...........................................................................................................................
7.5. Les ensembles magiques ..............................................................................................................
7.6. Quelques mthodes doptimisation moins gnrales ...........................................
7.6.1. La mthode fonctionnelle .............................................................................................
7.6.2. Les mthodes par comptages ....................................................................................
7.6.3. Les oprateurs graphes ..................................................................................................

553
553
556
556
558
559
559
561
563
564
564
566
566
569
570

8. RGLES ET OBJETS ................................................................................................................................. 570

8.1. Le langage de rgles pour objetS ROL ............................................................................ 571
8.2. Le langage de rgles pour objets DEL.............................................................................. 573
9. CONCLUSION ................................................................................................................................................. 574
10. BIBLIOGRAPHIE.......................................................................................................................................... 575

CHAPITRE XVI GESTION DE TRANSACTIONS ........................................................... 585

1. INTRODUCTION........................................................................................................................................... 585
2. NOTION DE TRANSACTION ..........................................................................................................
2.1. Exemple de transaction ..................................................................................................................
2.2. Proprit des transactions ............................................................................................................
2.2.1. Atomicit .....................................................................................................................................
2.2.2. Cohrence ..................................................................................................................................

586
586
588
588
588

Sommaire XXV

2.2.3. Isolation ....................................................................................................................................... 589

2.2.4. Durabilit ................................................................................................................................... 589
3. THORIE DE LA CONCURRENCE...........................................................................................
3.1. Objectifs ......................................................................................................................................................
3.2. Quelques dfinitions de base.....................................................................................................
3.3. Proprits des oprations sur granule ................................................................................
3.4. Caractrisation des excutions correctes ........................................................................
3.5. Graphe de prcdence .....................................................................................................................

589
589
591
593
594
596

4. CONTRLE DE CONCURRENCE PESSIMISTE .........................................................

4.1. Le Verrouillage deux phases .....................................................................................................
4.2. Degr disolation en SQL2 .........................................................................................................
4.3. Le problme du verrou mortel .................................................................................................
4.3.1. Dfinition ....................................................................................................................................
4.3.2. Reprsentation du verrou mortel ...........................................................................
4.3.3. Prvention du verrou mortel......................................................................................
4.3.4. Dtection du verrou mortel .........................................................................................
4.4. Autres problmes soulevs par le verrouillage ..........................................................
4.5. Les amliorations du verrouillage ........................................................................................
4.5.1. Verrouillage granularit variable .....................................................................
4.5.2. Verrouillage multi-versions.........................................................................................
4.5.3. Verrouillage altruiste........................................................................................................
4.5.4. Commutativit smantique doprations ........................................................

597
598
600
600
600
601
604
605
607
608
609
610
610
611

5. CONTRLES DE CONCURRENCE OPTIMISTE ........................................................

5.1. Ordonnancement par estampillage.......................................................................................
5.2. Certification optimiste ....................................................................................................................
5.3. Estampillage multi-versions ......................................................................................................

612
613
614
615

6. LES PRINCIPES DE LA RSISTANCE AUX PANNES ..........................................

6.1. Principaux types de pannes ........................................................................................................
6.2. Objectifs de la rsistance aux pannes ................................................................................
6.3. Interface applicative transactionnelle ................................................................................
6.4. lments utiliss pour la rsistance aux pannes .......................................................
6.4.1. Mmoire stable ......................................................................................................................
6.4.2. Cache volatile .........................................................................................................................
6.4.3. Journal des mises jour ...............................................................................................
6.4.4. Sauvegarde des bases ......................................................................................................
6.4.5. Point de reprise systme ................................................................................................

617
617
618
619
620
620
621
622
625
625

7. VALIDATION DE TRANSACTION ............................................................................................. 625

7.1. critures en place dans la base ................................................................................................ 626

XXVI BASES DE DONNES : OBJET ET RELATIONNEL

7.2. critures non en place ..................................................................................................................... 627

7.3. Validation en deux tapes ............................................................................................................ 628
8. LES PROCDURES DE REPRISE ................................................................................................
8.1. Procdure de reprise .........................................................................................................................
8.2. Reprise chaud.....................................................................................................................................
8.3. Protocoles de reprise chaud ...................................................................................................
8.4. Reprise froid et catastrophe ...................................................................................................

631
631
632
633
634

9. LA MTHODE ARIES .............................................................................................................................

9.1. Objectifs ......................................................................................................................................................
9.2. Les structures de donnes ............................................................................................................
9.3. Aperu de la mthode .....................................................................................................................

634
635
636
637

10. LES MODLES DE TRANSACTIONS TENDUS ......................................................

10.1.Les transactions imbriques.......................................................................................................
10.2.Les sagas.....................................................................................................................................................
10.3.Les activits .............................................................................................................................................
10.4.Autres modles......................................................................................................................................

638
639
640
641
642

11. SCURIT DES DONNES ...............................................................................................................

11.1.Identification des sujets .................................................................................................................
11.2.La dfinition des objets ..................................................................................................................
11.3.Attribution et contrle des autorisations : la mthode DAC ..........................
11.4.Attribution et contrle des autorisations : la mthode MAC .........................
11.5.Quelques mots sur le cryptage .................................................................................................

644
644
645
646
648
649

12. CONCLUSION ET PERSPECTIVES .......................................................................................... 651

13. BIBLIOGRAPHIE.......................................................................................................................................... 652

CHAPITRE XVII CONCEPTION DES BASES DE DONNES ........................... 661

1. INTRODUCTION........................................................................................................................................... 661
2. LABORATION DU SCHMA CONCEPTUEL .............................................................
2.1. Perception du monde rel avec E/R ....................................................................................
2.2. Perception du monde rel avec UML ................................................................................
2.3. Intgration de schmas externes ............................................................................................

663
663
667
670

3. CONCEPTION DU SCHMA LOGIQUE ..............................................................................

3.1. Passage au relationnel : la mthode UML/R ...............................................................
3.1.1. Cas des entits et associations.................................................................................
3.1.2. Cas des gnralisations avec hritage..............................................................

672
672
672
673

Sommaire XXVII

3.1.3. Cas des agrgations et collections ....................................................................... 675

3.1.4. Gnration de contraintes dintgrit ............................................................... 677
3.2. Passage lobjet-relationnel : UML/RO ou UML/OR? .................................... 678
4. AFFINEMENT DU SCHMA LOGIQUE ..............................................................................
4.1. Anomalies de mise jour.............................................................................................................
4.2. Perte dinformations .........................................................................................................................
4.3. Lapproche par dcomposition ................................................................................................
4.4. Lapproche par synthse................................................................................................................

679
679
680
681
683

5. DPENDANCES FONCTIONNELLES ....................................................................................

5.1. Quest-ce quune dpendance fonctionnelle ? ...........................................................
5.2. Proprits des dpendances fonctionnelles...................................................................
5.3. Graphe des dpendances fonctionnelles..........................................................................
5.4. Fermeture transitive et couverture minimale...............................................................
5.5. Retour sur la notion de cl de relation ..............................................................................

684
684
685
686
687
688

6. LES TROIS PREMIRES FORMES NORMALES ........................................................

6.1. Premire forme normale ...............................................................................................................
6.2. Deuxime forme normale ............................................................................................................
6.3. Troisime forme normale .............................................................................................................
6.4. Proprits dune dcomposition en troisime forme normale......................
6.5. Algorithme de dcomposition en troisime forme normale...........................
6.6. Algorithme de synthse en troisime forme normale ..........................................
6.7. Forme normale de Boyce-Codd..............................................................................................

689
689
690
691
692
693
695
695

7. QUATRIME ET CINQUIME FORMES NORMALES .........................................

7.1. Dpendances multivalues ..........................................................................................................
7.2. Quatrime forme normale............................................................................................................
7.3. Dpendances de jointure ...............................................................................................................
7.4. Cinquime forme normale ..........................................................................................................

697
697
699
700
702

8. CONCEPTION DU SCHMA INTERNE ...............................................................................

8.1. Les paramtres prendre en compte ..................................................................................
8.2. Dnormalisation et groupement de tables .....................................................................
8.3. Partitionnemment vertical et horizontal ..........................................................................
8.4. Choix des index ....................................................................................................................................
8.5. Introduction de vues concrtes ................................................................................................

704
704
705
706
706
707

9. CONCLUSION ................................................................................................................................................. 707

10. BIBLIOGRAPHIE.......................................................................................................................................... 708

XXVIII BASES DE DONNES : OBJET ET RELATIONNEL

CHAPITRE XVIII CONCLUSION ET PERSPECTIVES ........................................... 713

1. INTRODUCTION........................................................................................................................................... 713
2. LES BD ET LE DCISIONNEL....................................................................................................... 714
2.1. Lanalyse interactive multidimensionnelle (OLAP) ............................................. 715
2.2. La fouille de donnes (Data Mining) ................................................................................ 715
3. BD ET WEB ........................................................................................................................................................ 715
4. BD MULTIMDIA........................................................................................................................................ 717
5. CONCLUSION ................................................................................................................................................. 718
6. BIBLIOGRAPHIE.......................................................................................................................................... 720

EXERCICES ..................................................................................................................................................................... 723

Partie 1

LES BASES

I Introduction (Introduction)
II Objectifs et architecture des SGBD
(DBMS Objectives and Architecture)
III Fichiers, hachage et indexation
(File management)
IV Bases de donnes rseaux et hirarchiques
(Legacy databases)
V Logique et bases de donnes (Logic and databases)

Chapitre I

INTRODUCTION

1. QUEST-CE QUUNE BASE DE DONNES ?

Les bases de donnes ont pris aujourdhui une place essentielle dans linformatique,
plus particulirement en gestion. Au cours des trente dernires annes, des concepts,
mthodes et algorithmes ont t dvelopps pour grer des donnes sur mmoires
secondaires ; ils constituent aujourdhui lessentiel de la discipline Bases de
Donnes (BD). Cette discipline est utilise dans de nombreuses applications. Il
existe un grand nombre de Systmes de Gestion de Bases de Donnes (SGBD) qui
permettent de grer efficacement de grandes bases de donnes. De plus, une thorie
fondamentale sur les techniques de modlisation des donnes et les algorithmes de
traitement a vu le jour. Les bases de donnes constituent donc une discipline
sappuyant sur une thorie solide et offrant de nombreux dbouchs pratiques.
Vous avez sans doute une ide intuitive des bases de donnes. Prenez garde cependant,
car ce mot est souvent utilis pour dsigner nimporte quel ensemble de donnes ; il
sagit l dun abus de langage quil faut viter. Une base de donnes est un ensemble de
donnes modlisant les objets dune partie du monde rel et servant de support une
application informatique. Pour mriter le terme de base de donnes, un ensemble de
donnes non indpendantes doit tre interrogeable par le contenu, cest--dire que lon
doit pouvoir retrouver tous les objets qui satisfont un certain critre, par exemple tous
les produits qui cotent moins de 100 francs. Les donnes doivent tre interrogeables

4 BASES DE DONNES : OBJET ET RELATIONNEL

selon nimporte quel critre. Il doit tre possible aussi de retrouver leur structure, par
exemple le fait quun produit possde un nom, un prix et une quantit.
Plutt que de disserter longuement sur le concept de bases de donnes, prcisons ce
quest un SGBD. Un SGBD peut tre peru comme un ensemble de logiciels systmes
permettant aux utilisateurs dinsrer, de modifier et de rechercher efficacement des
donnes spcifiques dans une grande masse dinformations (pouvant atteindre
quelques milliards doctets) partage par de multiples utilisateurs. Les informations
sont stockes sur mmoires secondaires, en gnral des disques magntiques. Les
recherches peuvent tre excute partir de la valeur dune donne dsigne par un
nom dans un ensemble dobjets (par exemple, les produits de prix infrieur
100 francs), mais aussi partir de relations entre objets (par exemple, les produits
commands par un client habitant Paris). Les donnes sont partages, aussi bien en
interrogation quen mise jour. Le SGBD rend transparent le partage, savoir donne
lillusion chaque utilisateur quil est seul travailler avec les donnes.
En rsum, un SGBD peut donc apparatre comme un outil informatique permettant la
sauvegarde, linterrogation, la recherche et la mise en forme de donnes stockes sur
mmoires secondaires. Ce sont l les fonctions premires, compltes par des fonctions souvent plus complexes, destines par exemple assurer le partage des donnes
mais aussi protger les donnes contre tout incident et obtenir des performances
acceptables. Les SGBD se distinguent clairement des systmes de fichiers par le fait
quils permettent la description des donnes (dfinition des types par des noms, des
formats, des caractristiques et parfois des oprations) de manire spare de leur utilisation (mise jour et recherche). Ils permettent aussi de retrouver les caractristiques dun type de donnes partir de son nom (par exemple, comment est dcrit un
produit). Le systme de fichiers est un composant de plus bas niveau ne prenant pas
en compte la structure des donnes. La tendance est aujourdhui intgrer le systme
de fichiers dans le SGBD, construit au-dessus.
En consquence, un SGBD se compose en premire approximation de trois couches
embotes de fonctions, depuis les mmoires secondaires vers les utilisateurs (voir
figure I.1) :
La gestion des rcipients de donnes sur les mmoires secondaires constitue traditionnellement la premire couche ; cest le gestionnaire de fichiers, encore appel
systme de gestion de fichiers. Celui-ci fournit aux couches suprieures des
mmoires secondaires idales adressables par objets et capables de recherches par
le contenu des objets (mcanismes dindexation notamment).
La gestion des donnes stockes dans les fichiers, lassemblage de ces donnes en
objets, le placement de ces objets dans les fichiers, la gestion des liens entre objets
et des structures permettant dacclrer les accs aux objets constituent la deuxime
couche ; cest le systme daccs aux donnes ou SGBD interne. Celui-ci repose
gnralement sur un modle de donnes internes, par exemple des tables relies par
des pointeurs.

Introduction 5

La fonction essentielle de la troisime couche consiste dans la mise en forme et la

prsentation des donnes aux programmes dapplications et aux utilisateurs interactifs. Ceux-ci expriment leurs critres de recherches laide de langages bass sur
des procdures de recherche progressives ou sur des assertions de logiques, en rfrenant des donnes drives de la base ; cest le SGBD externe qui assure dune
part lanalyse et linterprtation des requtes utilisateurs en primitives internes,
dautre part la transformation des donnes extraites de la base en donnes changes avec le monde extrieur.

SGBD externe
P. A.

Terminaux
Terminaux
Terminaux
Terminaux

SGBD interne
Gestionnaire
M.S.
de fichiers
SGBD interne

SGBD externe
P.A. = Programmes d'Application
M.S. = Mmoires Secondaires

Figure I.1 : Premire vue dun SGBD

Ces couches de fonctions constituent sans doute seulement la moiti environ du code
dun SGBD. En effet, au-del de ses fonctions de recherche, de rangement et de prsentation, un SGBD gre des problmes difficiles de partage et de cohrence de donnes. Il protge aussi les donnes contre les accs non autoriss. Ces fonctions qui
peuvent paratre annexes sont souvent les plus difficiles raliser et ncessitent beaucoup de code.
Pour tre complet, signalons quau-dessus des SGBD les systmes dinformations
intgrent aujourdhui de plus en plus souvent des ateliers de gnie logiciel permettant
de modliser les donnes dune base de donnes et de reprsenter les traitements associs laide de graphiques et de langages de spcifications. Ces outils daide la
conception, bien que non intgrs dans le SGBD, permettent de spcifier les descriptions des donnes. Ils sappuient pour cela sur les modles de donnes dcrits dans cet
ouvrage et supports par les SGBD.

6 BASES DE DONNES : OBJET ET RELATIONNEL

2. HISTORIQUE DES SGBD

Les SGBD ont bientt quarante ans dhistoire. Les annes 60 ont connu un premier
dveloppement des bases de donnes sous forme de fichiers relis par des pointeurs.
Les fichiers sont composs darticles stocks les uns la suite des autres et accessibles par des valeurs de donnes appeles cls. Les systmes IDS.I et IMS.I dvelopps respectivement Honeywell et IBM vers 1965 pour les programmes de
conqute spatiale, notamment pour le programme APOLLO qui a permis denvoyer
un homme sur la lune, sont les prcurseurs des SGBD modernes. Ils permettent de
constituer des chanes darticles entre fichiers et de parcourir ces chanes.
Les premiers SGBD sont rellement apparus la fin des annes 60. La premire gnration de SGBD est marque par la sparation de la description des donnes et de la
manipulation par les programmes dapplication. Elle concide aussi avec lavnement
des langages daccs navigationnels, cest--dire permettant de se dplacer dans des
structures de type graphe et dobtenir, un par un, des articles de fichiers. Cette premire gnration, dont laboutissement est marqu par les recommandations du
CODASYL, est base sur les modles rseau ou hirarchique, cest--dire des
modles de donnes organiss autour de types darticles constituant les nuds dun
graphe, relis par des types de pointeurs composant les arcs du graphe. Cette gnration a t domine par les SGBD TOTAL, IDMS, IDS 2 et IMS 2. Elle traite encore
aujourdhui une partie importante du volume de donnes gres par des SGBD.
La deuxime gnration de SGBD a grandi dans les laboratoires depuis 1970, partir
du modle relationnel. Elle vise enrichir mais aussi simplifier le SGBD externe
afin de faciliter laccs aux donnes pour les utilisateurs. En effet, les donnes sont
prsentes aux utilisateurs sous forme de relations entre domaines de valeurs, simplement reprsentes par des tables. Les recherches et mises jour sont effectues
laide dun langage non procdural standardis appel SQL (Structured Query
Language). Celui-ci permet dexprimer des requtes traduisant directement des
phrases simples du langage naturel et de spcifier les donnes que lon souhaite obtenir sans dire comment les accder. Cest le SGBD qui doit dterminer le meilleur plan
daccs possible pour valuer une requte. Cette deuxime gnration reprend, aprs
les avoir faits voluer et rendus plus souples, certains modles daccs de la premire
gnration au niveau du SGBD interne, afin de mieux optimiser les accs. Les systmes de deuxime gnration sont commercialiss depuis 1980. Ils reprsentent
aujourdhui lessentiel du march des bases de donnes. Les principaux systmes sont
ORACLE, INGRES, SYBASE, INFORMIX, DB2 et SQL SERVER. Ils supportent en
gnral une architecture rpartie, au moins avec des stations clients transmettant leurs
requtes de puissants serveurs grant les bases.
La troisime gnration a t dveloppe dans les laboratoires depuis le dbut des
annes 80. Elle commence apparatre fortement dans lindustrie avec les extensions
objet des systmes relationnels. Elle supporte des modles de donnes extensibles

Introduction 7

intgrant le relationnel et lobjet, ainsi que des architectures mieux rparties, permettant une meilleure collaboration entre des utilisateurs concurrents. Cette troisime
gnration est donc influence par les modles objets, intgrant une structuration
conjointe des programmes et des donnes en types, avec des possibilits de dfinir des
sous-types par hritage. Cependant, elle conserve les acquis du relationnel en permettant une vision tabulaire des objets et une interrogation via le langage SQL tendu aux
objets. Elle intgre aussi le support de rgles actives plus ou moins drives de la
logique. Ces rgles permettent de mieux maintenir la cohrence des donnes en rpercutant des mises jour dun objet sur dautres objets dpendants. Les systmes objetrelationnels tels Oracle 8, DB2 Universal Database ou Informix Universal Server, ce
dernier issu du systme de recherche Illustra, sont les premiers reprsentants des systmes de 3e gnration. Les systmes objets tels ObjectStore ou O2 constituent une
voie plus novatrice vers la troisime gnration. Tous ces systmes tentent de
rpondre aux besoins des nouvelles applications (multimdia, Web, CAO, bureautique, environnement, tlcommunications, etc.).
Quant la quatrime gnration, elle est dj en marche et devrait mieux supporter
Internet et le Web, les informations mal structures, les objets multimdias, laide la
prise de dcisions et lextraction de connaissances partir des donnes. Certes, il
devient de plus en plus dur de dvelopper un nouvel SGBD. On peut donc penser que
les recherches actuelles, par exemple sur linterrogation par le contenu des objets multimdias distribus et sur lextraction de connaissances (data mining) conduiront
une volution des SGBD de 3e gnration plutt qu une nouvelle rvolution. Ce fut
dj le cas lors du passage de la 2e la 3e gnration, la rvolution conduite par
lobjet ayant en quelque sorte choue : elle na pas russi renverser le relationnel,
certes bouscul et adapt lobjet. Finalement, lvolution des SGBD peut tre perue
comme celle dun arbre, des branches nouvelles naissant mais se faisant gnralement
absorber par le tronc, qui grossit toujours davantage.

3. PLAN DE CET OUVRAGE

Ce livre traite donc de tous les aspects des bases de donnes relationnelles et objet,
mais aussi objet-relationnel. Il est dcoup en quatre parties autonomes, elles-mmes
divises en chapitres indpendants, en principe de difficult croissante.
La premire partie comporte, aprs cette introduction, quatre chapitres fournissant
les bases indispensables une tude approfondie des SGBD.
Le chapitre II bauche le cadre gnral de ltude. Les techniques de modlisation de
donnes sont tout dabord introduites. Puis les objectifs et les fonctions des SGBD
sont dvelopps. Finalement, les architectures fonctionnelles puis oprationnelles des

8 BASES DE DONNES : OBJET ET RELATIONNEL

SGBD modernes sont discutes. Lensemble du chapitre est une introduction aux
techniques et problmes essentiels de la gestion des bases de donnes, illustres partir dun langage adapt aux entits et associations.
Le chapitre III se concentre sur la gestion des fichiers et les langages daccs aux
fichiers. Certains peuvent penser que la gestion de fichiers est aujourdhui dpasse. Il
nen est rien, car un bon SGBD sappuie avant tout sur de bonnes techniques daccs
par hachage et par index. Nous tudions en dtail ces techniques, des plus anciennes
aux plus modernes, bases sur les indexes multiples et les hachages dynamiques
multi-attributs ou des bitmaps.
Le chapitre IV traite des modles lgus par les SGBD de premire gnration. Le
modle rseau tel quil est dfini par le CODASYL et implant dans le systme IDS.II
de Bull est dvelopp. Des exemples sont donns. Le modle hirarchique dIMS est
plus succinctement introduit.
Le chapitre V introduit les fondements logiques des bases de donnes, notamment
relationnelles. Aprs un rappel succinct de la logique du premier ordre, la notion de
bases de donnes logique est prsente et les calculs de tuples et domaines, la base
des langages relationnels, sont introduits.
La deuxime partie est consacre au relationnel. Le modle et les techniques de
contrle et doptimisation associes sont approfondis.
Le chapitre VI introduit le modle relationnel de Codd et lalgbre relationnelle associe. Les concepts essentiels pour dcrire les donnes tels quils sont aujourdhui supports par de nombreux SGBD sont tout dabord dcrits. Les types de contraintes
dintgrit qui permettent dassurer une meilleure cohrence des donnes entre elles
sont prciss. Ensuite, les oprateurs de lalgbre sont dfinis et illustrs par de nombreux exemples. Enfin, les extensions de lalgbre sont rsumes et illustres.
Le chapitre VII est consacr ltude du langage standardis des SGBD relationnels,
le fameux langage SQL. Les diffrents aspects du standard, accept en 1986 puis
tendu en 1989 et 1992, sont tout dabord prsents et illustrs par de nombreux
exemples. La version actuelle du standard accepte en 1992, connue sous le nom de
SQL2, est dcrite avec concision mais prcision. Il sagit l du langage aujourdhui
offert, avec quelques variantes, par tous les SGBD industriels.
Le chapitre VIII traite des rgles dintgrit et des bases de donnes actives. Le langage
dexpression des contraintes dintgrit et des dclencheurs intgr SQL est tudi.
Puis, les diffrentes mthodes pour contrler lintgrit sont prsentes. Enfin, les notions
de base de donnes active et les mcanismes dexcution des dclencheurs sont analyss.
Le chapitre IX expose plus formellement le concept de vue, dtaille le langage de
dfinition et prsente quelques exemples simples de vues. Sont successivement abords : les mcanismes dinterrogation de vues, le problme de la mise jour des vues,
lutilisation des vues concrtes notamment pour les applications dcisionnelles et
quelques autres extensions possibles du mcanisme de gestion des vues.

Introduction 9

Le chapitre X prsente dabord plus prcisment les objectifs de loptimisation de

requtes et introduit les lments de base. Une large part est consacre ltude des
principales mthodes doptimisation logique puis physique. Les premires restructurent les requtes alors que les secondes dterminent le meilleur plan dexcution pour
une requte donne. Loptimisation physique ncessite un modle de cot pour estimer le cot de chaque plan dexcution afin de choisir le meilleur. Un tel modle est
dcrit, puis les stratgies essentielles permettant de retrouver un plan dexcution
proche de loptimal sont introduites.
La troisime partie dveloppe les approches objet et objet-relationnel. Les problmes
fondamentaux poss par lobjet sont analyss en dtail.
Le chapitre XI dveloppe lapproche objet. Les principes de la modlisation de donnes oriente objet sont tout dabord esquisss. Puis, les techniques plus spcifiques
aux bases de donnes objets, permettant dassurer la persistance et le partage des
objets, sont dveloppes. Enfin, ce chapitre propose une extension de lalgbre relationnelle pour manipuler des objets complexes.
Le chapitre XII prsente le standard de lODMG, en lillustrant par des exemples. Sont
successivement tudis : le contexte et larchitecture dun SGBDO conforme lODMG,
le modle abstrait et le langage ODL, un exemple de base et de schma en ODL, le langage OQL travers des exemples et des syntaxes types de requtes, lintgration dans un
langage de programmation comme Java et les limites du standard de lODMG.
Le chapitre XIII prsente le modle objet-relationnel, et son langage SQL3. Il dfinit
les notions de base drives de lobjet et introduites pour tendre le relationnel. Il
dtaille le support des objets en SQL3 avec de nombreux exemples. Il rsume les
caractristiques essentielles du langage de programmation de procdures et fonctions
SQL/PSM, appoint essentiel SQL pour assurer la compltude en tant que langage de
programmation. Il souligne les points obscurs du modle et du langage SQL3.
Le chapitre XIV prsente une synthse des techniques essentielles de loptimisation
des requtes dans les bases de donnes objet, au-del du relationnel. Les nombreuses
techniques prsentes sont issues de la recherche ; elles commencent aujourdhui
tre intgres dans les SGBD objet-relationnel et objet. Une bonne comprhension des
techniques introduites de parcours de chemins, dvaluation de cot de requtes, de
placement par groupes, de prise en compte des rgles smantiques, permettra sans nul
doute une meilleure optimisation des nouvelles applications.
La dernire partie traite trois aspects indpendants importants des bases de donnes :
extensions pour la dduction, gestion de transactions et techniques de conception.
Le chapitre XV dcrit les approches aux bases de donnes dductives. Plus prcisment, il est montr comment une interprtation logique des bases de donnes permet
de les tendre vers la dduction. Le langage de rgles Datalog est prsent avec ses
diverses extensions. Les techniques doptimisation de rgles rcursives sont approfondies. Lintgration de rgles aux objets est exemplifie laide de langages concrets
implments dans des systmes oprationnels.

10 BASES DE DONNES : OBJET ET RELATIONNEL

Le chapitre XVI essaie de faire le point sur tous les aspects de la gestion de transactions dans les SGBD centraliss. Aprs quelques rappels de base, nous traitons
dabord les problmes de concurrence. Nous tudions ensuite les principes de la gestion de transactions. Comme exemple de mthode de reprise intgre, nous dcrivons
la mthode ARIES implmente IBM, la rfrence en matire de reprise. Nous terminons la partie sur les transactions proprement dites en prsentant les principaux
modles de transactions tendus introduits dans la littrature. Pour terminer ce chapitre, nous traitons du problme un peu orthogonal de confidentialit.
Le chapitre XVII traite le problme de la conception des bases de donnes objet-relationnel. Cest loccasion de prsenter le langage de modlisation UML, plus prcisment les constructions ncessaires la modlisation de BD. Nous discutons aussi des
techniques dintgration de schmas. Le chapitre dveloppe en outre les rgles pour
passer dun schma conceptuel UML un schma relationnel ou objet-relationnel. La
thorie de la normalisation est intgre pour affiner le processus de conception. Les
principales techniques doptimisation du schma physique sont introduites.
Enfin, le chapitre XVIII couvre les directions nouvelles dvolution des SGBD : datawarehouse, data mining, Web et multimdia. Ces directions nouvelles, sujets de nombreuses recherches actuellement, font lobjet dun livre complmentaire du mme
auteur chez le mme diteur.

4. BIBLIOGRAPHIE
De nombreux ouvrages traitent des problmes soulevs par les bases de donnes.
Malheureusement, beaucoup sont en anglais. Vous trouverez la fin de chaque chapitre du prsent livre les rfrences et une rapide caractrisation des articles qui nous
ont sembl essentiels. Voici quelques rfrences dautres livres traitant de problmes
gnraux des bases de donnes que nous avons pu consulter. Des livres plus spcialiss sont rfrencs dans le chapitre traitant du problme correspondant.
[Date90] Date C.J., An Introduction to Database Systems, 5e edition, The Systems
Programming Series, volumes I (854 pages) et II (383 pages), Addison Wesley,
1990.
Ce livre crit par un des inventeurs du relationnel est tourn vers lutilisateur.
Le volume I traite des principaux aspects des bases de donnes relationnelles,
sans oublier les systmes bass sur les modles rseau et hirarchique. Ce
volume est divis en six parties avec des appendices traitant de cas de systmes.
La partie I introduit les concepts de base. La partie II prsente un systme relationnel type, en fait une vue simplifie de DB2, le SGBD dIBM. La partie III
approfondit le modle et les langages de manipulation associs. La partie IV
traite de lenvironnement du SGBD. La partie V est consacre la conception

Introduction 11

des bases de donnes. La partie VI traite des nouvelles perspectives : rpartition, dduction et systmes objets. Le volume II traite des problmes dintgrit, de concurrence et de scurit. Il prsente aussi les extensions du modle
relationnel proposes par Codd (et Date), ainsi quune vue densemble des
bases de donnes rparties et des machines bases de donnes.
[Delobel91] Delobel C., Lcluse Ch., Richard Ph., Bases de Donnes : Des Systmes
Relationnels aux Systmes Objets, 460 pages, Interditions, Paris, 1991.
Une tude de lvolution des SGBD, des systmes relationnels aux systmes
objets, en passant par les systmes extensibles. Un intrt particulier est port
sur les langages de programmation de bases de donnes et le typage des donnes. Le livre dcrit galement en dtail le systme O2, son langage CO2 et les
techniques dimplmentation sous-jacentes. Un livre en franais.
[Gardarin97] Gardarin G., Gardarin O., Le Client-Serveur, 470 pages, ditions
Eyrolles, 1997.
Ce livre traite des architectures client-serveur, des middlewares et des bases de
donnes rparties. Les notions importantes du client-serveur sont dgages et
expliques. Une part importante de louvrage est consacre aux middlewares et
outils de dveloppement objet. Les middlewares objets distribus CORBA et
DCOM sont analyss. Ce livre est un complment souhaitable au prsent
ouvrage, notamment sur les middlewares, les bases de donnes rparties et les
techniques du client-serveur.
[Gray91] Gray J. Ed., The Benchmark Handbook, Morgan & Kaufman Pub., San
Mateo, 1991.
Le livre de base sur les mesures de performances des SGBD. Compos de diffrents articles, il prsente les principaux benchmarks de SGBD, en particulier le
fameux benchmark TPC qui permet dchantillonner les performances des
SGBD en transactions par seconde. Les conditions exactes du benchmark dfinies par le Transaction Processing Council sont prcises. Les benchmarks
de luniversit du Madisson, AS3AP et Catell pour les bases de donnes objets
sont aussi prsents.
[Korth97] Silberschatz A., Korth H., Sudarshan S., Database System Concepts, 819
pages, Mc Graw-Hill Editions, 3e edition, 1997.
Un livre orient systme et plutt complet. Partant du modle entit-association, les auteurs introduisent le modle relationnel puis les langages des systmes commercialiss. Ils se concentrent ensuite sur les contraintes et sur les
techniques de conception de bases de donnes. Les deux chapitres qui suivent
sont consacrs aux organisations et mthodes daccs de fichiers. Les techniques des SGBD relationnels (reprises aprs pannes, contrle de concurrence,
gestion de transaction) sont ensuite exposes. Enfin, les extensions vers les systmes objets, extensibles et distribus sont tudies. Le dernier chapitre pr-

12 BASES DE DONNES : OBJET ET RELATIONNEL

sente des tudes de cas de systmes et deux annexes traitent des modles
rseaux et hirarchiques. La nouvelle bible des SGBD en anglais.
[Maier83] Maier D., The Theory of Relational Databases, Computer Science Press,
1983.
Le livre synthtisant tous les dveloppements thoriques sur les bases de donnes
relationnelles mens au dbut des annes 80. En 600 pages assez formelles,
Maier fait le tour de la thorie des oprateurs relationnels, des dpendances
fonctionnelles, multivalues, algbriques et de la thorie de la normalisation.
[Parsaye89] Parsaye K., Chignell M., Khoshafian S., Wong H., Intelligent Databases,
478 pages, Wiley Editions, 1989.
Un livre sur les techniques avances la limite des SGBD et de lintelligence
artificielle : SGBD objets, systmes experts, hypermdia, systmes textuels,
bases de donnes intelligentes. Le SGBD intelligent est la convergence de
toutes ces techniques et intgre rgles et objets.
[Ullman88] Ullman J.D., Principles of Database and Knowledge-base Systems,
volumes I (631 pages) et II (400 pages), Computer Science Press, 1988.
Deux volumes trs complets sur les bases de donnes, avec une approche plutt
fondamentale. Jeffrey Ullman dtaille tous les aspects des bases de donnes,
des mthodes daccs aux modles objets en passant par le modle logique. Les
livres sont finalement trs centrs sur une approche par la logique des bases de
donnes. Les principaux algorithmes daccs, doptimisation de requtes, de
concurrence, de normalisation, etc. sont dtaills. noter lauteur traite dans
un mme chapitre les systmes en rseau et les systmes objets, quil considre
de mme nature.
[Valduriez99] Valduriez P., Ozsu T., Principles of Distributed Database Systems, 562
pages, Prentice Hall, 2e dition,1999.
Le livre fondamental sur les bases de donnes rparties. Aprs un rappel sur les
SGBD et les rseaux, les auteurs prsentent larchitecture type dun SGBD
rparti. Ils abordent ensuite en dtail les diffrents problmes de conception dun
SGBD rparti : distribution des donnes, contrle smantique des donnes, valuation de questions rparties, gestion de transactions rparties, liens avec les
systmes opratoires et multibases. La nouvelle dition aborde aussi le paralllisme et les middlewares. Les nouvelles perspectives sont enfin voques.

Chapitre II

OBJECTIFS ET ARCHITECTURE
DES SGBD
1. INTRODUCTION
Mme si vous navez jamais utilis de systme de gestion de bases de donnes
(SGBD), vous avez certainement une ide de ce quest une base de donnes (BD) et
par l mme un SGBD. Une BD est peut-tre pour certains une collection de fichiers
relis par des pointeurs multiples, aussi cohrents entre eux que possible, organiss de
manire rpondre efficacement une grande varit de questions. Pour dautres, une
BD peut apparatre comme une collection dinformations modlisant une entreprise
du monde rel. Ainsi, un SGBD peut donc tre dfini comme un ensemble de logiciels
systmes permettant de stocker et dinterroger un ensemble de fichiers interdpendants, mais aussi comme un outil permettant de modliser et de grer les donnes
dune entreprise.
Les donnes stockes dans des bases de donnes modlisent des objets du monde rel,
ou des associations entre objets. Les objets sont en gnral reprsents par des articles
de fichiers, alors que les associations correspondent naturellement des liens entre
articles. Les donnes peuvent donc tre vues comme un ensemble de fichiers relis
par des pointeurs ; elles sont interroges et mises jour par des programmes dapplications crits par les utilisateurs ou par des programmes utilitaires fournis avec le

14 BASES DE DONNES : OBJET ET RELATIONNEL

SGBD (logiciels dinterrogation interactifs, diteurs de rapports, etc.). Les programmes sont crits dans un langage de programmation traditionnel appel langage de
3e gnration (C, COBOL, FORTRAN, etc.) ou dans un langage plus avanc intgrant
des facilits de gestion dcrans et ddition de rapports appel langage de 4e gnration (Visual BASIC, SQL/FORMS, MANTIS, etc.). Dans tous les cas, ils accdent
la base laide dun langage unifi de description et manipulation de donnes permettant les recherches et les mises jour (par exemple, le langage SQL). Cette vision
simplifie dun SGBD et de son environnement est reprsente figure II.1.

P1
Cobol

Pi

Pn

L4G

Langage d'accs unifi

SGBD
E/S disques

Disques

Figure II.1 : Composants dun environnement base de donnes

Lobjectif de ce chapitre est dessayer de clarifier la notion plus ou moins floue de

SGBD. Pour cela nous prsentons dabord les objectifs que ces systmes cherchent
atteindre. Bien sr, peu de SGBD satisfont pleinement tous ces objectifs, mais ils y
tendent tous plus ou moins. Ensuite, nous exposerons les mthodes et concepts de
base ncessaires la comprhension gnrale du fonctionnement des SGBD, puis
larchitecture fonctionnelle de rfrence propose par le groupe de normalisation
ANSI/X3/SPARC. Une bonne comprhension de cette architecture est essentielle la
comprhension des SGBD proposs jusqu ce jour. Pour conclure le chapitre, nous
tudierons diverses architectures oprationnelles proposes par des groupes de normalisation ou des constructeurs de SGBD, telles larchitecture client-serveur deux ou
trois states (2-tiers ou 3-tiers) implante aujourdhui par beaucoup de constructeurs.

Objectifs et architecture des SGBD 15

2. MODLISATION DES DONNES

Une ide centrale des bases de donnes est de sparer la description des donnes effectue par les administrateurs de la manipulation effectue par les programmes dapplication. La description permet de spcifier les structures et les types de donnes de lapplication alors que la manipulation consiste effectuer des interrogations, des insertions et des
mises jour. Ds 1965, lide de dcrire les donnes des applications de manire indpendante des traitements fut propose. Aujourdhui, plusieurs niveaux de description
grs par un SGBD permettent de raliser des abstractions progressives des donnes stockes sur disques, de faon sapprocher de la vision particulire de chaque utilisateur.

2.1. INSTANCES ET SCHMAS

Toute description de donnes consiste dfinir les proprits densembles dobjets
modliss dans la base de donnes, et non pas dobjets particuliers. Les objets particuliers sont dfinis par les programmes dapplications lors des insertions et mises jour
de donnes. Ils doivent alors vrifier les proprits des ensembles auxquels ils appartiennent. On distingue ainsi deux notions essentielles :
le type dobjet permet de spcifier les proprits communes un ensemble dobjets
en termes de structures de donnes visible et doprations daccs,
linstance dobjet correspond un objet particulier identifiable parmi les objets
dun type.
Bien quoccurrence soit aussi employ, on prfre aujourdhui le terme dinstance.
Nous prcisons ci-dessous ces notions en les illustrant par des exemples.
Notion II.1 : Type dobjet (Object type)
Ensemble dobjets possdant des caractristiques similaires et manipulables par des oprations
identiques.

EXEMPLES

1. Le type dobjet Entier = {0, 1 N } muni des oprations standards de larithmtique {+, *, /, } est un type dobjet lmentaire, support
par tous les systmes.
2. Le type dobjet Vin possdant les proprits Cru, Millsime, Qualit,
Quantit peut tre muni des oprations Produire et Boire, qui permettent respectivement daccrotre et de dcrotre la quantit. Cest un type dobjet
compos pouvant tre utilis dans une application particulire, grant par
exemple des coopratives vinicoles.

16 BASES DE DONNES : OBJET ET RELATIONNEL

3. Le type dobjet Entit possdant les proprits P1, P2Pn et muni des oprations Crer, Consulter, Modifier, Dtruire est un type dobjet gnrique qui permet de modliser de manire trs gnrale la plupart des objets du monde rel.
Notion II.2 : Instance dobjet (Object instance)
lment particulier dun type dobjets, caractris par un identifiant et des valeurs de proprits.

EXEMPLES

1. Lentier 10 est une instance du type Entier.

2. Le vin (Volnay, 1992, Excellent, 1000) est une instance du type Vin.
3. Lentit e(a1, a2, an), o a1, a2,an dsignent des valeurs particulires,
est une instance du type Entit.
Toute description de donnes seffectue donc au niveau du type, laide dun
ensemble dlments descriptifs permettant dexprimer les proprits densembles
dobjets et composant un modle de description de donnes. Ce dernier est souvent
reprsent par un formalisme graphique. Il est mis en uvre laide dun langage de
description de donnes (LDD). La description dun ensemble de donnes particulier,
correspondant par exemple une application, laide dun langage de description,
donne naissance un schma de donnes. On distingue gnralement le schma
source spcifi par les administrateurs de donnes et le schma objet rsultant de la
compilation du prcdent par une machine. Le schma objet est directement utilisable
par le systme de gestion de bases de donnes afin de retrouver et de vrifier les proprits des instances dobjets manipules par les programmes dapplications.
Notion II.3 : Modle de description de donnes (Data model)
Ensemble de concepts et de rgles de composition de ces concepts permettant de dcrire des donnes.
Notion II.4 : Langage de description de donnes (Data description language)
Langage supportant un modle et permettant de dcrire les donnes dune base dune manire assimilable par une machine.
Notion II.5 : Schma (Schema)
Description au moyen dun langage dtermin dun ensemble de donnes particulier.

2.2. NIVEAUX DABSTRACTION

Un objectif majeur des SGBD est dassurer une abstraction des donnes stockes sur

Objectifs et architecture des SGBD 17

disques pour simplifier la vision des utilisateurs. Pour cela, trois niveaux de description de donnes ont t distingus par le groupe ANSI/X3/SPARC [ANSI78,
Tsichritzis78]. Ces niveaux ne sont pas clairement distingus par tous les SGBD : ils
sont mlangs en deux niveaux dans beaucoup de systmes existants. Cependant, la
conception dune base de donnes ncessite de considrer et de spcifier ces trois
niveaux, certains pouvant tre pris en compte par les outils de gnie logiciel aidant
la construction des applications autour du SGBD.

2.2.1. Le niveau conceptuel

Le niveau central est le niveau conceptuel. Il correspond la structure canonique des
donnes qui existent dans lentreprise, cest--dire leur structure smantique inhrente
sans souci dimplantation en machine, reprsentant la vue intgre de tous les utilisateurs. La dfinition du schma conceptuel dune entreprise ou dune application nest
pas un travail vident. Ceci ncessite un accord sur les concepts de base que modlisent les donnes. Par exemple, le schma conceptuel permettra de dfinir :
1. les types de donnes lmentaires qui dfinissent les proprits lmentaires des
objets de lentreprise (cru dun vin, millsime, qualit, etc.) ;
2. les types de donnes composs qui permettent de regrouper les attributs afin de
dcrire les objets du monde rel ou les relations entre objets (vin, personne, buveur,
etc.) ;
3. les types de donnes composs qui permettent de regrouper les attributs afin de
dcrire les associations du monde rel (abus de vin par un buveur, production dun
vin par un producteur, etc.) ;
4. ventuellement, des rgles que devront suivre les donnes au cours de leur vie dans
lentreprise (lge dune personne est compris entre 0 et 150, tout vin doit avoir un
producteur, etc.).
Un exemple de schma conceptuel dfini en termes de types dobjets composs (souvent appels entits) et dassociations entre ces objets est reprsent figure II.2. Le
type dobjet Buveur spcifie les proprits dun ensemble de personnes qui consomment des vins. Le type dobjet Vin a t introduit ci-dessous. Une consommation de
vin (abusivement appele ABUS) associe un vin et un buveur. La consommation
seffectue une date donne en une quantit prcise.
Type dobjets :
BUVEUR(Nom, Prnom, Adresse)
VIN(Cru, Millsime, Qualit, Quantit)
Type dassociations :
ABUS(BUVEUR, VIN, Date, Quantit)

Figure II.2 : Exemple de schma conceptuel

18 BASES DE DONNES : OBJET ET RELATIONNEL

2.2.2. Le niveau interne

Le niveau interne correspond la structure de stockage supportant les donnes. La dfinition du schma interne ncessite au pralable le choix dun SGBD. Elle permet donc
de dcrire les donnes telles quelles sont stockes dans la machine, par exemple :
les fichiers qui les contiennent (nom, organisation, localisation) ;
les articles de ces fichiers (longueur, champs composants, modes de placement en
fichiers) ;
les chemins daccs ces articles (index, chanages, fichiers inverss).
Une implmentation possible des donnes reprsentes figure II.2 est illustre figure II.3.
Il existe un fichier index sur le couple (Cru, Millsime) dont chaque article contient successivement le cru, le millsime, la qualit, la quantit stocke de vin. Il existe un autre
fichier dcrivant les buveurs et leurs abus. Chaque article de ce deuxime fichier contient
le nom, le prnom et ladresse dun buveur suivi dun groupe rptitif correspondant aux
abus comprenant le nombre dabus et pour chacun deux un pointeur sur le vin bu, la date
et la quantit. Un index sur le nom du buveur permet daccder directement aux articles
de ce fichier. Un autre index permet aussi dy accder par la date des abus.
Fichier
BUVEURS
Nom

Fichier
VINS

Nom

Cru

Prnom

Millsime

Adresse

Qualit

NbAbus

Quantit

Cru
Millsime

RefVin
Date

Date
Quantit

Figure II.3 : Exemple de schma interne

2.2.3. Le niveau externe

Au niveau externe, chaque groupe de travail utilisant des donnes possde une description des donnes perues, appele schma externe. Cette description est effectue
selon la manire dont le groupe voit la base dans ses programmes dapplication. Alors

Objectifs et architecture des SGBD 19

quau niveau conceptuel et interne les schmas dcrivent toute une base de donnes,
au niveau externe ils dcrivent simplement la partie des donnes prsentant un intrt
pour un utilisateur ou un groupe dutilisateurs. En consquence, un schma externe est
souvent qualifi de vue externe. Le modle externe utilis est dpendant du langage
de manipulation de la base de donnes utilis. La figure II.4 donne deux exemples de
schma externe pour la base de donnes dont le schma conceptuel est reprsent
figure II.2. Il est souligner que la notion de schma externe permet dassurer une
certaine scurit des donnes. Un groupe de travail ne peut en effet accder quaux
donnes dcrites dans son schma externe. Les autres donnes sont ainsi protges
contre les accs non autoriss ou mal intentionns de la part de ce groupe de travail.

Identit_Buveurs
Nom
Buveurs_de_Vins

Adresse

Nom

Prnom

Prnom
NbAbus
Vins_Consomms
Cru

Cru

Millsime

Millsime
Quantit
Quantit_Consomme

SCHMA EXTERNE 1

SCHMA EXTERNE 2

Figure II.4 : Exemples de schmas externes

2.2.4. Synthse des niveaux de schmas

Retenez que, pour une base particulire, il existe un seul schma interne et un seul
schma conceptuel. En revanche, il existe en gnral plusieurs schmas externes. Un
schma externe peut tre dfini par un groupe dutilisateurs. partir de l, il est possible de construire des schmas externes pour des sous-groupes du groupe dutilisateurs considr. Ainsi, certains schmas externes peuvent tre dduits les uns des
autres. La figure II.5 illustre les diffrents schmas dune base de donnes centralise.

20 BASES DE DONNES : OBJET ET RELATIONNEL

Nous rappelons ci-dessous ce que reprsente chacun des niveaux de schma laide
dune notion.
Notion II.6 : Schma conceptuel (Conceptual Schema)
Description des donnes dune entreprise ou dune partie dune entreprise en termes de types
dobjets et de liens logiques indpendants de toute reprsentation en machine, correspondant une
vue canonique globale de la portion dentreprise modlise.
Notion II.7 : Schma interne (Internal Schema)
Description des donnes dune base en termes de reprsentation physique en machine, correspondant une spcification des structures de mmorisation et des mthodes de stockage et daccs utilises pour ranger et retrouver les donnes sur disques.
Notion II.8 : Schma externe (External Schema)
Description dune partie de la base de donnes extraite ou calcule partir de la base physique,
correspondant la vision dun programme ou dun utilisateur, donc un arrangement particulier de
certaines donnes.

Schma Externe 1

Schma Externe i

Schma Externe n

SCHMA CONCEPTUEL

SCHMA INTERNE

Figure II.5 : Les trois niveaux de schmas

2.3. LE MODLE ENTIT-ASSOCIATION

Les donnes lmentaires dcrivent des vnements atomiques du monde rel. Par
exemple, la donne 10 000 francs peut correspondre une instance de salaire ou

Objectifs et architecture des SGBD 21

de prix. Dupont Jules est un nom. Dans les bases de donnes, des instances de types
lmentaires sont groupes ensemble pour constituer un objet compos. Labstraction
qui concatne des donnes lmentaires (et plus gnralement des objets) est appele
lagrgation. La figure II.6 reprsente par un graphe lagrgation des donnes
(Volnay, 1978, Excellente, 100) pour constituer un objet compos dcrivant le vin
identifi par Volnay78.
Notion II.9 : Agrgation (Aggregation)
Abstraction consistant grouper des objets pour constituer des objets composs dune concatnation dobjets composants.

Volnay78

Volnay

1978

Excellente

100

Figure II. 6 : Exemple dagrgation de valeurs

Le modle entit-association [Chen76] est bas sur une perception du monde rel qui
consiste distinguer des agrgations de donnes lmentaires appeles entits et des
liaisons entre entits appeles associations. Intuitivement, une entit correspond un
objet du monde rel gnralement dfini par un nom, par exemple un vin, un buveur,
une voiture, une commande, etc. Une entit est une agrgation de donnes lmentaires. Un type dentit dfinit un ensemble dentits constitu par des donnes de
mme type. Les types de donnes agrges sont appels les attributs de lentit ; ils
dfinissent ses proprits.
Notion II.10 : Entit (Entity)
Modle dobjet identifi du monde rel dont le type est dfini par un nom et une liste de proprits.

Une association correspond un lien logique entre deux entits ou plus. Elle est souvent dfinie par un verbe du langage naturel. Une association peut avoir des proprits
particulires dfinies par des attributs spcifiques.
Notion II.11 : Association (Relationship)
Lien logique entre entits dont le type est dfini par un verbe et une liste ventuelle de proprits.

22 BASES DE DONNES : OBJET ET RELATIONNEL

Notion II.12 : Attribut (Attribute)

Proprit dune entit ou dune association caractrise par un nom et un type lmentaire.

Le modle entit-association, qui se rsume aux trois concepts prcdents, permet de

modliser simplement des situations dcrites en langage naturel : les noms correspondent aux entits, les verbes aux associations et les adjectifs ou complments aux proprits. Il sagit l bien sr dune abstraction trs schmatique dun sous-ensemble
rduit du langage naturel que nous illustrons par un exemple simple.
EXEMPLE

Les buveurs abusent de vins en certaines quantits des dates donnes. Tout
buveur a un nom, un prnom, une adresse et un type. Un vin est caractris par
un cru, un millsime, une qualit, une quantit et un degr.
Il est possible de se mettre daccord au niveau conceptuel pour reprsenter une
telle situation par le schma entit-association suivant :
entits = {BUVEUR, VIN};
association = {ABUS};
attributs = {Nom, Prnom, Adresse et Type pour BUVEUR; Cru, Millsime,
Qualit, Quantit et Degr pour VIN; Quantit et Date pour ABUS}.
Un des mrites essentiels du modle entit-association est de permettre une reprsentation graphique lgante des schmas de bases de donnes [Chen76]. Un rectangle
reprsente une entit ; un losange reprsente une association entre entits ; une ellipse
reprsente un attribut. Les losanges sont connects aux entits quils associent par des
lignes. Les attributs sont aussi connects aux losanges ou rectangles quils caractrisent. La figure II.7 reprsente le diagramme entit-association correspondant la
situation dcrite dans lexemple ci-dessus.

ABUS

BUVEUR

Nom

Prnom

VIN

Cru

Type

Adresse

Quantit

Date

Degr
Millsime

Quantit
Qualit

Figure II.7 : Exemple de diagramme entit-association

Objectifs et architecture des SGBD 23

3. OBJECTIFS DES SGBD

Le principal objectif dun SGBD est dassurer lindpendance des programmes aux
donnes, cest--dire la possibilit de modifier les schmas conceptuel et interne des
donnes sans modifier les programmes dapplications, et donc les schmas externes
vus par ces programmes. Cet objectif est justifi afin dviter une maintenance coteuse des programmes lors des modifications des structures logiques (le dcoupage en
champs et articles) et physiques (le mode de stockage) des donnes. Plus prcisment,
on distingue lindpendance physique qui permet de changer les schmas internes
sans changer les programmes dapplications, et lindpendance logique qui permet de
modifier les schmas conceptuels (par exemple, ajouter un type dobjet) sans changer
les programmes dapplications.
Afin dassurer encore une meilleure indpendance des programmes aux donnes
est rapidement apparue la ncessit de manipuler (cest--dire dinterroger et de
mettre jour) les donnes par des langages de haut niveau spcifiant celles que
lon veut traiter (le quoi) et non pas comment y accder. Ainsi, les procdures
daccs aux donnes restent invisibles aux programmes dapplication qui utilisent
donc des langages non procduraux. Ces langages rfrencent des descriptions
logiques des donnes (les schmas externes) stockes dans le dictionnaire de donnes. Les descriptions de donnes, qui existent plusieurs niveaux introduits cidessus, sont tablies par les administrateurs de donnes. Un SGBD se doit donc de
faciliter ladministration (cest--dire la cration et la modification de la description) des donnes. En rsum, voici les objectifs premiers dun SGBD :
Indpendance physique des programmes aux donnes
Indpendance logique des programmes aux donnes
Manipulation des donnes par des langages non procduraux
Administration facilite des donnes.
Les SGBD conduisent mettre en commun les donnes dune entreprise, ou au moins
dune application dans une base de donnes dcrite par un dictionnaire de donnes.
Cette mise en commun ne va pas sans problmes defficacit: de nombreux utilisateurs accdent simultanment aux donnes souvent situes sur un mme disque. La
base de donnes devient ainsi un goulot dtranglement. Il faut assurer globalement
lefficacit des accs. Il faut aussi garantir les utilisateurs contre les mises jour
concurrentes, et donc assurer le partage des donnes. Lenvironnement multi-usager
ncessite de protger la base de donnes contre les mises jour errones ou non autorises: il faut assurer la cohrence des donnes. Notamment, des donnes redondantes
doivent rester gales. Enfin, en cas de panne systme, ou plus simplement derreurs de
programmes, il faut assurer la scurit des donnes, en permettant par exemple de
repartir sur des versions correctes. En rsum, voici les objectifs additionnels des
SGBD, qui sont en fait des consquences des objectifs premiers :

24 BASES DE DONNES : OBJET ET RELATIONNEL

Efficacit des accs aux donnes

Partage des donnes
Cohrence des donnes
Redondance contrle des donnes
Scurit des donnes.

Dans la pratique, ces objectifs ne sont que trs partiellement atteints. Ci-dessous nous
analysons plus prcisment chacun deux.

3.1. INDPENDANCE PHYSIQUE

Bien souvent, les donnes lmentaires du monde rel sont assembles pour dcrire
les objets et les associations entre objets directement perceptibles dans le monde rel.
Bien que souvent deux groupes de travail assemblent diffremment des donnes lmentaires, il est possible au sein dune entreprise bien organise de dfinir une structure canonique des donnes, cest--dire un partitionnement en ensembles et sousensembles ayant des proprits bien dfinies et cohrentes avec les vues particulires.
Cet assemblage peut tre considr comme lintgration des vues particulires de
chaque groupe de travail. Il obit des rgles qui traduisent lessentiel des proprits
des donnes lmentaires dans le monde rel. Il correspond au schma conceptuel
dune base de donnes.
Par opposition, la structure de stockage des donnes appartient au monde des informaticiens et na donc un sens que dans lunivers du systme informatique. Le schma
interne dcrit un assemblage physique des donnes en articles, fichiers, chemins
daccs (organisation et mthode daccs des fichiers, modes de placement des
articles dans les fichiers, critres de tri, chanages) sur des mmoires secondaires.
Cet assemblage propre au monde informatique doit tre bas sur des considrations de
performances et de souplesse daccs.
Un des objectifs essentiels des SGBD est donc de permettre de raliser lindpendance des structures de stockage aux structures de donnes du monde rel
[Stonebraker74], cest--dire entre le schma interne et le schma conceptuel. Bien
sr, ces deux schmas dcrivent les mmes donnes, mais des niveaux diffrents. Il
sagit donc de pouvoir modifier le schma interne sans avoir modifier le schma
conceptuel, en tenant compte seulement des critres de performance et de flexibilit
daccs. On pourra par exemple ajouter un index, regrouper deux fichiers en un, changer lordre ou le codage des donnes dans un article, sans mettre en cause les entits
et associations dfinies au niveau conceptuel.
Les avantages de lindpendance physique peuvent tre facilement compris si lon
considre les inconvnients de la non-indpendance physique. Celle-ci impliquerait
que la manire dont les donnes sont organises sur mmoire secondaire soit directe-

Objectifs et architecture des SGBD 25

ment limage de lorganisation canonique de donnes dans le monde rel. Pour permettre de conserver les possibilits doptimisation de performances vitales aux systmes informatiques, les notions de mthodes daccs, modes de placement, critres
de tri, chanages et codages de donnes devraient directement apparatre dans le
monde rel et donc dans les applications. Tout changement informatique devrait alors
tre rpercut dans la vie dune entreprise et par consquent impliquerait une reconstruction des applications. Cela est bien sr impraticable, do la ncessit dindpendance des structures de stockages aux donnes du monde rel.

3.2. INDPENDANCE LOGIQUE

Nous avons admis ci-dessus lexistence dun schma conceptuel modlisant les objets
et associations entre objets dans le monde rel. Ce schma rsulte dune synthse des
vues particulires de chaque groupe de travail utilisant la base de donnes, cest--dire
dune intgration de schmas externes. En consquence, chaque groupe de travail ralisant une application doit pouvoir assembler diffremment les donnes pour former
par exemple les entits et les associations de son schma externe, ou plus simplement
des tables quil souhaite visualiser. Ainsi, chacun doit pouvoir se concentrer sur les
lments constituant son centre dintrt, cest--dire quun utilisateur doit pouvoir ne
connatre quune partie des donnes de la base au travers de son schma externe,
encore appel vue.
Il est donc souhaitable de permettre une certaine indpendance des donnes vues par
les applications la structure canonique des donnes de lentreprise dcrite dans le
schma conceptuel. Lindpendance logique est donc la possibilit de modifier un
schma externe sans modifier le schma conceptuel. Elle assure aussi lindpendance
entre les diffrents utilisateurs, chacun percevant une partie de la base via son schma
externe, selon une structuration voire un modle particulier.
Les avantages de lindpendance logique [Date71] sont les suivants :
permettre chaque groupe de travail de voir les donnes comme il le souhaite ;
permettre lvolution de la vue dun groupe de travail (dun schma externe) sans
remettre en cause, au moins dans une certaine mesure, le schma conceptuel de
lentreprise ;
permettre lvolution dun schma externe sans remettre en cause les autres schmas externes.
En rsum, il doit tre possible dajouter des attributs, den supprimer dautres,
dajouter et de supprimer des associations, dajouter ou de supprimer des entits, etc.,
dans des schmas externes mais aussi dans le schma conceptuel sans modifier la plus
grande partie des applications.

26 BASES DE DONNES : OBJET ET RELATIONNEL

3.3. MANIPULATION DES DONNES

PAR DES LANGAGES NON PROCDURAUX
Les utilisateurs, parfois non professionnels de linformatique, doivent pouvoir manipuler simplement les donnes, cest--dire les interroger et les mettre jour sans prciser les algorithmes daccs. Plus gnralement, si les objectifs dindpendance sont
atteints, les utilisateurs voient les donnes indpendamment de leur implantation en
machine. De ce fait, ils doivent pouvoir manipuler les donnes au moyen de langages
non procduraux, cest--dire en dcrivant les donnes quils souhaitent retrouver (ou
mettre jour) sans dcrire la manire de les retrouver (ou de les mettre jour) qui est
propre la machine. Les langages non procduraux sont bass sur des assertions de
logique du premier ordre. Ils permettent de dfinir les objets dsirs au moyen de relations entre objets et de proprits de ces objets.
Deux sortes dutilisateurs manipulent en fait les bases de donnes : les utilisateurs
interactifs et les programmeurs. Les utilisateurs interactifs peuvent interroger voire
mettre jour la base de donnes. Ils sont parfois non informaticiens et rclament des
langages simples. De tels langages peuvent tre formels (logique du premier ordre) ou
informels (menus). Une large varit de langages interactifs doivent tre supports par
un SGBD, depuis les langages de commandes semi-formels jusquaux langages graphiques, en passant par linterrogation par menus ou par formes. La limite suprieure
de tels langages est le langage naturel, qui reste cependant en gnral trop complexe
et lourd pour interroger les bases de donnes.
Les programmeurs crivent des programmes en utilisant des langages traditionnels
dits de 3e gnration (C, COBOL, PL1, etc.), des langages plus rcents orients objet
tels C++ ou Java ou des langages de 4e gnration (VB, PL/SQL, FORT, etc.). Ces
derniers regroupent des instructions de programmation structure (WHILE, IF, CASE,
etc.), des expressions arithmtiques, des commandes daccs la base de donnes et
des commandes ddition et entre de messages (menus droulants, gestion de
fentres, rapports imprims, etc.). Ils sont de plus en plus souvent orients objets.
Dans tous les cas, il est important que le SGBD fournisse les commandes ncessaires
de recherche et mise jour de donnes pour pouvoir accder aux bases. Une intgration harmonieuse avec le langage de programmation, qui traite en gnral un objet la
fois, est souhaitable.

3.4. ADMINISTRATION FACILITE DES DONNES

Un SGBD doit fournir des outils pour dcrire les donnes, la fois leurs structures de
stockage et leurs prsentations externes. Il doit permettre le suivi de ladquation de
ces structures aux besoins des applications et autoriser leur volution aise. Les fonc-

Objectifs et architecture des SGBD 27

tions qui permettent de dfinir les donnes et de changer leur dfinition sont appeles
outils dadministration des donnes. Afin de permettre un contrle efficace des donnes, de rsoudre les conflits entre divers points de vue pas toujours cohrents, de
pouvoir optimiser les accs aux donnes et lutilisation des moyens informatiques, on
a pens centraliser ces fonctions entre les mains dun petit groupe de personnes hautement qualifies, appeles administrateurs de donnes.
En fait, la centralisation des descriptions de donnes entre les mains dun groupe spcialis a souvent conduit des difficults dorganisation. Aussi, lvolution des SGBD
modernes tend fournir des outils permettant de dcentraliser la description de donnes, tout en assurant une cohrence entre les diverses descriptions partielles. Un dictionnaire de donnes dynamique pourra ainsi aider les concepteurs de bases de donnes. Pour permettre une volution rapide, les descriptions de donnes devront tre
faciles consulter et modifier. Lvolution va donc vers le dveloppement doutils
intgrs capables de faciliter ladministration des donnes et dassurer la cohrence
des descriptions.

3.5. EFFICACIT DES ACCS AUX DONNES

Les performances en termes de dbit (nombre de transactions types excutes par
seconde) et de temps de rponse (temps dattente moyen pour une requte type) sont
un problme cl des SGBD. Lobjectif de dbit lev ncessite un overhead minimal
dans la gestion des tches accomplie par le systme. Lobjectif de bons temps de
rponse implique quune requte courte dun utilisateur nattende pas une requte
longue dun autre utilisateur. Il faut donc partager les ressources (units centrales, units dentres-sorties) entre les utilisateurs en optimisant lutilisation globale et en vitant les pertes en commutation de contextes.
Le goulot dtranglement essentiel dans les systmes de bases de donnes reste les
E/S disques. Une E/S disque cote en effet quelques dizaines de millisecondes. Afin
de les viter, on utilisera une gestion de tampons en mmoire centrale dans de vritables mmoires caches des disques, afin quun grand nombre daccs aux donnes se
fasse en mmoire. Un autre facteur limitatif est d lutilisation de langages non procduraux trs puissants afin dinterroger et mettre jour la base de donnes. Ainsi, il
devient possible de demander en une requte le tri dun grand volume de donnes. Il
devient donc aussi ncessaire doptimiser lactivit de lunit centrale pour traiter les
oprations en mmoire. En rsum, un SGBD devra chercher optimiser une fonction
de cot de la forme C(Q) = a * ES(Q) + b * UC(Q) pour un ensemble typique de
requtes (recherches et mises jour) Q ; ES(Q) est le nombre dentres-sorties ralises pour la requte Q et UC(Q) est le temps unit centrale dpens ; a et b sont des
facteurs convertissant entres-sorties et temps dunit centrale en cots.

28 BASES DE DONNES : OBJET ET RELATIONNEL

3.6. REDONDANCE CONTRLE DES DONNES

Dans les systmes classiques fichiers non intgrs, chaque application possde ses
donnes propres. Cela conduit gnralement de nombreuses duplications de donnes
avec, outre la perte en mmoire secondaire associe, un gchis important en moyens
humains pour saisir et maintenir jour plusieurs fois les mmes donnes. Avec une
approche base de donnes, les fichiers plus ou moins redondants seront intgrs en un
seul fichier partag par les diverses applications. Ladministration centralise des donnes conduisait donc naturellement la non-duplication physique des donnes afin
dviter les mises jour multiples.
En fait, avec les bases de donnes rparties sur plusieurs calculateurs interconnects,
il est apparu souhaitable de faire grer par le systme des copies multiples de donnes.
Cela optimise les performances en interrogation, en vitant les transferts sur le rseau
et en permettant le paralllisme des accs. On considre donc aujourdhui que la
redondance gre par le SGBD au niveau physique des donnes nest pas forcment
mauvaise. Il faudra par contre viter la redondance anarchique, non connue du systme, qui conduirait les programmes utilisateurs devoir mettre jour plusieurs fois
une mme donne. Il sagit donc de bien contrler la redondance, qui permet doptimiser les performances, en la grant de manire invisible pour les utilisateurs.

3.7. COHRENCE DES DONNES

Bien que les redondances anarchiques entre donnes soient vites par lobjectif prcdent, les donnes vues par lutilisateur ne sont pas indpendantes. Au niveau
densemble de donnes, il peut exister certaines dpendances entre donnes. Par
exemple, une donne reprsentant le nombre de commandes dun client doit correspondre au nombre de commandes dans la base. Plus simplement, une donne lmentaire doit respecter un format et ne peut souvent prendre une valeur quelconque. Par
exemple, un salaire mensuel doit tre suprieur 4 700 F et doit raisonnablement rester
infrieur 700 000 F. Un systme de gestion de bases de donnes doit veiller ce que
les applications respectent ces rgles lors des modifications des donnes et ainsi assurer
la cohrence des donnes. Les rgles que doivent explicitement ou implicitement
suivre les donnes au cours de leur volution sont appeles contraintes dintgrit.

3.8. PARTAGE DES DONNES

Lobjectif est ici de permettre aux applications de partager les donnes de la base dans
le temps mais aussi simultanment. Une application doit pouvoir accder aux donnes
comme si elle tait seule les utiliser, sans attendre mais aussi sans savoir quune
autre application peut les modifier concurremment.

Objectifs et architecture des SGBD 29

En pratique, un utilisateur excute des programmes gnralement courts qui mettent

jour et consultent la base de donnes. Un tel programme interactif, appel transaction,
correspond par exemple lentre dun produit en stock ou une rservation de place
davion. Il est important que deux transactions concurrentes (par exemple, deux rservations sur le mme avion) ne semmlent pas dans leurs accs la base de donnes (par
exemple, rservent le mme sige pour deux passagers diffrents). On cherchera donc
assurer que le rsultat dune excution simultane de transactions reste le mme que
celui dune excution squentielle dans un ordre quelconque des transactions.

3.9. SCURIT DES DONNES

Cet objectif a deux aspects. Tout dabord, les donnes doivent tre protges contre
les accs non autoriss ou mal intentionns. Il doit exister des mcanismes adquats
pour autoriser, contrler ou enlever les droits daccs de nimporte quel usager tout
ensemble de donnes. Les droits daccs peuvent galement dpendre de la valeur des
donnes ou des accs prcdemment effectus par lusager. Par exemple, un employ
pourra connatre les salaires des personnes quil dirige mais pas des autres employs
de lentreprise.
Dun autre ct, la scurit des donnes doit aussi tre assure en cas de panne dun
programme ou du systme, voire de la machine. Un bon SGBD doit tre capable de
restaurer des donnes cohrentes aprs une panne disque, bien sr partir de sauvegardes. Aussi, si une transaction commence une mise jour (par exemple un transfert
depuis votre compte en banque sur celui de lauteur) et est interrompue par une panne
en cours de mise jour (par exemple aprs avoir dbit votre compte en banque), le
SGBD doit assurer lintgrit de la base (cest--dire que la somme dargent gre
doit rester constante) et par suite dfaire la transaction qui a chou. Une transaction
doit donc tre totalement excute, ou pas du tout : il faut assurer latomicit des transactions, et ainsi garantir lintgrit physique de la base de donnes.

4. FONCTIONS DES SGBD

Cette section prsente les fonctions essentielles dun SGBD. Un SGBD permet de
dcrire les donnes des bases, de les interroger, de les mettre jour, de transformer
des reprsentations de donnes, dassurer les contrles dintgrit, de concurrence et
de scurit. Il supporte de plus en plus frquemment des fonctions avances pour la
gestion de procdures et dvnements. Toutes ces fonctionnalits sont illustres par
des exemples simples.

30 BASES DE DONNES : OBJET ET RELATIONNEL

4.1. DESCRIPTION DES DONNES

Un SGBD offre donc des interfaces pour dcrire les donnes. La dfinition des diffrents schmas est effectue par les administrateurs de donnes ou par les personnes
jouant le rle dadministrateur.
Notion II.13 : Administrateur de donnes (Data Administrator)
Personne responsable de la dfinition de schmas de bases de donnes.

Dans un SGBD ou un environnement de dveloppement de bases de donnes supportant trois niveaux de schmas, les administrateurs de donnes ont trois rles :
Administrateur de bases de donnes. Lexcutant de ce rle est charg de la dfinition du schma interne et des rgles de correspondance entre les schmas interne
conceptuel.
Administrateur dentreprise. Le porteur de ce rle est charg de la dfinition du
schma conceptuel.
Administrateur dapplication. Lattributaire est charg de la dfinition des schmas
externes et des rgles de correspondance entre les schmas externe et conceptuel.
Ces trois rles peuvent tre accomplis par les mmes personnes ou par des personnes
diffrentes. Un rle essentiel est celui dadministrateur dentreprise, qui inclut la dfinition des informations que contient la base de donnes au niveau smantique, par
exemple avec des diagrammes entit-association. La plupart des SGBD modernes
supportent seulement un schma interne et plusieurs schmas externes. Le schma
conceptuel est dfini en utilisant un outil daide la conception (par exemple au sein
dun atelier de gnie logiciel) sappuyant gnralement sur des interfaces graphiques
permettant dlaborer des diagrammes de type entit-association.
Quoi quil en soit, les diffrents schmas et procdures pour passer de lun lautre
sont stocks dans le dictionnaire des donnes. Celui-ci peut tre divis en deux dictionnaires : le dictionnaire dentreprise qui contient le schma conceptuel et les procdures et commentaires sappliquant sur ce schma, et le dictionnaire des bases qui
contient les schmas internes et externes, ainsi que les procdures de passage dun
niveau lautre. Tout dictionnaire contient en gnral des descriptions en langage
naturel permettant de prciser la signification des donnes. Un dictionnaire de donnes peut contenir des informations non strictement bases de donnes, telles que des
masques dcrans ou des programmes. Les informations sont souvent stockes en format source, mais aussi en format compil. Un dictionnaire de donnes organis sous
forme de base de donnes est appel mtabase.
Notion II.14 : Dictionnaire des donnes (Data Dictionnary)
Ensemble des schmas et des rgles de passage entre les schmas associs une base de donnes, combins une description de la signification des donnes.

Objectifs et architecture des SGBD 31

Notion II.15 : Mtabase (Metabase)

Dictionnaire de donnes organis sous forme de base de donnes qui dcrit donc les autres bases.

Un SGBD fournit des commandes permettant de dfinir les schmas interne, conceptuel et externe. Afin dillustrer concrtement cette fonctionnalit, voici les commandes essentielles permettant de crer un schma avec le seul modle prsent
jusque-l, cest--dire le modle entit-association. La syntaxe drive dune extension
du langage QUEL [Zook77] au modle entit-association.
Voici donc les commandes minimales ncessaires :
pour crer une base de donnes :
CREATDB <nom-de-base>

pour crer une entit :

CREATE ENTITY <nom-dentit> (<nom-dattribut> <type>
[{,<nom-dattribut> <type>}])

pour crer une association :

CREATE RELATIONSHIP <nom-dassociation> (<nom-dentit>
[{,<nom dentit>}], [{,<nom-dattribut> <type>}])

pour dtruire une entit ou une association :

DESTROY {<nom-de-relation> | <nom-dassociation>}

pour dtruire une base :

DESTROYDB <nom-de-base>.

Ces commandes permettent de crer un schma conceptuel entit-association. Elles

sont utilises dans la figure II.8 pour crer la base de donnes correspondant au
schma conceptuel de la figure II.7.
CREATE ENTITY Buveur
(Nom Char(16), Prnom Char(16), Adresse Text, Type Char(4));
CREATE ENTITY Vin
(Cru Char(10), Millsime Int, Qualit Char(10), Quantit Int, Degr Real)
CREATE RELATIONSHIP Abus
(Buveur, Vin, Date Date, Quantit Int)

Figure II.8 : Exemple de description de donnes

Dautres commandes sont ncessaires, par exemple pour crer le schma interne. Un
exemple typique ce niveau est une commande de cration dindex sur un ou plusieurs attributs dune entit :
CREATE INDEX ON <nom-dentit>
USING <nom-dattribut> [{,<nom-dattribut>}]

Nous verrons plus loin des commandes de cration de vues (schmas externes).

32 BASES DE DONNES : OBJET ET RELATIONNEL

4.2. RECHERCHE DE DONNES

Tout SGBD fournit des commandes de recherche de donnes. Les SGBD modernes
offrent un langage dinterrogation assertionnel permettant de retrouver les donnes
par le contenu sans prciser la procdure daccs. Les SGBD de premire gnration
offraient des langages procduraux permettant de rechercher un objet dans la base de
donnes par dplacements successifs. Afin dillustrer un langage de requte non procdural, nous introduisons informellement un langage driv du langage QUEL
adapt au modle entit-association.
Le langage QUEL [Zook77] est le langage de manipulation de donnes du systme
INGRES [Stonebraker76], un des premiers systmes relationnels dvelopp luniversit de Californie Berkeley et commercialis sur de nombreuses machines. Ce langage est aujourdhui peu utilis car il a t remplac par SQL, langage plus commercial. Il a cependant le mrite dtre la fois simple et didactique, car driv de la
logique du premier ordre. Nous proposons une variante simplifie tendue au modle
entit-association [Zaniolo83].
Afin dexprimer des questions, QUEL permet tout dabord la dfinition de variables
reprsentant un objet quelconque dune entit ou dune association. Une dfinition de
variables seffectue laide de la clause :
RANGE OF variable IS {nom-dentit | nom dassociation}.

La variable est associe avec lentit ou lassociation spcifie. Plusieurs variables

associes plusieurs entits ou associations peuvent tre dclares par une clause
RANGE. Les variables dclares demeurent en principe connues jusqu une nouvelle
dclaration ou la fin de session.
Dans le cas de la base de donnes cre figure II.8, on peut par exemple dfinir trois
variables :
RANGE OF B IS Buveur;
RANGE OF V IS Vin;
RANGE OF A IS Abus.

Une commande de recherche permet de retrouver les donnes de la base rpondant un

critre plus ou moins complexe, appel qualification. Une qualification est une expression logique (ET de OU par exemple) de critres simples, chaque critre permettant soit
de comparer un attribut une valeur, soit de parcourir une association. En QUEL, un
attribut est spcifi par X.Attribut, o X est une variable et Attribut un nom dattribut de
lentit ou de lassociation reprsente par la variable. Un critre simple sera donc de la
forme X.Attribut = valeur pour une recherche sur valeur, ou X.Entit = Y pour un parcours dassociation. Dautres fonctionnalits sont possibles, comme nous le verrons plus
loin dans cet ouvrage. Une qualification est une expression logique de critres simples.
Notion II.16 : Qualification de question (Query Qualification)
Expression logique construite avec des OU (OR), ET (AND), NON (NOT) de critres simples permettant dexprimer une condition que doit satisfaire les rsultats dune question.

Objectifs et architecture des SGBD 33

Une recherche sexprime alors laide de requte du type suivant, o la liste rsultat
est une suite dattributs de variables ou de fonctions appliques ces attributs :
RETRIEVE (liste rsultat)
[WHERE qualification] ;

Voici quelques questions simples afin dillustrer les capacits minimales dun SGBD.
(Q1) Rechercher les noms et adresses des buveurs :
RETRIEVE B.Nom, B.Adresse;

(Q2) Rechercher les crus et millsimes des vins de qualit excellente :

RETRIEVE V.Cru, V.Millsime
WHERE V.Qualit = Excellente ;

(Q3) Rechercher les noms des gros buveurs ainsi que les crus, dates et quantits de
vins quils ont consomm :
RETRIEVE B.Nom, V.Cru, A.Date, A.Quantit
WHERE B.Type = Gros AND A.Buveur = B AND A.Vin = V ;

A priori, un SGBD doit offrir un langage complet, cest--dire un langage permettant

de poser toutes les questions possibles sur la base de donnes. On limite cependant
aux langages du premier ordre la notion de compltude. Les questions peuvent faire
intervenir un grand nombre dentits et dassociations, des calculs, des quantificateurs
(quel que soit, il existe), des restructurations de donnes, etc. En restant au premier
ordre, il nest pas possible de quantifier des ensembles dobjets.
Notion II.17 : Langage complet (Complete Language)
Langage de requtes permettant dexprimer toutes les questions que lon peut poser en logique du
premier ordre une base de donnes.

4.3. MISE JOUR DES DONNES

Le concept de mise jour intgre la fois linsertion de donnes dans la base, la
modification de donnes et la suppression de donnes. Nous illustrons ces aspects par
une variation du langage QUEL adapt au modle entit association.
Le langage prsent comporte une commande pour insrer des instances dans la base
dont la syntaxe est la suivante :
APPEND [TO] <nom-dentit> [(<liste-dattributs>)]
(<liste-de-valeurs>) [{,(<liste-de-valeurs>)}] ;

Cette commande permet dajouter les instances dfinies par les listes de valeurs
lentit de nom <nom-dentit>. Plusieurs instances dentits peuvent ainsi tre ajoutes dans la base. La liste dattributs permet de spcifier les seuls attributs que lon
dsire documenter, les autres tant a priori remplacs par une valeur nulle signifiant

34 BASES DE DONNES : OBJET ET RELATIONNEL

inconnue. Par exemple, lajout du vin <Volnay, 1978, Excellente, 100> dans la base
seffectuera par la commande :
(U1) APPEND TO Vin (Cru, Millsime, Qualit, Quantit)
(Volnay, 1978, Excellente, 100) ;

Linsertion dinstances dassociation est plus dlicate car il faut insrer un enregistrement rfrenant des entits de la base. titre indicatif, cela peut tre fait par une
commande APPEND TO dans laquelle les rfrences aux entits connectes sont des
variables calcules par une qualification. On aboutit alors une insertion qualifie du
type :
APPEND [TO] <nom-dassociation> [(<liste-dattributs>)]
<liste-de-valeurs> [{,<liste-de-valeurs>}]
WHERE <qualification> ;

Une liste de valeurs peut alors comprendre des attributs extraits de la base par la qualification. Par exemple, la commande suivante insre un abus de Volnay 78 au buveur
Dupont :
(U2) APPEND TO abus(buveur, vin, date, quantit)
(V, B, 10-02-92, 100)
WHERE B.Nom = Dupont AND V.Cru = Volnay
AND V. Millsime = 1978 ;

La modification de donnes seffectue en gnral par recherche des donnes modifier laide dune qualification, puis par renvoi dans la base des donnes modifies.
La commande peut tre du style suivant :
REPLACE <variable><attribut> = <valeur>
[{,<attribut> = <valeur>}]
[WHERE qualification]

Elle permet de changer la valeur des attributs figurant dans la liste pour tous les tuples
de la variable satisfaisant la qualification. Par exemple, lajout de 1 000 litres aux
stocks de Volnay seffectuera par la commande (V est suppose une variable sur
lentit Vin) :
(U3) REPLACE V (Quantit = Quantit + 1.000)
WHERE V.Cru = Volnay ;

Finalement, il est aussi possible de supprimer des tuples dune base de donnes par la
commande trs simple :
DELETE variable
WHERE <qualification>

Par exemple, la suppression de tous les vins de millsime 1992 seffectue par :
(U4) DELETE V
WHERE V.Millsime = 1992 ;

Objectifs et architecture des SGBD 35

4.4. TRANSFORMATION DES DONNES

Comme il peut exister plusieurs niveaux de schmas grs par systme pour dcrire
un mme ensemble de donnes, un systme de gestion de base de donnes doit pouvoir assurer le passage des donnes depuis le format correspondant un niveau dans
le format correspondant un autre niveau. Cette fonction est appele transformation
de donnes.
Notion II.18 : Transformation de donnes (Data mapping)
Fonction effectuant la restructuration dinstances de donnes conformes un schma en instances
de donnes conformes un autre schma.

Dans un SGBD trois niveaux de schmas, il existera donc deux niveaux de transformation :
la transformation conceptuelle interne permettant de faire passer des instances de
donnes depuis le format conceptuel au format interne et rciproquement ;
la transformation externe conceptuelle permettant de faire passer des instances de
donnes depuis le format conceptuel au format externe et rciproquement.
titre dexemple, la figure II.9 (page suivante) reprsente la transformation dun
ensemble doccurrences de donnes depuis le format conceptuel indiqu au format
externe indiqu.
Pour tre capable deffectuer automatiquement la transformation des donnes dun
niveau un autre, un SGBD doit connatre les correspondances existant entre les
niveaux. Pour cela, lors de la dfinition des schmas, le groupe dadministration des
donnes doit expliciter comment les schmas se dduisent les uns des autres au
moyen de rgles de correspondance. Ces rgles sont souvent exprimer sous la forme
de questions.
Notion II.19 : Rgles de correspondance (Mapping rules)
Questions dfinissant les procdures de transformation des donnes depuis un niveau de schma
dans un autre niveau.

Dans les systmes de gestion de base de donnes classiques, les rgles de correspondance sont bien souvent mlanges avec les schmas. Il y a cependant intrt distinguer ces deux notions. Par exemple, le langage QUEL permet de dfinir une vue de la
base (schma externe) par une commande du type suivant :
DEFINE VIEW <nom dentit> (<liste-dattributs>) AS
RETRIEVE (liste rsultat)
[WHERE qualification] ;

36 BASES DE DONNES : OBJET ET RELATIONNEL

La rgle de correspondance entre lentit de la vue (une table en QUEL) et le schma

de la base est clairement exprime par une question. On pourra par exemple dfinir le
schma externe Gros_Buveurs comme suit, B dsignant une variable sur Buveur :
(V1) DEFINE VIEW Gros_Buveurs (Nom, Prnom, Adresse) AS
RETRIEVE B.Nom, B.Prnom, B.Adresse
WHERE B.Type = Gros;

Table Externe
Fantomas 10-02-93 212 Volnay
Fantomas 11-02-93 527 Chablis

Transformation
Conceptuel - Externe
Entit et Associations
Conceptuelles

Chablis
Drink-1

Fantomas

Fantomas

Gros

75016 Paris

10-02-93 212

11,8

Chablis
1981

Drink-2
Volnay
11-02-93 527
Volnay

1983

11,9

Transformation
Conceptuel - Interne
Fichiers Internes

Buveurs
Fantomas
75016 Paris
Gros

AbusVins
Chablis
1981
11,8
10-02-93
212
Volnay
1983
11,9
11-02-93
527

Figure II.9 : Transformation de donnes

Objectifs et architecture des SGBD 37

4.5. CONTRLE DE LINTGRIT DES DONNES

Comme on la vu au niveau des objectifs, un SGBD doit assurer le maintien de la
cohrence des donnes par rapport aux schmas (contrles de type), mais aussi entre
elles (contrle de redondance). On appelle contrainte dintgrit toute rgle implicite ou explicite que doivent suivre les donnes. Par exemple, si le SGBD supporte un
modle entit-association, les contraintes suivantes sont possibles :
1. Toute entit doit possder un identifiant unique attribu par lutilisateur. Pour les
vins, nous avons suppos jusque-l que cru et millsime constituaient un identifiant.
Il pourra tre plus sage de numroter les vins par un attribut numro de vin (not
NV). Cet attribut devra tre un identifiant unique, donc toujours document (non
nul). Une telle contrainte est souvent appel contrainte dunicit de cl.
2. Certaines associations doivent associer des instances dentit obligatoirement dcrites
dans la base. Ainsi, un abus ne peut tre enregistr que pour un buveur et un vin existants dans la base. Une telle contrainte est souvent appele contrainte rfrentielle.
3. Tout attribut dentit ou dassociation doit possder une valeur qui appartient son
type. Par exemple, une quantit doit tre un nombre entier. Il est mme possible de
prciser le domaine de variation permis pour un attribut ; par exemple, une quantit
de vin peut varier entre 0 et 10 000. Une telle contrainte est souvent appele
contrainte de domaine.
Notion II. 20 : Contrainte dintgrit (Integrity Constraint)
Rgle spcifiant les valeurs permises pour certaines donnes, ventuellement en fonction dautres
donnes, et permettant dassurer une certaine cohrence de la base de donnes.

En rsum, un grand nombre de type de contraintes dintgrit est possible. Celles-ci

gagnent tre dclares au SGBD par une commande spcifique DEFINE INTEGRITY. Le SGBD doit alors les vrifier lors des mises jour de la base.

4.6. GESTION DE TRANSACTIONS ET SCURIT

La gestion de transactions permet dassurer quun groupe de mises jour est totalement excut ou pas du tout. Cette proprit est connue sous le nom datomicit des
transactions. Elle est garantie par le SGBD qui connat lexistence de transactions
laide de deux commandes : BEGIN_TRANSACTION et END_TRANSACTION.
Ces commandes permettent dassurer que toutes les mises jour quelles encadrent
sont excutes ou quaucune ne lest.
Notion II.21 : Atomicit des transactions (Transaction Atomicity)
Proprit dune transaction consistant tre totalement excute ou pas du tout.

38 BASES DE DONNES : OBJET ET RELATIONNEL

Une transaction est donc un groupe de mises jour qui fait passer la base dun tat
un autre tat. Les tats successifs doivent tre cohrents et donc respecter les
contraintes dintgrit. Cette responsabilit incombe au programmeur qui code la transaction. Cette proprit est connue sous le nom de correction des transactions.
Notion II.22 : Correction des transactions (Transaction Correctness)
Proprit dune transaction consistant respecter la cohrence de la base de donnes en fin dexcution.

Lorsquune transaction est partiellement excute, les donnes peuvent passer par des
tats incohrents transitoires, qui seront corrigs par les mises jour suivantes de la
transaction. Pendant cette priode dactivit, les effets de la transaction ne doivent pas
tre visibles aux autres transactions. Cette proprit est connue sous le nom disolation des transactions ; lisolation doit tre assure par le SGBD.
Notion II.23 : Isolation des transactions (Transaction Isolation)
Proprit dune transaction consistant ne pas laisser visible lextrieur les donnes modifies
avant la fin de la transaction.

En rsum, un bon SGBD doit donc assurer les trois proprits prcdentes pour les
transactions quil gre : Atomicit, Correction, Isolation. Ces proprits sont parfois
rsumes par le sigle ACID, le D signifiant que lon doit aussi pouvoir conserver
durablement les mises jour des transactions (en anglais, durability). En plus, le
SGBD doit garantir la scurit des donnes. Rappelons que la scurit permet dviter
les accs non autoriss aux donnes par des mcanismes de contrle de droits daccs,
mais aussi de restaurer des donnes correctes en cas de pannes ou derreurs.

4.7. AUTRES FONCTIONS

De nombreuses autres fonctions se sont progressivement intgres aux SGBD. Par
exemple, beaucoup savent aujourdhui dclencher des procdures catalogues par
lutilisateur lors de lapparition de certaines conditions sur les donnes ou lors de
lexcution de certaines oprations sur certaines entits ou associations. Cette fonctionnalit est connue sous le nom de dclencheur, encore appel rflexe dans le
contexte des architectures client-serveur en relationnel. Les dclencheurs permettent
de rendre les bases de donnes actives, par exemple en dclenchant des procdures de
correction lors de lapparition de certains vnements. Il sagit l dune fonctionnalit
nouvelle qui prend de plus en plus dimportance.
Notion II.24 : Dclencheur (Trigger)
Mcanisme permettant dactiver une procdure catalogue lors de lapparition de conditions particulires dans la base de donnes.

Objectifs et architecture des SGBD 39

De manire plus gnrale, les SGBD sont amens supporter des rgles permettant
dinfrer (cest--dire de calculer par des raisonnements logiques) de nouvelles donnes partir des donnes de la base, lors des mises jour ou des interrogations. Cela
conduit la notion de SGBD dductif, capable de dduire des informations partir de
celles connues et de rgles de dduction.
Enfin, les SGBD sont aussi amens grer des objets complexes, tels des dessins
darchitecture ou des cartes de gographie, en capturant finement le dcoupage de ces
gros objets en sous-objets composants. Ces objets pourront tre atteints via des procdures elles-mmes intgres au SGBD. Cela conduit la notion de SGBD objets,
capable de grer des objets multiples manipuls par des fonctions utilisateurs.

5. ARCHITECTURE FONCTIONNELLE
DES SGBD
5.1. LARCHITECTURE TROIS NIVEAUX
DE LANSI/X3/SPARC
Les groupes de normalisation se sont penchs depuis fort longtemps sur les architectures de SGBD. la fin des annes 70, le groupe ANSI/X3/SPARC DBTG a propos
une architecture intgrant les trois niveaux de schmas : externe, conceptuel et
interne. Bien quancienne [ANSI78], cette architecture permet de bien comprendre les
niveaux de description et transformation de donnes possible dans un SGBD.
Larchitecture est articule autour du dictionnaire de donnes et comporte deux
parties :
1. un ensemble de modules (appels processeurs) permettant dassurer la description
de donnes et donc la constitution du dictionnaire de donnes ;
2. une partie permettant dassurer la manipulation des donnes, cest--dire linterrogation et la mise jour des bases.
Dans chacune des parties, on retrouve les trois niveaux interne, conceptuel et externe.
Larchitecture propose est reprsente figure II.10.
Les fonctions de chacun des processeurs indiqus sont les suivantes. Le processeur de
schma conceptuel compile le schma conceptuel et, dans le cas o il ny a pas
derreur, range ce schma compil dans le dictionnaire des donnes. Le processeur de
schma externe compile les schmas externes et les rgles de correspondance externe
conceptuel et, aprs une compilation sans erreur, range le schma compil et les

40 BASES DE DONNES : OBJET ET RELATIONNEL

rgles de correspondance dans le dictionnaire des donnes. Le processeur de schma

interne a un rle symtrique pour le schma interne.
Admin
Entreprise
1
Admin
BD

Processeur
de schma
Conceptuel

Processeur
de schma
Interne

Transformateur
Interne
Stockage

11

DICTIONNAIRE

Processeur
de schma
Externe

10

Transformateur
Externe
Conceptuel

14
Transformateur
Conceptuel
Interne

Admin
Application

12

9
Programme
dapplication

Systme
dE/S

13

Programmeur
dapplication

Figure II.10 : LArchitecture ANSI/X3/SPARC

Le processeur de transformation externe conceptuel traduit les manipulations externes

en manipulations conceptuelles et dans lautre sens les donnes conceptuelles en donnes externes. Une requte externe peut donner naissance plusieurs requtes au niveau
conceptuel. Le processeur de transformation conceptuel interne traduit les manipulations conceptuelles en manipulations internes et dans lautre sens les donnes internes
en donnes conceptuelles. Finalement, le processeur de transformation interne stockage traduit les manipulations internes en programmes daccs au systme de stockage
et dlivre les donnes stockes en format correspondant au schma interne.
Les diverses interfaces indiques correspondent successivement (les numros se rapportent la figure II.10) :
(1) Langage de description de donnes conceptuel, format source ; il permet
ladministrateur dentreprise de dfinir le schma conceptuel en format source. Il

Objectifs et architecture des SGBD 41

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)
(10)

(11)

correspond par exemple aux commandes CREATE ENTITY et CREATE RELATIONSHIP vues ci-dessus (paragraphe II.4.1).
Langage de description de donnes conceptuel, format objet ; il rsulte de la
compilation du prcdent et permet de ranger le schma objet dans le dictionnaire des donnes.
Description de donnes conceptuel, format ddition ; cette interface permet aux
administrateurs dapplications et de bases de consulter le schma conceptuel afin
de dfinir les rgles de correspondance. Il pourrait sagir par exemple dune
visualisation graphique des diagrammes entit-association.
Langages de description de donnes externes, format source ; ils peuvent tre
multiples si le SGBD supporte plusieurs modles de donnes. Ils permettent aux
administrateurs dapplications de dfinir les schmas externes et les rgles de
correspondance avec le schma conceptuel. Par exemple, la commande DEFINE
VIEW introduite ci-dessus illustre ce type de langage, qui permet donc de dfinir
des schmas externes encore appels vues.
Langages de description de donnes externes, format objet ; ils correspondent
la compilation des prcdents et permettent de ranger les schmas externes
objets dans le dictionnaire de donnes.
Langages de description de donnes internes, format source ; il permet ladministrateur de bases de donnes de dfinir le schma interne et les donnes de correspondance avec le schma conceptuel. Par exemple, la commande CREATE
INDEX vue ci-dessus (paragraphe II.4.1) se situe ce niveau dinterface.
Langage de description de donnes internes, format objet ; il correspond la
compilation du prcdent et permet de ranger le schma interne objet dans le dictionnaire des donnes.
Langages de manipulation de donnes externes, format source ; ils permettent
aux programmeurs dapplications, voire aux non-informaticiens, de manipuler
les donnes dcrites dans un schma externe. Ils comportent des commandes du
type RETRIEVE, APPEND, MODIFY et DELETE rfrenant les objets dcrits
dans un schma externe.
Langages de manipulation de donnes externes, format objet ; ils correspondent
aux schmas compils des prcdents.
Langage de manipulation de donnes conceptuelle, format objet ; il est gnr
par les processeurs de transformation externe conceptuel afin de manipuler les
donnes logiques dcrites dans le schma conceptuel. Ils comportent des primitives correspondant la compilation des commandes du type RETRIEVE,
APPEND, MODIFY et DELETE rfrenant cette fois les objets dcrits dans le
schma conceptuel.
Langage de manipulation de donnes interne, format objet ; il est gnr par le
processeur de transformation conceptuel interne afin de manipuler les donnes
internes. Il permet par exemple daccder aux articles de fichiers via des index.

42 BASES DE DONNES : OBJET ET RELATIONNEL

(12) Langage de stockage de donnes, format objet ; il correspond linterface du

systme de stockage de donnes. Il permet par exemple de lire ou dcrire une
page dans un fichier.
(13) Interface mmoires secondaires ; elle permet deffectuer les entres-sorties sur
les disques.
(14) Interface daccs au dictionnaire des donnes ; elle permet aux divers processeurs
de transformation daccder aux schmas objets et aux rgles de correspondance.

5.2. UNE ARCHITECTURE FONCTIONNELLE

DE RFRENCE
Larchitecture trois niveaux de schmas prsente ci-dessus permet de bien comprendre les niveaux de description et de manipulation de donnes. Cependant, elle
nest que peu suivie, la plupart des systmes intgrant le niveau interne et le niveau
conceptuel dans un seul niveau. En fait, le vritable niveau conceptuel est pris en
charge par les outils daide la conception lextrieur du SGBD, lors de la conception de lapplication. Nous proposons une architecture de rfrence (voir figure II.11)
plus proche de celles des SGBD actuels, base sur seulement deux niveaux de
schma : le schma et les vues. Le schma correspond une intgration des schmas
interne et conceptuel, une vue est un schma externe.

Mtabase

Analyseur

Analyse syntaxique
Analyse smantique
Gestion des schmas

Contrleur

Modification de requtes
Contrle d'intgrit
Contrle d'autorisation

Optimiseur

Ordonnancement
Optimisation
laboration d'un plan

Excuteur

Excution du plan
Mthodes d'accs
Contrle de concurrence
Atomicit des transactions

BD

Figure II.11 : Architecture typique dun SGBD

Objectifs et architecture des SGBD 43

Du point de vue de la description de donnes, un SGBD gre un dictionnaire de donnes, encore appel mtabase car souvent organis comme une base de donnes qui
dcrit les autres bases. Ce dictionnaire est aliment par les commandes de dfinition
du schma (par exemple CREATE ENTITY, CREATE RELATIONSHIP, CREATE
INDEX) et de dfinition des vues (par exemple DEFINE VIEW). Ces commandes
sont analyses et traites par le processeur danalyse (ANALYSEUR), plus spcifiquement par la partie traitant le langage de description de donnes de ce processeur.
Celle-ci fait souvent appel aux fonctions plus internes du SGBD pour grer le dictionnaire comme une vritable base de donnes.
Du point de vue de la manipulation des donnes, les requtes (par exemple,
RETRIEVE, APPEND, MODIFY, DELETE) sont tout dabord prises en compte par
lanalyseur de requtes. Celui-ci ralise lanalyse syntaxique (conformit la grammaire) et smantique (conformit la vue rfrence ou au schma) de la requte.
Celle-ci est alors traduite en format interne, les noms tant remplacs par des rfrences internes.
Une requte en format interne rfrenant une vue doit tout dabord tre traduite en
une (ou plusieurs) requte(s) rfrenant des objets existant dans la base, cest--dire
des objets dcrits au niveau du schma. Cette fonctionnalit, accomplie au niveau du
contrleur de requtes figure II.11, est souvent appele modification de requtes,
car elle consiste changer la requte en remplaant les rfrences aux objets de la vue
par leur dfinition en termes dobjets du schma. Cest aussi au niveau du contrleur
que sont pris en compte les problmes de contrle de droits daccs (autorisation de
lire ou dcrire un objet) et de contrle dintgrit lors des mises jour. Le contrle
dintgrit consiste vrifier que la base nest pas pollue lors des mises jour, cest-dire que les rgles de cohrence des donnes restent vrifies aprs mise jour.
Loptimiseur de requtes est un composant cl du SGBD. Son rle essentiel est
dlaborer un plan daccs optimis pour traiter la requte. Pour se faire, il dcompose
en gnral la requte en oprations daccs lmentaires (e.g., slection dindex, lecture darticle, etc.) et choisit un ordre dexcution optimal ou proche de loptimum
pour ces oprations. Il choisit aussi les mthodes daccs utiliser. Pour effectuer les
meilleurs choix, loptimiseur sappuie souvent sur un modle de cot qui permet
dvaluer le cot dun plan daccs avant son excution. Le rsultat de loptimisation
(le plan daccs optimis) peut tre sauvegard en mmoire pour des excutions multiples ultrieures ou excut directement puis dtruit.
Lexcuteur de plans a enfin pour rle dexcuter le plan daccs choisi et labor
par loptimiseur. Pour cela, il sappuie sur les mthodes daccs qui permettent
daccder aux fichiers via des index et/ou des liens. Cest aussi ce niveau que sont
grs les problmes de concurrence daccs et datomicit de transactions. Les techniques utilises dpendent beaucoup de larchitecture oprationnelle du SGBD qui
sexprime en termes de processus et de tches.

44 BASES DE DONNES : OBJET ET RELATIONNEL

5.3. LARCHITECTURE DU DBTG CODASYL

Le groupe de travail Data Base Task Group du comit CODASYL responsable du
dveloppement de COBOL a propos depuis 1971 des recommandations pour
construire un systme de bases de donnes [Codasyl71]. Ces recommandations comportent essentiellement des langages de description de donnes et de manipulation de
donnes orients COBOL que nous tudierons plus loin, mais aussi une recommandation darchitecture.
Larchitecture dun systme obissant aux recommandations CODASYL sarticule
autour du schma qui permet de dfinir les articles, leurs donnes et les liens entre ces
articles. Ce schma peut tre assimil au schma conceptuel de larchitecture
ANSI/X3/SPARC, bien que comportant, notre avis, pas mal de notions du niveau
interne. La structure de stockage des donnes est dfinie par le schma de stockage
qui correspond plus ou moins au schma interne ANSI. La notion de schma externe
est dfinie pour COBOL et est appele sous-schma. Un groupe de travail a galement propos des langages de description de sous-schmas pour FORTRAN ainsi
quun langage de manipulation associ. Larchitecture globale est reprsente
figure II.12.
Programme
Utilisateur

Programme
Utilisateur

Programme
Utilisateur

Sous-schma

Sous-schma

Sous-schma

DML

SCHMA

SCHMA DE
STOCKAGE

SGBD

OS

BD

Figure II.12 : Architecture du DBTG CODASYL

Objectifs et architecture des SGBD 45

6. ARCHITECTURES OPRATIONNELLES
DES SGBD
Depuis le milieu des annes 80, les SGBD fonctionnent selon larchitecture client-serveur. Nous introduisons ces architectures brivement ci-dessous.

6.1. LES ARCHITECTURES CLIENT-SERVEUR

Dun point de vue oprationnel, un SGBD est un ensemble de processus et de tches
qui supportent lexcution du code du SGBD pour satisfaire les commandes des utilisateurs. Depuis lavnement des architectures distribues autour dun rseau local, les
systmes sont organiss selon larchitecture client-serveur. Cette architecture a t
bauche dans un rapport du sous-groupe de lANSI/X3/SPARC appel DAFTG
(Database Architecture Framework Task Group) [ANSI86] et mise la mode la fin
des annes 80 par plusieurs constructeurs de SGBD.
Larchitecture client-serveur inclut le noyau dun SGBD tel que dcrit ci-dessus,
appel DMCS (Description Manipulation and Control Sub-system), qui fonctionne en
mode serveur. Autour de ce serveur sarticulent des processus attachs aux utilisateurs
supportant les outils et les interfaces externes. Le DMCS est construit sur le gestionnaire de fichiers ou de disques virtuels du systme opratoire. La figure II.13 (page
suivante) illustre cette architecture.
Notion II.25 : Architecture client-serveur (Client-server architecture)
Architecture hirarchise mettant en jeu dune part un serveur de donnes grant les donnes partages en excutant le code du SGBD avec dventuelles procdures applicatives, dautre part des
clients pouvant tre organiss en diffrents niveaux supportant les applications et la prsentation, et
dans laquelle les clients dialoguent avec les serveurs via un rseau en utilisant des requtes de type
question-rponse.

Le langage DL (Data Language) est le langage standard daccs au SGBD, support

par un protocole de niveau application pour le fonctionnement en mode rparti, appel
protocole daccs aux donnes distantes (Remote Data Access RDA). Ce protocole
est aujourdhui en bonne voie de standardisation. Il est dailleurs complt par un protocole de gestion de transactions rparties.
Il existe diffrentes variantes de larchitecture client-serveur, selon quun processus
serveur est associ chaque utilisateur, ou que plusieurs utilisateurs partagent un
mme processus serveur. Dans le premier cas, le serveur est monotche. Chaque processus client a un processus serveur associ. La machine supportant les serveurs doit
partager son temps entre eux. Les commutations de processus peuvent tre lourdes
(quelques millisecondes sur UNIX). De plus, les processus serveurs partageant les

46 BASES DE DONNES : OBJET ET RELATIONNEL

mmes donnes, il est ncessaire de les synchroniser, par exemple par des smaphores, afin dviter les problmes de concurrence daccs. Cela peut entraner des
pertes de temps importantes, et donc de mauvaises performances en prsence dusagers multiples.
CLIENT
Langages et outils de gestion de donnes

DL

SERVEUR
DMCS

i - DL
OS

BD

Figure II.13 : Larchitecture client-serveur

Aujourdhui, plusieurs systmes proposent un serveur multitche, capable de traiter

plusieurs requtes dutilisateurs diffrents en parallle. Cela est ralis grce un
multiplexage du serveur en tches, les commutations de tches tant assures par le
serveur lui-mme, au niveau dun gestionnaire de tches optimis pour les bases de
donnes. Une telle architecture multitche (en anglais, multi-thread) permet de
meilleures performances en prsence dun nombre important dutilisateurs.
Au-del du multi-thread, le besoin en performance a conduit partionner les traitements applicatifs de faon rduire les communications entre client et serveur. Ainsi,
le client peut invoquer des procdures applicatives qui manipulent la base directement
sur le serveur. Ces procdures applicatives lies la base sont appeles des procdures stockes. Elles vitent de multiples commandes et transferts de donnes sur le
rseau. Ceux-ci sont remplacs par linvocation de procdures stockes avec quelques
paramtres et la transmission des paramtres retour. Larchitecture obtenue permettant

Objectifs et architecture des SGBD 47

deux couches de traitement applicatifs est appele architecture deux strates (twotiered architecture).
Notion II.26 : Architecture client-serveur deux strates (Two-tiered client-server
architecture)
Architecture client-serveur compose : (i) dun serveur excutant le SGBD et ventuellement des pro-

La figure II.14 propose une vue plus dtaille dune architecture client-serveur deux
strates. Lapplication est crite laide dun outil applicatif, souvent un L4G. Elle
soumet ses demandes de services (requtes au SGBD ou invocation de procdures
stockes au middleware qui les transfert au serveur. Le middleware comporte un composant client et un composant serveur qui permettent les changes de commandes via
le protocole rseau. Sur la figure, il est appel outil de connectabilit. Si vous souhaitez en savoir plus sur le middleware, reportez-vous [Gardarin97].
Application
Outil Applicatif

Client

Outil de connectabilit
Protocole Rseau
Requtes
de services

Rsultats
Rseau local

Protocole Rseau
Outil de connectabilit
Serveur BD

Serveur

Procdures
Stockes

BD

Figure II.14 : Larchitecture client-serveur deux strates

Avec lapparition dInternet et du Web, les architectures client-serveur ont volu vers
des architectures trois strates (three-tiered architecture). Le client est responsable
de la prsentation. Il utilise pour cela des browsers Web. Le serveur dapplication ex-

48 BASES DE DONNES : OBJET ET RELATIONNEL

cute le code applicatif essentiel. Le serveur de donnes supporte le SGBD et gre

ventuellement des procdures stockes.
Notion II.27 : Architecture client-serveur trois strates (Three-tiered client-server
architecture)
Architecture client-serveur compose : (i) dun serveur de donnes excutant le SGBD et ventuellement des procdures applicatives ; (ii) dun serveur dapplication excutant le corps des applications ; (iii) de clients responsables des dialogues et de la prsentation des donnes selon les standards du Web.

Browser

Browser

..

Clients de
prsentation

Rseau Internet/Intranet

Service applicatifs
Outil Applicatif

Serveur
dapplication

Outil de connectabilit
Protocole Rseau
Requtes
de services

Rsultats
Rseau local

Protocole Rseau
Outil de connectabilit
Serveur BD

Procdures
Stockes

Serveur
de donnes

BD

Figure II.15 : Larchitecture client-serveur trois strates

Objectifs et architecture des SGBD 49

La figure II.15 illustre une telle architecture. Les middlewares mis en jeu sont beaucoup plus complexes.
Larchitecture client-serveur est aujourdhui bien adapte aux systmes rpartis autour
dun rseau local et/ou dInternet. Elle permet de multiples postes ou stations de travail distribus sur la plante de partager les mmes donnes. Celles-ci sont gres de
manire fiable et avec de bons contrles de concurrence au niveau du serveur. Un processus client sur la station de travail ou lordinateur personnel gre les applications de
lutilisateur qui mettent des requtes au serveur. Un client peut mme invoquer plusieurs serveurs : on parle alors darchitecture client-multiserveur. Linconvnient mais
aussi lavantage du client-serveur est de centraliser la gestion des donnes au niveau
du serveur.

6.2. LES ARCHITECTURES RPARTIES

Donnes
textuelles
Descriptions
des produits

Systmes
classiques

Site 1

Donnes
techniques
Site 2

Site 4
Oprations
des produits

Donnes de gestion
Commandes,
Clients, Factures
Rseau de communication

Donnes
gographiques
Site 5

Site 3

CLIENT

SERVEUR

Localisation
des clients

Figure II.16 : Exemple darchitecture rpartie

50 BASES DE DONNES : OBJET ET RELATIONNEL

Afin de rpondre la tendance centralisatrice de lapproche client-serveur, certains

SGBD prconisent une architecture rpartie. Une architecture rpartie fait interagir
plusieurs serveurs grant un ensemble de bases peru comme une seule base par les
utilisateurs.
Notion : Architecture BD rpartie (Distributed database architecture)
Architecture compose de plusieurs serveurs cooprant la gestion de bases de donnes composes de plusieurs sous-bases gres par un seul serveur, mais apparaissant comme des bases
uniques centralises pour lutilisateur.

La figure II.16 illustre une architecture rpartie. Celle-ci est compose de diffrents
serveurs munis de SGBD diffrents et spcialiss. Cest un exemple de base de donnes rpartie htrogne, encore appele base de donnes fdre. Nous ntudions
pas les bases de donnes rparties dans cet ouvrage. Lauteur pourra se reporter
[Gardarin97] et [Valduriez99] pour une tude plus complte des systmes de bases
de donnes rparties.

7. CONCLUSION
Dans ce chapitre, nous avons prsent les objectifs des systmes de gestion de bases
de donnes, puis les concepts et mthodes essentiels de ces systmes. Cela nous a
conduit tudier les architectures fonctionnelles, puis les architectures oprationnelles. Afin de concrtiser nos propos, nous avons introduit une variante du langage
QUEL pour dcrire et manipuler les donnes. Larchitecture propose en 1978 par le
groupe ANSI/X3/SPARC permet de bien comprendre les niveaux de schmas possible. Larchitecture fonctionnelle de rfrence est voisine de celle retenue dans le systme SABRINA [Gardarin86] ou encore de celle des systmes INGRES ou ORACLE.
Les architectures oprationnelles sont aujourdhui client-serveur, mais voluent de
plus en plus souvent vers le rparti.
Il est possible de rsumer ce chapitre en rappelant quun SGBD offre une interface de
description de donnes qui permet de documenter le dictionnaire de donnes. Le compilateur du langage de description gre cette mtabase. Un SGBD offre aussi une
interface de manipulation de donnes (recherches et mises jour) qui permet de modifier ou de retrouver des donnes dans la base. Le compilateur-optimiseur du langage
de manipulation gnre des plans daccs optimiss. Ceux-ci sont excuts par le processus serveur, qui gre aussi la concurrence et la fiabilit. Les requtes peuvent tre
mises par des programmes dapplications crits dans des langages plus ou moins traditionnels, ou par des utilisateurs travaillant en interactif partir dutilitaires.

Objectifs et architecture des SGBD 51

Les SGBD tels que prsents dans ce chapitre sappuient au niveau interne sur une
gestion de fichiers. Celle-ci peut tre une partie intgrante du systme opratoire. Elle
peut tre plus ou moins sophistique. Dans le chapitre suivant, nous allons tudier la
gestion de fichiers, de la plus simple la plus labore. Selon le niveau de sophistication du gestionnaire de fichiers sur lequel il est construit, un SGBD devra ou non intgrer des fonctionnalits de type gestion de fichiers au niveau interne. Aujourdhui, la
plupart des SGBD intgrent leurs propres mthodes daccs aux fichiers (parfois
appels segments), du type de celles que nous allons tudier dans le chapitre suivant.

8. BIBLIOGRAPHIE
[ANSI75] ANSI/X3/SPARC Study Group on Data Base Management Systems,
Interim Report , ACM SIGMOD Bulletin, vol. 7, n 2, ACM Ed., 1975.
Ce document prsente larchitecture ANSI/X3/SPARC et ses trois niveaux de
schmas.
[ANSI78] ANSI/X3/SPARC Study Group on Data Base Management Systems,
Framework Report on Database Management Systems , Information
Systems, vol. 3, n 3 1978.
Il sagit du document final prsentant larchitecture trois niveaux de schmas
de lANSI.
[ANSI86] ANSI/X3/SPARC Database Architecture Framework Task Group,
Reference Model for DBMS Standardization , ACM SIGMOD Record,
vol. 15, n 1, mars 1986.
Il sagit du document final prsentant ltude sur les architectures de SGBD du
groupe DAFTG. Celui-ci conseille de ne pas chercher standardiser davantage
les architectures, mais plutt de sefforcer de standardiser les langages.
[Astrahan76] Astrahan M., Blasgen M., Chamberlin D., Eswaran K., Gray. J.,
Griffiths P., King W., Lorie R., McJones P., Mehl J., Putzolu G., Traiger I.,
Wade B., Watson V., System R: Relational Approach to Database
Management , ACM Transactions on Database Systems, vol. 1, n 2, juin 1976.
Cet article prsente System R, le premier prototype de SGBD relationnel ralis
par IBM dans son centre de recherches de San Jos. System R comporte une
architecture deux niveaux de schma et deux processeurs essentiels : le RDS
(Relational Data System) qui comprend analyseur, traducteur et optimiseur, et
le RSS qui correspond lexcuteur. System R a donn naissance SQL/DS et
DB2.

52 BASES DE DONNES : OBJET ET RELATIONNEL

[Brodie86] Brodie M. Ed., On Knowledge Base Management Systems, Springer

Verlag Ed., Berlin, 1986.
Ce livre discute les problmes lis lintroduction des techniques de lintelligence artificielle au sein des SGBD. Les consquences en termes dobjectifs et
darchitecture sont analyses tout au long des multiples articles composant le
livre.
[Carey85] Carey M.J., Dewitt D.J., Extensible Database Systems , Islamodrada
Workshop, 1985, dans [Brodie86].
Cet article plaide pour une architecture extensible des SGBD, notamment au
niveau de loptimiseur. Il propose de raliser un optimiseur dirig par une
bibliothque de rgles spcifiant les techniques doptimisation.
[Codasyl71] CODASYL DBTG, Codasyl Data Base Task Group Report, ACM Ed.,
New-York, avril 1971.
Ce document prsente la synthse des travaux du CODASYL en termes darchitecture, de langage de description et de langage de manipulation de donnes
pour SGBD supportant le modle rseau. Le groupe CODASYL tait une manation du groupe de standardisation de COBOL. Il a tent de standardiser la
premire gnration de SGBD.
[Chen76] Chen P.P., The Entity-Relationship Model Towards a Unified View of
Data , ACM Transactions on Database Systems, vol. 1, n 1, Mars 1976.
Cet article introduit le modle entit-association pour dcrire la vue des donnes dune entreprise. En particulier, les diagrammes de Chen sont prsents. Il
est montr que le modle permet dunifier les diffrents points de vue.
[Date71] Date C.J., Hopewell P., File Definition and Logical Data Independance ,
ACM SIGFIDET Workshop on Data Description, Access and Control, ACM
Ed., New-York, 1971.
Lindpendance physique et logique est discute clairement pour la premire
fois. En particulier, les modifications de structures de fichiers qui doivent tre
possibles sans changer les programmes sont analyses.
[Gardarin86] Gardarin G., Kerherv B., Jean-Nol M., Pasquer F., Pastre D.,
Simon E., Valduriez P., Verlaine L., Vimont Y., SABRINA: un systme de
gestion de bases de donnes relationnel issu de la recherche , Techniques et
Sciences Informatique (TSI), Dunod Ed., vol. 5, n 6, 1986.
Cet article prsente le SGBD relationnel SABRINA ralis dans le projet
SABRE lINRIA, puis en collaboration avec plusieurs industriels, de 1979
1989. Ce systme avanc supporte une architecture extensible voisine de
larchitecture de rfrence prsente ci-dessus. Il est construit selon lapproche
client-serveur.

Objectifs et architecture des SGBD 53

[Gardarin97] Gardarin G., Gardarin O., Le Client-Serveur, 470 pages, ditions

Eyrolles, 1997.
Ce livre traite des architectures client-serveur, des middlewares et des bases de
donnes rparties. Les notions importantes du client-serveur sont clairement
expliques. Une part importante de louvrage est consacre aux middlewares et
outils de dveloppement objet. CORBA et DCOM sont analyss. Ce livre est un
complment souhaitable au prsent ouvrage, notamment sur les bases de donnes rparties et les techniques du client-serveur.
[Stonebraker74] Stonebraker M.R., A Functional View of Data Independance ,
ACM SIGMOD Workshop on Data Description, Access and Control, ACM Ed.,
mai 1974.
Un des premiers articles de Mike Stonebraker, lun des pres du systme
INGRES. Il plaide pour lintroduction de vues assurant lindpendance
logique.
[Stonebraker76] Stonebraker M., Wong E., Kreps P., Held G.D., The Design and
Implementation of Ingres , ACM Transactions on Database Systems, vol. 1,
n 3, septembre 1976.
Cet article dcrit le prototype INGRES ralis luniversit de Berkeley. Celuici supporte le langage QUEL. Il est compos de 4 processus correspondant
grossirement lanalyseur, au traducteur, loptimiseur et lexcuteur prsent ci-dessus. Ce prototype est lanctre du systme INGRES aujourdhui trs
populaire.
[Stonebraker80] Stonebraker M., Retrospection on a Database system , ACM
Transactions on Database Systems, vol. 5, n 2, mars 1980.
Cet article fait le bilan de la ralisation du systme INGRES. Il souligne
notamment limportance du support gnie logiciel pour la ralisation dun
SGBD. Par exemple, lorsquun module change de responsable, le nouveau responsable sempresse de le rcrire sous pretexte de non propret, etc.
[Stonebraker87] Stonebraker M., The Design of the POSTGRES Storage System ,
Int. Conf. on Very Large Databases, Morgan & Kauffman Ed., Brighton,
Angleterre, 1987.
M. Stonebraker prsente la conception du noyau de stockage du systme
POSTGRES, successeur dINGRES. Celui-ci tait entirement bas sur le
contrle de concurrence et le support de dclencheurs.
[Tsichritzis78] Tsichritzis D.C., Klug A. (diteurs), The ANSI/X3/SPARC Framework,
AFIPS Press, Montvale, NJ, 1978.
Une autre version du rapport final de lANSI/X3/SPARC avec ses trois niveaux
de schmas.

54 BASES DE DONNES : OBJET ET RELATIONNEL

[Valduriez99] Valduriez P., Ozsu T., Principles of Distributed Database Systems, 562
pages, Prentice Hall, 2e dition,1999.
Le livre fondamental sur les bases de donnes rparties en anglais. Aprs un
rappel sur les SGBD et les rseaux, les auteurs prsentent larchitecture type
dun SGBD rparti. Ils abordent ensuite en dtails les diffrents problmes de
conception dun SGBD rparti : distribution des donnes, contrle smantique
des donnes, valuation de questions rparties, gestion de transactions rparties, liens avec les systmes opratoires et multibases. La nouvelle dition
aborde aussi le paralllisme et les middlewares. Les nouvelles perspectives sont
enfin voques.
[Weldon79] Weldon J.L., The Practice of Data Base Administration , National
Computer Conference, AFIPS Ed., V.48, New York, 1979.
Cet article rsume les rsultats dune tude du rle des administrateurs de donnes travers une enqute ralise auprs de 25 dentre eux. Un appendice
permet plus particulirement de dfinir leurs tches : tablissement du schma
directeur, conception des bases de donnes, tests, contrles et support oprationnel.
[Zaniolo83] Zaniolo C., The Database Language GEM , ACM SIGMOD Int. Conf.
on Management of Data, San Jos, CA, 1983.
Cet article prsente une extension trs complte du langage QUEL pour le
modle entit-association. Cette extension a t implante au-dessus dune
machine bases de donnes excutant un langage proche de QUEL.
[Zook77] Zook W. et. al., INGRES Reference Manual, Dept. of EECS, University of
California, Berkeley, CA, 1977.
Ce document dcrit les interfaces externes de la premire version dINGRES et
plus particulirement le langage QUEL.

Chapitre III

FICHIERS, HACHAGE
ET INDEXATION
1. INTRODUCTION

Un SGBD inclut en son cur une gestion de fichiers. Ce chapitre est consacr
ltude des fichiers et de leurs mthodes daccs. Historiquement, la notion de fichier
a t introduite en informatique dans les annes 50, afin de simplifier lutilisation des
mmoires secondaires des ordinateurs et de fournir des rcipients de donnes plus
manipulables aux programmes. Au dbut, un fichier tait bien souvent limage dune
portion nomme de bande magntique. Puis, au fur et mesure de la sophistication
des systmes informatiques, les fichiers sont devenus plus structurs. Des mthodes
daccs de plus en plus performantes ont t labores. Aujourdhui, les fichiers sont
la base des grands systmes dinformation ; la gestion de fichiers est le premier
niveau dun SGBD.

Idalement, un gestionnaire de fichiers doit permettre le traitement par linformatique

de la gestion complte dune entreprise. Les donnes descriptives des objets grs par
lentreprise, ainsi que les programmes spcifiant les traitements appliqus aux donnes, doivent pouvoir tre stocks dans des fichiers grs par le systme informatique.
Les traitements de ces donnes peuvent tre excuts par lots, en fin de mois par
exemple, ou en fin de semaine, mais aussi (et cest en gnral plus difficile) lunit

56 BASES DE DONNES : OBJET ET RELATIONNEL

ds que survient un vnement dans le monde rel : on parle alors de traitement transactionnel, mode de traitement privilgi par les bases de donnes.

Un gestionnaire de fichiers devrait par exemple permettre de traiter lapplication

comptabilit dune socit de livraison. Cette application est reprsente figure III.1.
Elle gre les comptes des clients et dite les factures correspondant aux livraisons.
Pour calculer les montants facturer et dduire des comptes clients, un catalogue
des prix est utilis. Les traitements peuvent tre effectus en traitement par lots, en fin
de mois ; dans ce cas, les bordereaux de livraison du mois sont traits ensemble, par
exemple partir dun fichier de saisie. Le traitement dune livraison peut tre effectu
en transactionnel ; dans ce cas, la description de la livraison est tape en direct sur un
terminal et les traitements associs sont immdiatement excuts.

Livraisons

Factures

Saisie
Impression
Catalogue
des prix

Comptabilit

Fichier

Comptes
clients

Comptes
clients

Fichier

Fichier mis jour

Figure III.1 : Un exemple dapplication

Nous allons, dans ce chapitre, tudier plus spcifiquement la gestion des fichiers au
cur des SGBD. Un fichier est un rcipient de donnes identifi par un nom et contenant des informations systme ou utilisateur. La gestion des fichiers est une des fonctions essentielles offertes par les systmes opratoires. Cest en effet grce cette
fonction quil est possible de traiter et de conserver des quantits importantes de donnes, et de les partager entre plusieurs programmes. De plus, elle sert de base au
niveau interne des Systmes de Gestion de Bases de Donnes (SGBD) qui la compltent par des mthodes daccs spcifiques ou la reprennent totalement.

Ce chapitre introduit tout dabord les objectifs de la gestion des fichiers et les
concepts de base associs, puis tudie les fonctions accomplies par le noyau dun gestionnaire de fichiers. Enfin, et cest son objet essentiel, il prsente les principales
organisations et mthodes daccs de fichiers. Celles-ci sont groupes en deux

Fichiers, hachage et indexation 57

classes : (i) les mthodes par hachage qui appliquent une fonction de hachage lidentifiant des articles dun fichier, appel cl, afin de retrouver son emplacement dans le
fichier ; (ii) les mthodes indexes qui grent une table des matires du fichier afin
daccder aux articles.

2. OBJECTIFS ET NOTIONS DE BASE

Nous rappelons ici les notions fondamentales darchitecture dordinateur et de gestion

de fichiers. Le lecteur informaticien pourra sauter cette section, voire la suivante.

2.1. GESTION DES DISQUES MAGNTIQUES

Linformatisation de la gestion dune grande entreprise ncessite le stockage de

volumes de donnes importants bien souvent plusieurs milliards doctets. Il nest
pas possible de stocker de tels volumes de donnes en mmoire centrale. On est ainsi
conduit introduire des mmoires secondaires.
Notion III.1 : Mmoire secondaire (External Storage)
Mmoire non directement adressable par les instructions du processeur central, mais par des instructions dentres-sorties spcialises et dont les temps daccs sont trs suprieurs ceux de la
mmoire centrale.

Il existe diffrents types de mmoires secondaires : disques magntiques, disques

optiques numriques, bandes magntiques, cassettes, etc. Parmi les disques magntiques, on distingue les disques ttes fixes des disques ttes mobiles. Les premiers
ont des capacits variant de 1 100 millions doctets et des temps daccs de quelques
millisecondes. Au contraire, les disques ttes mobiles sont plus lents, mais supportent en gnral des capacits plus importantes. Les mini-disques des micro-ordinateurs sont dans cette catgorie, mais restent cependant de faible capacit (400 kilos
quelques mga-octets). loppos, les disques optiques numriques constituent une
technologie bas prix permettant darchiver plusieurs giga-octets sur un mme
disque. Ils ne sont malheureusement inscriptibles quune seule fois, bien que des
disques optiques rinscriptibles commencent apparatre.
Les disques magntiques les plus utiliss ont des diamtres de 3 14 pouces et sont
organiss en piles. IBM commence mme produire des disques de un pouce. Leur
capacit sest accrue depuis les annes 1955 pour atteindre plusieurs milliards doctets
aujourdhui. Les temps daccs se sont galement amliors pour avoisiner 10 20 ms

58 BASES DE DONNES : OBJET ET RELATIONNEL

en moyenne. Notons quils restent encore de lordre de 20 000 fois plus levs que
ceux des mmoires centrales. Nous appellerons une pile de disques un volume.
Notion III.2 : Volume (Disk Pack)
Pile de disques constituant une unit de mmoire secondaire utilisable.

Un volume disque est associ un tourne-disque. Les volumes peuvent tre fixes ou
amovibles. Si le volume est amovible, il est mont sur un tourne-disque pour utilisation puis dmont aprs. Les volumes amovibles sont monts et dmonts par les oprateurs, en gnral sur un ordre du systme. Un contrleur de disque contrle en gnral plusieurs tourne-disques. La notion de volume sapplique galement aux bandes
magntiques o un volume est une bande. Une unit peut alors comporter un ou plusieurs drouleurs de bande.

Un volume et lquipement de lecture-criture associ un tourne-disque sont reprsents figure III.2. Un volume se compose de p disques (par exemple 9), ce qui correspond 2p 2 surfaces magntises, car les deux faces externes ne le sont pas. Les
disques ttes mobiles comportent une tte de lecture-criture par surface. Cette tte
est accroche un bras qui se dplace horizontalement de manire couvrir toute la
surface du disque. Un disque est divis en pistes concentriques numrotes de 0 n
(par exemple n = 1024). Les bras permettant de lire/crire les pistes dun volume sont
solidaires, ce qui force leur dplacement simultan. Les disques tournent continment
une vitesse de quelques dizaines de tours par seconde. Lensemble des pistes, dcrit
quand les bras sont positionns, est appel cylindre.

Chaque piste dun disque supporte plusieurs enregistrements physiques appels secteurs, de taille gnralement constante, mais pouvant tre variable pour certains types
de disque. Le temps daccs un groupe de secteurs conscutifs est une des caractristiques essentielles des disques. Il se compose :
1. du temps ncessaire au mouvement de bras pour slectionner le bon cylindre
(quelques millisecondes des dizaines de millisecondes selon lamplitude du dplacement du bras et le type de disque) ;
2. du temps de rotation du disque ncessaire pour que lenregistrement physique
dsir passe devant les ttes de lecture/criture ; ce temps est appel temps de
latence ; il est de quelques millisecondes, selon la position de lenregistrement par
rapport aux ttes et selon la vitesse de rotation des disques ;
3. du temps de lecture/criture du groupe de secteurs, appel temps de transfert ; ce
temps est gal au temps de rotation multipli par la fraction de pistes lue, par
exemple 1/16 de 10 ms pour lire un secteur sur une piste de 16 secteurs avec un
disque tournant 100 tours par seconde.

Fichiers, hachage et indexation 59

(a) vue de cot

Cylindre interne
Cylindre externe

(b) vue de dessus

Figure III.2 : Volume amovible ttes mobiles et quipement de lecture/criture

Au total, les disques ont un temps daccs variable selon la distance qui spare lenregistrement auquel accder de la position des ttes de lecture/criture. La tendance
aujourdhui est de rduire cette variance avec des moteurs acclration constante
pour commander les mouvements de bras, et avec des quantits de donnes enregistres par cylindre de plus en plus importantes.

De plus en plus souvent, des volumes multiples organiss en tableaux de disques

sont utiliss pour composer des units fiables et de grande capacit (des dizaines de
milliards doctets). Ces systmes de mmorisation portent le nom de RAID
(Redundant Array of Inexpensive disques). On distingue le RAID 0 sans redondance
des RAID 1 6 qui grent des redondances. Avec ces derniers, diffrentes techniques
de redondance sont utilises lors des critures et lectures afin dassurer une grande
fiabilit. Le RAID 1 groupe les disques du tableau par deux et effectuent les critures
sur les deux disques, lun apparaissant donc comme le miroir de lautre. En cas de
panne dun disque, le disque miroir peut toujours tre utilis. Les RAID 2, 3 et 4
grent un disque de parit, respectivement au niveau bit, octet ou bloc. En cas de
panne dun disque, celui-ci peut tre reconstitu grce la parit. Les RAID 5 et 6
sont bass sur des redondances plus fortes, avec des codes cycliques (CRC). Ils permettent de rsister des doubles pannes. Les disques RAID permettent des performances en lecture et criture leves car de multiples contrleurs dentres-sorties
fonctionnent en parallle.

60 BASES DE DONNES : OBJET ET RELATIONNEL

2.2. INDPENDANCE DES PROGRAMMES

PAR RAPPORT AUX MMOIRES SECONDAIRES

Les disques magntiques et plus gnralement les mmoires secondaires doivent pouvoir tre utiliss par plusieurs programmes dapplication. En consquence, il faut pouvoir partager lespace mmoire secondaire entre les donnes des diverses applications.
Une gestion directe de cet espace par les programmes nest pas souhaitable car elle
interdirait de modifier lemplacement des donnes sans modifier les programmes
dapplication. Les adresses utilises par les programmes doivent tre indpendantes
de lemplacement des donnes sur disques. Il faut donc introduire des couches systmes intermdiaires permettant dassurer lindpendance des programmes vis--vis
de lemplacement des donnes sur les mmoires secondaires. Autrement dit, lallocation de la mmoire secondaire doit tre gre par le systme.
Dun autre ct, les progrs technologiques ne cessent damliorer le rapport performance/prix des mmoires secondaires. La densit des disques magntiques (nombre
de bits enregistrs/cm2) double approximativement tous les deux ans, ce qui permet
daccrotre les capacits de stockage et les performances. Un bon systme doit permettre aux utilisateurs de profiter des avances technologiques, par exemple en achetant des disques plus performants, et cela sans avoir modifier les programmes. En
effet, la reprogrammation cote trs cher en moyens humains. En rsum, il faut assurer lindpendance des programmes dapplication par rapport aux mmoires
secondaires. Cette indpendance peut tre dfinie comme suit :
Notion III.3 : Indpendance des programmes par rapport aux mmoires
secondaires (Program-Storage device independence)
Possibilit de changer les donnes de localit sur les mmoires secondaires sans changer les programmes.

Afin de raliser cette indpendance, on introduit des objets intermdiaires entre les
programmes dapplication et la mmoire secondaire. Ces objets sont appels fichiers.
Ainsi, les programmes dapplication ne connaissent pas les mmoires secondaires,
mais les fichiers qui peuvent tre implants sur diverses mmoires secondaires. Un
fichier peut tre dfini comme suit :
Notion III.4 : Fichier (File)
Rcipient dinformation caractris par un nom, constituant une mmoire secondaire idale, permettant dcrire des programmes dapplication indpendants des mmoires secondaires.

Un programme dapplication ne manipule pas globalement un fichier mais lit/crit et

traite des portions successives de celui-ci, correspondant en gnral un objet du
monde rel, par exemple un client, un compte, une facture. Une telle portion est appele article.

Fichiers, hachage et indexation 61

Notion III.5 : Article (Record)

lment composant dun fichier correspondant lunit de traitement par les programmes dapplication.

Les articles sont stocks dans les rcipients dinformation que constituent les fichiers.
Ils ne sont pas stocks nimporte comment, mais sont physiquement relis entre eux
pour composer le contenu dun fichier. Les structures des liaisons constituent lorganisation du fichier.
Notion III.6 : Organisation de fichier (File organization)
Nature des liaisons entre les articles contenus dans un fichier.

Les programmes dapplication peuvent choisir les articles dans un fichier de diffrentes manires, par exemple lun aprs lautre partir du premier, ou en attribuant un
nom chaque article, selon la mthode daccs choisie.
Notion III.7 : Mthode daccs (Acces Method)
Mthode dexploitation du fichier utilise par les programmes dapplication pour slectionner des
articles.

2.3. UTILISATION DE LANGAGES HTES

Le systme de gestion de fichiers doit tre utilisable par un programme dont le code
objet rsulte dune compilation dun langage de haut niveau (COBOL, PL/1, PASCAL, C, etc.). De plus, il doit tre possible dutiliser les fichiers dans le langage
choisi dune manire aussi intgre que possible, par exemple en dcrivant les donnes du fichier comme des types dans le langage. On appelle langage hte le langage
de programmation qui intgre les verbes de manipulation de fichiers.
Notion III.8 : Langage hte (Host language)
Langage de programmation accueillant les verbes de manipulation de fichiers et la dfinition des
donnes des fichiers.

Il est utile de rappeler le cheminement dun programme en machine. Celui-ci est donc
crit laide dun langage de programmation hte et de verbes de manipulation de
fichiers. Il est pris en charge par le compilateur du langage. Ce dernier gnre du code
machine translatable incluant des appels au systme, en particulier au gestionnaire de
fichiers. Le chargeur-diteur de liens doit ensuite amener en bonne place en mmoire
les diffrents modules composants du programme ; en particulier, les translations

62 BASES DE DONNES : OBJET ET RELATIONNEL

dadresse doivent tre effectues ce niveau. On obtient alors du code excutable. La

figure III.3 illustre ces tapes.
Programme

Compilation

Code machine
translatable

Chargement
dition de liens

Code machine
excutable

Figure III.3 : Cheminement dun programme

2.4. POSSIBILITS DACCS SQUENTIEL ET SLECTIF

Afin de caractriser le comportement des programmes dapplication vis--vis des

fichiers, il est possible dutiliser deux mesures. Le taux de consultation (TC) est le
quotient du nombre darticles utilement lus par un programme sur le nombre darticles
total du fichier. Le taux de mouvement (TM) est le quotient du nombre darticles
modifis par un programme sur le nombre darticles total du fichier. On est ainsi
conduit introduire deux types de mthodes daccs.
Notion III.9 : Mthode daccs squentielle (Sequential Acces Method)
Mthode daccs consistant lire successivement tous les articles dun fichier, depuis le premier
jusqu larticle dsir.

Fichiers, hachage et indexation 63

Notion III.10 : Mthodes daccs slectives (Key-based access methods)

Ensemble de mthodes daccs permettant de lire/crire tout article au moyen de quelques accs
disques (moins de 5, idalement 1), y compris pour de trs gros fichiers.

Une mthode daccs squentielle est adapte si TC ou TC+TM sont de lordre de 1.

Elle sera essentiellement utilise en traitement par lots. Au contraire, une mthode
daccs slective sera utilise quand TC, ou TC+TM pour un programme modifiant,
sera petit. Les mthodes daccs slectives sont donc particulirement adaptes au
transactionnel. Un gestionnaire de fichiers doit supporter des mthodes daccs
squentielle et slectives, cela afin de permettre la fois les traitements par lots et le
travail en transactionnel.

Afin de mettre en uvre une mthode daccs slective, il faut pouvoir identifier de
manire unique un article. En effet, une mthode daccs slective permet partir de
lidentifiant dun article de dterminer ladresse dun article (adresse dbut) et de lire
larticle en moins de 5 E/S. Lidentifiant dun article est appel cl (que lon qualifie
parfois de primaire). La cl peut ou non figurer comme une donne de larticle.
Notion III.11 : Cl darticle (Record Key)
Identifiant dun article permettant de slectionner un article unique dans un fichier.

Soit lexemple dun fichier dcrivant des tudiants. Les articles comportent les
champs suivants : numro dtudiant, nom, prnom, ville, date dinscription et rsultats. La cl est le numro dtudiant ; cest une donne de larticle. partir de cette
cl, cest--dire dun numro dtudiant, une mthode daccs slective doit permettre
de dterminer ladresse de larticle dans le fichier et daccder larticle en principe
en moins de 5 entres/sorties disques.

Comme cela a t dj dit, il existe diffrents types dorganisations slectives (et

mthodes daccs associes). Nous allons ci-dessous tudier les principales. Elles peuvent tre divises en deux classes :
Les mthodes daccs par hachage utilisent des fonctions de calcul pour dterminer
ladresse dun article dans un fichier partir de sa cl ;
Les mthodes daccs par index utilisent des tables gnralement stockes sur
disques pour mmoriser lassociation cl article-adresse article.

2.5. POSSIBILIT DUTILISATEURS MULTIPLES

Dans les machines modernes, lexcution dune instruction dentre-sortie ne bloque

pas le processeur central : celui-ci peut continuer excuter des instructions machine
en parallle lexcution de lentre-sortie. Afin dutiliser ces possibilits, le systme
excute plusieurs programmes usagers simultanment, ce qui conduit une simultanit inter-usagers, cest--dire entre diffrents programmes utilisateurs.

64 BASES DE DONNES : OBJET ET RELATIONNEL

Notion III.12 : Simultanit inter-usagers (Inter-user parallelism)

Type de simultanit consistant excuter un programme dapplication en processeur central pendant quun autre programme effectue des entres-sorties.

Un bon systme de fichiers doit permettre le partage des fichiers par diffrents programmes dapplication sans que ceux-ci sen aperoivent. Le partage peut tre simultan, mais aussi plus simplement rparti dans le temps. Nous tudierons plus en dtail
les problmes de partage dans le contexte des bases de donnes o ils se posent avec
plus dacuit encore.

2.6. SCURIT ET PROTECTION DES FICHIERS

Lobjectif scurit des fichiers contre les accs mal intentionns, ou plus simplement non
autoriss, dcoule directement du besoin de partager les fichiers. En effet, lorsque les
fichiers sont partags, le propritaire dsire contrler les accs, les autoriser certains,
les interdire dautres. Cest l une des fonctions que doit rendre un bon systme de gestion de fichiers. Ces mcanismes sont gnralement raliss laide de noms hirarchiques et de cls de protection associs chaque fichier, voire chaque article. Lusager
doit fournir ces noms et ces cls pour accder au fichier ou larticle. Nous tudierons
les solutions dans le cadre des bases de donnes o le problme devient plus aigu.

Le gestionnaire de fichiers doit aussi garantir la conservation des fichiers en cas de

panne du matriel ou du logiciel. En consquence, il doit tre prvu de pouvoir repartir aprs panne avec des fichiers corrects. On considre en gnral deux types de
pannes : les pannes simples avec seulement perte du contenu de la mmoire secondaire, les pannes catastrophiques o le contenu de la mmoire secondaire peut tre
dtruit. Ainsi, il est ncessaire dincorporer des procdures de reprise aprs pannes
simples et catastrophiques. Nous tudierons ces procdures dans le cadre des bases de
donnes o elles sont gnralement plus compltes, bien que souvent prises en
compte au niveau de la gestion de fichiers.

3. FONCTIONS DUN GRANT DE FICHIERS

3.1. ARCHITECTURE DUN GESTIONNAIRE
DE FICHIERS

Un gestionnaire de fichiers est gnralement structur autour dun noyau, appel ici
analyseur, qui assure les fonctions de base, savoir la cration/destruction des
fichiers, lallocation de la mmoire secondaire, la localisation et la recherche des

Fichiers, hachage et indexation 65

fichiers sur les volumes et la gestion des zones de mmoires intermdiaires appeles
tampons. Les mthodes daccs sont des modules spcifiques qui constituent une
couche plus externe et qui utilisent les fonctions du noyau. La figure III.4 reprsente
les diffrents modules dun gestionnaire de fichiers typique. Notons que ces modules
sont organiss en trois couches de logiciel : les mthodes daccs, le noyau et le gestionnaire dentres-sorties compos de modules plus ou moins spcifiques chaque
priphrique. Chaque couche constitue une machine abstraite qui accomplit un certain
nombre de fonctions accessibles aux couches suprieures par des primitives (par
exemple, lire ou crire un article, ouvrir ou fermer un fichier) constituant linterface
de la couche.

Squentiel

Hach

OUVRIR

LIRE

Index 1

CRIRE

Index 2

FERMER
ANALYSEUR

ADRESSAGE

ME 1

MTHODES
D'ACCS

MODULES
DE/S

ME k

Disques magntiques

Figure III.4 : Architecture dun gestionnaire de fichiers

Le noyau ou analyseur dun gestionnaire de fichiers est charg dassurer la gestion des
fichiers en temps que rcipients non structurs. Il permet en gnral dtablir le lien
entre un fichier et un programme (ouverture du fichier), de supprimer ce lien (fermeture), de lire ou crire une suite doctets un certain emplacement dans un fichier. Il
accde aux mmoires secondaires par lintermdiaire du gestionnaire dentres-sorties. Celui-ci, qui nappartient pas proprement parler au gestionnaire de fichiers mais
bien au systme opratoire, gre les entres-sorties physiques : il permet la lecture et
lcriture de blocs physiques de donnes sur tous les priphriques, gre les particularits de chacun, ainsi que les files dattente dentres-sorties.

66 BASES DE DONNES : OBJET ET RELATIONNEL

Chaque module mthode daccs est la fois charg de lorganisation des articles
dans le fichier et de la recherche des articles partir de la cl. Un bon systme de
fichiers doit offrir une grande varit de mthodes daccs. Il offrira bien sr une
mthode daccs squentielle, mais surtout plusieurs mthodes daccs slectives.

3.2. FONCTIONS DU NOYAU DUN GESTIONNAIRE

DE FICHIERS
3.2.1. Manipulation des fichiers

Le programmeur travaillant au niveau du langage machine, ainsi que les modules

mthodes daccs accdent au noyau du gestionnaire de fichiers laide dun
ensemble dinstructions de manipulation de fichiers. Tout dabord, deux instructions
permettent de crer et de dtruire un fichier. Puis, avant de lire ou dcrire des donnes dans un fichier, il faut contrler son identit et ouvrir un chemin pour les donnes entre le programme effectuant les lectures-critures et la mmoire secondaire.
Cette opration est gnralement effectue par une instruction douverture : ouvrir.
Lopration inverse est excute lorsque le programme se dsintresse du fichier par
une instruction de fermeture : fermer.

3.2.2. Adressage relatif

Un fichier tant gnralement discontinu sur mmoire secondaire, il est utile de pouvoir adresser son contenu laide dune adresse continue de 0 n appele adresse
relative. Cela prsente lintrt de disposer dun reprage indpendant de la localisation du fichier sur mmoire secondaire (en cas de recopie du fichier, ladresse relative
ne change pas) et de pouvoir assurer que lon travaille bien lintrieur dun fichier
sans risque datteindre un autre fichier (il suffit de contrler que ladresse relative ne
dpasse pas la taille du fichier).
Notion III.13 : Adresse relative (Relative address)
Numro dunit dadressage dans un fichier (autrement dit dplacement par rapport au dbut du
fichier).

Pour raliser ladressage relatif, on divise gnralement le fichier en pages (on trouve
galement selon les implantations les termes de bloc, groupe, intervalle) : une adresse
relative octet se compose alors dun numro de page suivi dun numro doctet dans
la page. Pour viter un nombre trop important dentres-sorties, la taille de la page est
choisie de faon contenir plusieurs enregistrements physiques et des tampons dune
page sont utiliss. La taille de la page, fixe dans le systme ou lors de la cration du

Fichiers, hachage et indexation 67

fichier, est le plus souvent de lordre de quelques kilos (K) octets (par exemple, 4K).
Elle dpend parfois de lorganisation du fichier. Celle dun enregistrement physique
dpasse rarement quelques centaines doctets.

Ainsi, lanalyseur dun gestionnaire de fichiers offre gnralement la possibilit

daccder une ou plusieurs pages dadresse relative (numro de page) donne dans
un fichier. Il peut aussi permettre daccder directement aux octets, donc de lire une
suite doctets partir dune adresse relative en octets dans le fichier. Lanalyseur se
compose essentiellement dalgorithmes dallocation de mmoire secondaire et de
conversion dadresse relative page en adresse relle de lenregistrement physique
(secteur sur disque), et rciproquement. Finalement, il permet de banaliser toutes les
mmoires secondaires en offrant un accs par adresse relative uniforme, avec
quelques restrictions cependant : il est par exemple interdit daccder autrement quen
squentiel une bande magntique.
Les articles de lusager sont alors implants dans les pages par les mthodes daccs
selon lorganisation choisie. Si plusieurs articles sont implants dans une mme page,
on dit quil y a blocage. Dans le cas o les articles sont implants conscutivement
sans trou la suite les uns des autres, on dit quil y a compactage : aucune place nest
alors perdue sur la mmoire secondaire, mais des articles peuvent tre cheval sur
plusieurs pages.

3.2.3. Allocation de la place sur mmoires secondaires

La taille dun fichier est fixe soit de manire statique lors de sa cration, soit de
manire dynamique au fur et mesure des besoins. Des solutions intermdiaires sont
possibles avec une taille initiale extensible par paliers. Dans tous les cas, il est ncessaire de rserver des zones de mmoires secondaires continues pour le fichier. Ces
zones sont appeles rgions.
Notion III.14 : Rgion (Allocation area)
Ensemble de zones de mmoires secondaires (pistes) adjacentes alloues en une seule fois un
fichier.

Comme les fichiers vivent et sont de tailles diffrentes, les rgions successivement
alloues un fichier ne sont gnralement pas contigus sur une mmoire secondaire.
Le gestionnaire de fichiers doit alors pouvoir retrouver les rgions composant un
fichier. Pour cela, il peut soit garder la liste des rgions alloues un fichier dans une
table, soit les chaner, cest--dire mettre dans une entre dune table correspondant
chaque rgion ladresse de la rgion suivante.
La taille dune rgion peut varier partir dun seuil minimal appel granule (par
exemple une piste, etc.). Il devient alors possible dallouer des rgions de taille
variable un fichier, mais toujours composes dun nombre entier de granules cons-

68 BASES DE DONNES : OBJET ET RELATIONNEL

cutifs. Un granule est souvent choisi de taille gale une piste o une fraction de
piste.
Notion III.15 : Granule dallocation (Allocation granule)
Unit de mmoire secondaire allouable un fichier.

Lorsquun fichier est dtruit ou rtrci, les rgions qui lui taient alloues et qui ne
sont plus utilises sont libres. Les granules composants sont alors librs et introduits dans la liste des granules libres. Afin de maximiser la proximit des granules
allous un fichier, plusieurs mthodes dallocations ont t proposes. Nous allons
tudier ci-dessous quelques algorithmes dallocation des rgions aux fichiers.

3.2.4. Localisation des fichiers sur les volumes

Il est ncessaire de pouvoir identifier un volume. En effet, lorsquun volume amovible

nest pas actif, il peut tre enlev. Il faut donc une intervention manuelle pour monter/dmonter un volume sur un tourne-disque. Cette opration est excute par un
oprateur. Celui-ci reconnat un volume grce un numro (ou nom) attribu chaque
volume. Pour pouvoir contrler les oprateurs lors des montages/dmontages de
volume et viter les erreurs, ce numro est crit sur le volume dans le label du
volume.
Notion III.16 : Label de volume (Label)
Premier secteur dun volume permettant didentifier ce volume et contenant en particulier son
numro.

Lorsquon a retrouv et mont le volume supportant un fichier, il faut retrouver le

fichier sur le volume. Pour cela, chaque fichier possde un ensemble de donnes descriptives (nom, adresse dbut, localisation, etc.) regroupes dans un descripteur du
fichier.
Notion III.17 : Descripteur de fichier (Directory entry)
Ensemble des informations permettant de retrouver les caractristiques dun fichier, contenant en
particulier son nom, sa localisation sur disque, etc.

Il est important que lensemble des descripteurs de fichiers contenu sur un volume
dfinisse tous les fichiers dun volume. On obtient ainsi des volumes autodocuments,
donc portables dune installation une autre. Pour cela, les descripteurs de fichiers
dun volume sont regroups dans une table des matires du volume appele
catalogue.

Fichiers, hachage et indexation 69

Notion III.18 : Catalogue (Directory)

Table (ou fichier) situe sur un volume et contenant les descripteurs des fichiers du volume.

Le catalogue est soit localis en un point conventionnel du volume (par exemple, partir
du secteur 1), soit crit dans un fichier spcial de nom standard. Le descripteur de ce premier fichier peut alors tre contenu dans le label du volume. En rsum, la figure III.5
illustre lorganisation des informations tudies jusqu prsent sur un volume.

VOLUME n

Catalogue

Label

F1

F3

F2

F4

Figure III.5 : Schma reprsentant lorganisation dun volume

3.2.5. Classification des fichiers en hirarchie

Quand le nombre de fichiers dune installation devient lev, on est conduit classer
les descripteurs de fichiers dans plusieurs catalogues, par exemple un par usager. Les
descripteurs des fichiers catalogues peuvent alors tre maintenus dans un catalogue de
niveau plus lev. On aboutit ainsi des catalogues hirarchiss qui sont implants
dans de nombreux systmes [Daley65].
Notion III.19 : Catalogue hirarchis (Hierarchical directory)
Catalogue constitu dune hirarchie de fichiers, chaque fichier contenant les descripteurs des
fichiers immdiatement infrieurs dans la hirarchie.

70 BASES DE DONNES : OBJET ET RELATIONNEL

Dans un systme catalogues hirarchiss, chaque niveau de catalogue est gnralement spcialis. Par exemple, le niveau 1 contient un descripteur de fichier catalogue
par usager. Pour chaque usager, le niveau 2 peut contenir un descripteur de fichier par
application. Enfin, pour chaque couple <usager-application>, le niveau 3 peut contenir la liste des descripteurs de fichiers de donnes. La figure III.6 illustre un exemple
de catalogue hirarchis. Le descripteur du catalogue de niveau 1 est appel racine.
Racine
hirarchie

Pierre
Utilisateur

Bases
de donnes

Rseaux

Internet

ATM

Paul
Utilisateur

Paralllisme

...
Utilisateur

...

Jacques
Utilisateur

...

...

Figure III.6 : Exemple de catalogue hirarchis

La prsence de catalogue hirarchis conduit introduire des noms de fichiers composs. Pour atteindre le descripteur dun fichier, il faut en effet indiquer le nom du chemin qui mne ce descripteur. Voici des noms de fichiers possibles avec le catalogue
reprsent figure III.6 :
PIERRE
PIERRE > BASES-DE-DONNEES
PIERRE > BASES-DE-DONNES > MODELES

Afin dviter un cloisonnement trop strict des fichiers, les systmes catalogues hirarchiss permettent en gnral lintroduction de liens. Un lien est simplement un descripteur qui contient un pointeur logique sur un autre descripteur, ventuellement dans
une autre branche de la hirarchie. Par exemple, le descripteur de
nom > LIONEL > BASES-DE-DONNEES > LANGAGES pourra tre un descripteur
de type lien indiquant quil est un synonyme du descripteur > PIERRE > BASES-DEDONNEES > LANGAGES. Les noms dusagers tant gnralement fournis par le
systme, des descripteurs de type lien permettent le partage des fichiers entre usagers.

Fichiers, hachage et indexation 71

Pour simplifier la nomination des fichiers, les systmes catalogues hirarchiss

grent bien souvent la notion de catalogue de base, encore appel catalogue courant.
Lors du dbut de session (login), le systme positionne le catalogue courant par
exemple sur les applications de lusager. Celui-ci peut alors se dplacer par rapport
ce catalogue courant. Par exemple, Pierre passera au catalogue bases-de-donnes par
le nom > Bases-de-donnes. Celui-ci deviendra alors son catalogue courant. Laccs
au fichier modles se fera alors par le nom > Modles. Le retour au catalogue initial
de Pierre seffectuera par < < ; en effet, les noms de rpertoires sont dtermins de
manire unique quand on remonte la hirarchie.

3.2.6. Contrle des fichiers

Le noyau dun gestionnaire de fichiers inclut galement des fonctions de contrle des
fichiers : partage des fichiers, rsistances aux pannes, scurit et confidentialit des
donnes. Nous ntudions pas ici ces problmes, qui font lobjet de nombreux dveloppements dans le contexte des bases de donnes, donc dans les chapitres suivants.

3.3. STRATGIE DALLOCATION

DE LA MMOIRE SECONDAIRE
3.3.1. Objectifs dune stratgie

Il existe diffrentes stratgies dallocation de la mmoire secondaire aux fichiers. Une

bonne stratgie doit chercher :
1. minimiser le nombre de rgions allouer un fichier pour rduire dune part les
dplacements des bras des disques lors des lectures en squentiel, dautre part le
nombre de descripteurs de rgions associs un fichier ;
2. minimiser la distance qui spare les rgions successives dun fichier, pour rduire
les dplacements de bras en amplitude.

Les stratgies peuvent tre plus ou moins complexes. La classe la plus simple de stratgies alloue des rgions de taille fixe gale un granule, si bien que les notions de
granule et rgion sont confondues. Une classe plus performante alloue des rgions de
tailles variables, composes de plusieurs granules successifs. Nous allons approfondir
ces deux classes ci-dessous.

Auparavant, il est ncessaire de prciser que toutes les mthodes conservent une table
des granules libres ; une copie de cette table doit tre stocke sur disque pour des raisons de fiabilit. La table elle-mme peut tre organise selon diffrentes mthodes :
liste des granules ou rgions libres, ordonne ou non ; lallocation dune rgion
consiste alors enlever la rgion choisie de cette liste pour lassocier au descripteur
du fichier ;

72 BASES DE DONNES : OBJET ET RELATIONNEL

table de bits dans laquelle chaque bit correspond un granule; lallocation dun granule consiste alors trouver un bit 0, le positionner 1 et adjoindre ladresse du
granule allou au descripteur du fichier.

3.3.2. Stratgie par granule ( rgion fixe)

Ces stratgies confondent donc les notions de rgion et de granule. Elles sont simples
et gnralement implantes sur les petits systmes. On peut distinguer :
La stratgie du premier trouv : le granule correspondant la tte de liste de la liste
des granules libres, ou au premier bit 0 dans la table des granules libres, est choisi ;
La stratgie du meilleur choix : le granule le plus proche (du point de vue dplacement de bras) du dernier granule allou au fichier est retenu.

3.3.3. Stratgie par rgion ( rgion variable)

Ces stratgies permettent dallouer des rgions composes de plusieurs granules

conscutifs, selon les besoins des fichiers. Le noyau du gestionnaire de fichiers reoit
alors des demandes dallocation et libration de rgions de tailles variables. Dans le
cas o aucune rgion de la taille demande ne peut tre constitue par des granules
conscutifs, la demande peut ventuellement tre satisfaite par plusieurs rgions.
Parmi les stratgies par rgion, on peut distinguer :
La stratgie du plus proche choix. Deux rgions libres conscutives sont fusionnes en une seule. Lors dune demande dallocation, la liste des rgions libres est
parcourue jusqu trouver une rgion de la taille demande ; si aucune rgion de la
taille demande nest libre, la premire rgion de taille suprieure est dcoupe en
une rgion de la taille cherche qui est alloue au fichier et une nouvelle rgion
libre correspondant au reste.
La stratgie des frres siamois. Elle offre la possibilit dallouer des rgions de 1,
2, 4, 8 2K granules. Des listes spares sont maintenues pour les rgions libres de
dimensions 20, 21 2K granules. Lors dune demande dallocation, une rgion libre
peut tre extraite de la liste des rgions libres de taille 2i+1 pour constituer deux
rgions libres de taille 2i. Lors dune libration, deux rgions libres conscutives
(deux siamoises) de taille 2i sont fusionnes afin de constituer une rgion libre de
taille 2i+1. Lalgorithme de recherche dune rgion libre de taille 2i consiste chercher cette rgion dans la liste des rgions de taille 2i. Si cette liste est vide, on
recherche alors une rgion de taille 2i+1 que lon divise en deux. Sil ny en a pas,
on passe alors au niveau suivant 2i+2, etc., jusqu atteindre le niveau k; cest seulement dans le cas o les listes 2i 2K sont vides que lon ne peut satisfaire la
demande par une seule rgion. Cet algorithme, qui est emprunt aux mcanismes
dallocation de segments dans les systmes pagins [Lister84], est sans doute le
plus efficace ; il est aussi trs bien adapt certaines mthodes daccs.

Fichiers, hachage et indexation 73

En rsum, les stratgies par rgion de tailles variables sont en gnral plus efficaces
du point de vue dplacement de bras et taille de la table des rgions dun fichier. Un
problme commun ces stratgies peut cependant survenir aprs des dcoupages trop
nombreux sil nexiste plus de rgions de taille suprieure un granule. Dans ce cas,
lespace disque doit tre rorganis (ramassage des miettes). Ce dernier point fait que
les stratgies par granule restent les plus utilises.

4. ORGANISATIONS ET MTHODES DACCS

PAR HACHAGE

Les organisations et mthodes daccs par hachage sont bases sur lutilisation dune
fonction de calcul qui, applique la cl, dtermine ladresse relative dune zone
appele paquet (bucket en anglais) dans laquelle est plac larticle. On distingue les
mthodes daccs par hachage statique, dans lesquelles la taille du fichier est fixe, des
mthodes par hachage dynamique, o le fichier peut grandir.

4.1. ORGANISATION HACHE STATIQUE

Cest la mthode la plus ancienne et la plus simple. Le fichier est de taille constante,
fixe lors de sa cration. Une fois pour toute, il est donc divis en p paquets de taille
fixe L. La cl permet de dterminer un numro de paquet N dont ladresse relative est
obtenue par la formule AR = N * L. Nous dfinirons un fichier hach statique
comme suit.
Notion III.20 : Fichier hach statique (Static hashed file)
Fichier de taille fixe dans lequel les articles sont placs dans des paquets dont ladresse est calcule
laide dune fonction de hachage fixe applique la cl.

lintrieur dun paquet, les articles sont rangs la suite dans lordre darrive. Ils
sont retrouvs grce la donne contenant la cl. La figure III.7 illustre un exemple
de structure interne dun paquet. En tte du paquet, on trouve ladresse du premier
octet libre dans le paquet. Ensuite, les articles successifs du paquet sont rangs avec
leur longueur en tte, par exemple sur deux octets. lintrieur dun tel paquet, on
accde un article par balayage squentiel. Des structures de paquet plus sophistiques permettent laccs direct un article de cl donne lintrieur dun paquet. De
telles structures sont plus efficaces que la structure simple reprsente figure III.7.

74 BASES DE DONNES : OBJET ET RELATIONNEL

Iga1
Article a1
de longueur lga1

Adresse premier octet

libre dans le paquet

a1
Iga2

Article a2
de longueur lga2

a2

L Octets

Iga3
Article a3
de longueur lga3

a3

Index optionnel

Figure III.7 : Structure interne dun paquet

Lorsquun nouvel article est insr dans un fichier, il est log la premire place libre
dans le paquet. Sil ny a pas de place libre, on dit quil y a dbordement. Il faut videmment contrler lunicit de la cl dun article lors des insertions. Cela ncessite de
balayer tous les articles du paquet.

partir de la cl dun article, on calcule le numro de paquet dans lequel larticle est
plac laide dune fonction appele fonction de hachage (Fig. III.8). Une fonction
de hachage doit tre choisie de faon distribuer uniformment les articles dans les
paquets. Plusieurs techniques sont possibles :
le pliage, qui consiste choisir et combiner des bits de la cl (par exemple par ou
exclusif ) ;
les conversions de la cl en nombre entier ou flottant avec utilisation de la mantisse
permettants dobtenir galement un numro de paquet ;
le modulo, sans doute la fonction la plus utilise, qui consiste prendre pour
numro de paquet le reste de la division de la cl par le nombre de paquets.
Ces techniques peuvent avantageusement tre combines.

Soit un fichier de 47 paquets et des articles de cl numrique. Le modulo 47 pourra

alors tre choisi comme fonction de hachage. Ainsi, larticle de cl 100 sera plac

Fichiers, hachage et indexation 75

dans le paquet 6, larticle de cl 47 dans le paquet 0, celui de cl 123 dans le

paquet 29, etc.
Fonction
de
hachage

Cl

Nombre de 0 N-1

...

...

Figure III.8 : Illustration dun fichier hach statique

N-1

Paquets

Le problme de dbordement se pose lorsquun paquet est plein. Une premire solution simple consiste ne pas grer de dbordements et rpondre fichier satur
lutilisateur. Cela implique une mauvaise utilisation de la place occupe par le fichier,
surtout si la distribution des articles dans les paquets est mauvaise. Des solutions plus
satisfaisantes consistent utiliser une technique de dbordement parmi lune des suivantes [Knuth73] :
ladressage ouvert consiste placer larticle qui devrait aller dans un paquet plein
dans le premier paquet suivant ayant de la place libre ; il faut alors mmoriser tous
les paquets dans lequel un paquet plein a dbord ;
le chanage consiste constituer un paquet logique par chanage dun paquet de
dbordement un paquet plein ;
le rehachage consiste appliquer une deuxime fonction de hachage lorsquun
paquet est plein; cette deuxime fonction conduit gnralement placer les articles
dans des paquets de dbordements.

Dans tous les cas, la gestion de dbordements dgrade les performances et complique
la gestion des fichiers hachs.

La mthode daccs base sur lorganisation hache statique a plusieurs avantages. En

particulier, elle sadapte des fichiers de cls quelconques, reste simple et donne
dexcellentes performances tant quil ny a pas de dbordements : une lecture darticle
seffectue en une entre-sortie (lecture du paquet) alors quune criture en ncessite
en gnral deux (lecture puis rcriture du paquet). Cependant, les dbordements
dgradent rapidement les performances. De plus, le taux doccupation de la mmoire
secondaire rellement utilise peut rester assez loign de 1. Enfin, la taille dun
fichier doit tre fixe a priori. Si le nombre darticles dun fichier devient plus important que prvu, le fichier doit tre rorganis.

76 BASES DE DONNES : OBJET ET RELATIONNEL

4.2. ORGANISATIONS HACHES DYNAMIQUES

4.2.1. Principes du hachage dynamique

La premire organisation hache dynamique a t propose pour des tables

en mmoire [Knott71]. Puis plusieurs techniques fondes sur le mme principe
mais diffrentes ont t proposes pour tendre les possibilits du hachage
des fichiers dynamiques [Fagin79, Larson78, Litwin78, Larson80, Litwin80]. Le principe de base de ces diffrentes techniques est la digitalisation progressive de la fonction de hachage : la chane de bits rsultat de lapplication de la fonction de hachage
la cl est exploite progressivement bit par bit au fur et mesure des extensions du
fichier.

Plus prcisment, les mthodes dynamiques utilisent une fonction de hachage de la

cl h(K) gnrant une chane de N bits, o N est grand (par exemple 32). La fonction
est choisie de sorte quun bit quelconque de h(K) ait la mme probabilit dtre 1 ou
0. Lors de la premire implantation du fichier hach, seuls les M premiers bits de
h(K) (avec M petit devant N) sont utiliss pour calculer le numro de paquet dans
lequel placer un article. Ensuite, lorsque le fichier est considr comme satur (par
exemple, lorsquun premier paquet est plein), une partie du fichier (par exemple le
paquet plein) est double : une nouvelle rgion est alloue pour cette partie et les
articles de lancienne partie sont distribus entre lancienne partie et la nouvelle en
utilisant le bit M+1 de la fonction de hachage. Ce processus dclatement est appliqu
chaque fois que le fichier est satur, de manire rcursive. Ainsi, les bits (M+1),
(M+2), (M+3) de la fonction de hachage sont successivement utiliss et le fichier
peut grandir jusqu 2N paquets. Une telle taille est suffisante sous lhypothse que N
soit assez grand.
Les mthodes de hachage dynamique diffrent par les rponses quelles apportent aux
questions suivantes :
(Q1) Quel est le critre retenu pour dcider quun fichier hach est satur ?
(Q2) Quelle partie du fichier faut-il doubler quand un fichier est satur ?

(Q3) Comment retrouver les parties dun fichier qui ont t doubles et combien de
fois ont-elles t doubles ?
(Q4) Faut-il conserver une mthode de dbordement, et si oui laquelle ?

Nous prsentons ci-dessous deux mthodes qui nous paraissent des plus intressantes:
le hachage extensible [Fagin79] et le hachage linaire [Litwin80]. Vous trouverez des
mthodes sans doute plus labores dans [Larson80], [Lomet83], [Samet89] ainsi que
des valuations du hachage extensible dans [Scholl81] et du hachage linaire dans
[Larson82].

Fichiers, hachage et indexation 77

4.2.2. Le hachage extensible

Le hachage extensible [Fagin79] apporte les rponses suivantes aux questions prcdentes :

(Q1) Le fichier est tendu ds quun paquet est plein ; dans ce cas un nouveau paquet
est ajout au fichier.

(Q2) Seul le paquet satur est doubl lors dune extension du fichier. Il clate selon le
bit suivant du rsultat de la fonction de hachage applique la cl h(K). Les
articles ayant ce bit 0 restent dans le paquet satur, alors que ceux ayant ce bit
1 partent dans le nouveau paquet.

(Q3) La fonction de hachage adresse un rpertoire des adresses de paquets ; la taille

du rpertoire est 2**(M+P) o P est le niveau du paquet qui a clat le plus
grand nombre de fois. Chaque entre du rpertoire donne ladresse dun paquet.
Les 2**(P-Q) adresses correspondant un paquet qui a clat Q fois sont identiques et pointent sur ce paquet. Ainsi, par lindirection du rpertoire, le systme
retrouve les paquets.
(Q4) La gestion de dbordement nest pas ncessaire.

Le hachage extensible associe donc chaque fichier un rpertoire des adresses de

paquets. Au dpart, M bits de la fonction de hachage sont utiliss pour adresser le
rpertoire. la premire saturation dun paquet, le rpertoire est doubl, et un nouveau paquet est allou au fichier. Le paquet satur est distribu entre lancien et le
nouveau paquets, selon le bit suivant (M+1) de la fonction de hachage. Ensuite, tout
paquet plein est clat en deux paquets, lui-mme et un nouveau paquet allou au
fichier. Lentre du rpertoire correspondant au nouveau paquet est mise jour avec
ladresse de ce nouveau paquet si elle pointait encore sur le paquet plein. Sinon, le
rpertoire est nouveau doubl. En rsum, le hachage extensible peut tre dfini
comme suit :
Notion III.21 : Hachage extensible (Extensible hashing)
Mthode de hachage dynamique consistant clater un paquet plein et mmoriser ladresse des
paquets dans un rpertoire adress directement par les (M+P) premiers bits de la fonction de
hachage, o P est le nombre dclatements maximal subi par les paquets.

Cette organisation est illustre figure III.9. Nous montrons ici un rpertoire adress
par 3 bits de la fonction de hachage. Le fichier avait t cr avec deux paquets et
tait adress par le premier bit de la fonction de hachage (celui de droite). Puis le
paquet 1 a clat et a t distribu entre le paquet 01 et 11. Le paquet 11 a clat son
tour et a t distribu entre le paquet 011 et le paquet 111. Le rpertoire a donc t
doubl deux fois (P = 2 alors que M = 1).

78 BASES DE DONNES : OBJET ET RELATIONNEL

H (KEY)

XXXX

X X X
000
001
010
011
100
101
110
111

Figure III.9 : Rpertoire et paquets dun fichier hach extensible

Un fichier hach extensible est donc structur en deux niveaux : le rpertoire et les
paquets. Soit P le niveau dclatement maximal du fichier. Le rpertoire contient un entte qui indique la valeur de M+P, le nombre de bits de la fonction de hachage utiliss
pour le paquet ayant le plus clat. Aprs len-tte figurent des pointeurs vers les paquets.
Les M+P premiers bits de la fonction de hachage sont donc utiliss pour adresser le rpertoire. Le premier pointeur correspond la valeur 0 des (M+P) premiers bits de la fonction
de hachage, alors que le dernier correspond la valeur 2**(M+P) 1, cest--dire aux
(M+P) premiers bits 1. Soit Q le nombre dclatements subis par un paquet. chaque
paquet sont associs dans le rpertoire 2**(P-Q) pointeurs qui indiquent son adresse. Le
rpertoire pointe ainsi plusieurs fois sur le mme paquet, ce qui accrot sa taille.

Linsertion dun article dans un fichier hach extensible ncessite tout dabord laccs
au rpertoire. Pour cela, les (M+P) bits de la cl sont utiliss. Ladresse du paquet
dans lequel larticle doit tre plac est ainsi lue dans lentre adresse du rpertoire. Si
le paquet est plein, alors celui-ci doit tre doubl et son niveau dclatement Q augment de 1 ; un paquet frre au mme niveau dclatement doit tre cr ; les articles
sont rpartis dans les deux paquets selon la valeur du bit (M+Q+1) de la fonction de
hachage. Le mcanisme dclatement de paquet est illustr figure III.10. Si le niveau
du rpertoire P est suprieur Q, alors le rpertoire doit simplement tre mis jour,
2**(P-Q+1) pointeurs tant forcs sur ladresse du nouveau paquet. Si P est gal Q,
alors le rpertoire doit tre doubl.
En cas de suppression dans un paquet adress par M+Q bits de la fonction de hachage,
il est possible de tenter de regrouper ce paquet avec lautre paquet adress par M+Q
bits sil existe. Ainsi, la suppression dun article dans un paquet peut thoriquement
conduire rorganiser le rpertoire. En effet, si le paquet concern est le seul paquet
avec son frre au niveau dclatement le plus bas et si la suppression dun article
laisse assez de place libre pour fusionner les deux frres, la fusion peut tre entreprise.

Fichiers, hachage et indexation 79

Le niveau dclatement du rpertoire doit alors tre rduit de 1 et celui-ci doit tre
divis par deux en fusionnant les blocs jumeaux.
000

001

010

c1

011

100

101

110

c2

111

Figure III.10 : clatement de paquet dans un fichier hach extensible

4.2.3. Le hachage linaire

Le hachage linaire [Litwin80] apporte les rponses suivantes aux questions dterminantes dune mthode de hachage dynamique :
(Q1) Le fichier est tendu ds quun paquet est plein, comme dans le hachage extensible ; un nouveau paquet est aussi ajout au fichier chaque extension ;
(Q2) Le paquet doubl nest pas celui qui est satur, mais un paquet point par un
pointeur courant initialis au premier paquet du fichier et incrment de 1
chaque clatement dun paquet (donc chaque saturation) ; lorsque ce pointeur
atteint la fin de fichier, il est repositionn au dbut du fichier ;
(Q3) Un niveau dclatement P du fichier (initialis 0 et incrment lorsque le pointeur
courant revient en dbut de fichier) est conserv dans le descripteur du fichier;
pour un paquet situ avant le pointeur courant, (M+P+1) bits de la fonction de
hachage doivent tre utiliss alors que seulement (M+P) sont utiliser pour adresser un paquet situ aprs le pointeur courant et avant le paquet 2**(M+P) ;
(Q4) Une gestion de dbordement est ncessaire puisquun paquet plein nest en gnral pas clat ; il le sera seulement quand le pointeur courant passera par son
adresse. Une mthode de dbordement quelconque peut tre utilise.
En rsum, il est possible de dfinir le hachage linaire comme suit :
Notion III.22 : Hachage linaire (Linear hashing)
Mthode de hachage dynamique ncessitant la gestion de dbordement et consistant : (1) clater
le paquet point par un pointeur courant quand un paquet est plein, (2) mmoriser le niveau dclatement du fichier afin de dterminer le nombre de bits de la fonction de hachage appliquer avant
et aprs le pointeur courant.

80 BASES DE DONNES : OBJET ET RELATIONNEL

La figure III.11 illustre un fichier hach linairement. Le pointeur courant est situ en
dbut du 3e paquet (paquet 10). Les paquets 000 et 001, 100 et 101 (cest--dire 0, 1,
4 et 5) sont adresss par les trois premiers bits de la fonction de hachage, alors que les
paquets 10 et 11 (cest--dire 2 et 3) sont seulement adresss par les deux premiers
bits. Lors du prochain dbordement, le paquet 10 (2) clatera, quel que soit le paquet
qui dborde.
H (KEY)

000

001

3 bits

dbordement

XXXXX

10

XX

11

100

101

2 bits

Figure III.11 : Fichier hach linairement

Notons que le hachage linaire peut aussi simplmenter avec un rpertoire. Dans ce
cas, le pointeur courant est un pointeur sur le rpertoire : il rfrence ladresse du
paquet suivant clater. Lavantage du hachage linaire est alors la simplicit de
lalgorithme dadressage du rpertoire ; on utilise tout dabord M+P bits de la fonction de hachage ; si lon est positionn avant le pointeur courant, on utilise un bit de
plus, sinon on lit ladresse du paquet dans le rpertoire. chaque clatement, le rpertoire saccrot dune seule entre. Linconvnient est bien sr la ncessit de grer des
dbordements.
Linsertion dun article dans un fichier hach linairement se fait trs simplement : si
P est le niveau dclatement du fichier, (M+P) bits de la cl sont tout dabord pris en
compte pour dterminer le numro de paquet. Si le numro obtenu est suprieur au
pointeur courant, il est correct ; sinon, un bit supplmentaire de la fonction de hachage
est utilis pour dterminer le numro de paquet. Linsertion seffectue ensuite de
manire classique, ceci prs que lorsquun paquet est satur, le paquet point par le
pointeur courant est clat ; ce pointeur courant est augment de 1 ; sil atteint le
paquet 2**(M+P) du fichier, il est ramen au dbut et le niveau dclatement du
fichier est augment de un.

Fichiers, hachage et indexation 81

De manire analogue au rpertoire du hachage extensible, la suppression darticle

dans un paquet peut amener la fusion de deux paquets et donc le recul de 1 du pointeur courant. Attention : en gnral les paquets fusionns nincluent pas le paquet dans
lequel a lieu la suppression ; la fusion peut amener des distributions darticles en
dbordement.
Une variante de cette mthode consistant changer la condition dclatement a t
propose dans [Larson80]. La condition retenue est latteinte dun taux de remplissage
maximal du fichier, le taux de remplissage tant le rapport de la place occupe par les
articles sur la taille totale du fichier.
En rsum, les mthodes de hachage dynamique sont bien adaptes aux fichiers dynamiques, cest--dire de taille variable, cependant pas trop gros pour viter les saturations de paquets trop nombreuses et les accroissements de la taille du catalogue. Leurs
limites sont encore mal connues. Le hachage extensible parat plus robuste face aux
mauvaises distributions de cls que le hachage linaire. Par contre, la gestion dun
rpertoire est plus lourde que celle dun pointeur courant.
Le grand problme des mthodes par hachage reste labsence de possibilits efficaces
daccs ordonn pour un tri total ou pour des questions sur des plages de valeur. Telle
est la limite essentielle, qui ncessite lemploi dautres mthodes.

5. ORGANISATIONS ET MTHODES DACCS

INDEXES

Dans cette section, nous tudions les principes de base des organisations avec index et
les principales mthodes pratiques.

5.1. PRINCIPES DES ORGANISATIONS INDEXES

5.1.1. Notion dindex

Le principe de base des organisations et mthodes daccs indexes est dassocier la

cl dun article son adresse relative dans le fichier laide dune table des
matires du fichier. Ainsi, partir de la cl de larticle, un accs rapide est possible
par recherche de ladresse relative dans la table des matires, puis par un accs en
relatif larticle dans le fichier. Les principales mthodes daccs indexes se distinguent par le mode de placement des articles dans le fichier et par lorganisation de la
table des matires, appele index.

82 BASES DE DONNES : OBJET ET RELATIONNEL

Notion III.23 : Index (Index)

Table (ou plusieurs tables) permettant dassocier une cl darticle ladresse relative de cet article.

La figure III.12 illustre cette notion dindex. Le fichier contient les articles a5, a2,
a57, a3 et a10. Lindex est rang en fin de fichier comme le dernier article du fichier.
Il contient une entre par article indiquant la cl de larticle et son adresse relative
dans le fichier. Lindex dun fichier peut en gnral tre rang dans le fichier ou plus
rarement dans un fichier spcial.
Articles
{a5

a2

a57

a3

a10

a5

a2 a57 a3 a10

12

18

Index
{0

Adresses relatives

10

12

14

16

18

20

22

24

Figure III.12 : Exemple de fichier index

Les tapes successives excutes pour laccs un article dans un fichier index sont
les suivantes :
1. Accs lindex qui est mont en mmoire dans un tampon.
2. Recherche de la cl de larticle dsir en mmoire afin dobtenir ladresse relative
de larticle ou dun paquet contenant larticle.
3. Conversion de ladresse relative trouve en adresse absolue par les couches internes
du systme de gestion de fichiers.
4. Accs larticle (ou au paquet darticles) sur disques magntiques et transfert dans
un tampon du systme.
5. Transfert de larticle dans la zone du programme usager.
En gnral, laccs un article dans un fichier index ncessite une trois entressorties pour monter lindex en mmoire, puis une entre sortie pour monter larticle en
mmoire. Diffrentes variantes sont possibles, selon lorganisation des articles dans le
fichier et de lindex.

5.1.2. Variantes possibles

Les variantes se distinguent tout dabord par lorganisation de lindex. Celui-ci peut
tre tri ou non. Le fait que lindex soit tri autorise la recherche dichotomique. Ainsi,

Fichiers, hachage et indexation 83

un index contenant n cls, divis en blocs (dune page) de b cls, ncessitera en

moyenne n/2b accs pour retrouver une cl sil nest pas tri ; il suffira de
log2n/b accs sil est tri. Par exemple, avec n = 106, b = 100 cls, on obtient 10 accs
si lindex est tri contre 5 000 accs sinon.
Un index dun fichier index peut contenir toutes les cls (cest--dire celles de tous
les articles) ou seulement certaines. Un index qui contient toutes les cls est appel
index dense. Afin de diffrencier plus prcisment les mthodes daccs obtenues, il
est possible dintroduire la notion de densit dun index.
Notion III.24 : Densit dun index (Index key selectivity)
Quotient du nombre de cls dans lindex sur le nombre darticles du fichier.

La densit dun index varie entre 0 et 1. Un index dense a donc une densit gale 1.
Dans le cas dindex non dense, toutes les cls ne figurent pas dans lindex. Aussi, les
articles du fichier ainsi que lindex sont tris. Le fichier est divis en paquets de taille
fixe et chaque paquet correspond une entre en index contenant le doublet : <plus
grande cl du paquet-adresse relative du paquet>. La figure III.13 illustre un index
non dense et le fichier correspondant. Le paquet 1 contient les articles de cl 1, 3 et 7.
La plus grande cl (7) figure dans lindex non dense, etc. Lindex est compos ici dun
seul bloc contenant trois cls, la plus grande de chaque paquet.
1-3-7

9 - 11 - 23

25 - 30 - 31

Paquet 1

Paquet 2

Paquet 3

723 -

31 -

Figure III.13 : Exemple dindex non dense

Comme le fichier peut tre tri ou non tri, et lindex dense ou non dense, tri ou non
tri, diverses variantes sont thoriquement possibles. Deux mthodes sont particulirement intressantes : le fichier squentiel non tri avec index tri dense, historiquement la base de lorganisation IS3, et le fichier tri avec index non dense tri, sur

84 BASES DE DONNES : OBJET ET RELATIONNEL

lequel sont fondes des organisations telles ISAM, VSAM et UFAS. Il est impossible
dassocier un index non dense un fichier non tri.

5.1.3. Index hirarchis

Un index peut tre vu comme un fichier de cls. Si lindex est grand (par exemple plus
dune page), la recherche dune cl dans lindex peut devenir trs longue. Il est alors
souhaitable de crer un index de lindex vu comme un fichier de cls. Cela revient
grer un index plusieurs niveaux. Un tel index est appel index hirarchis.
Notion III.25 : Index hirarchis (Multilevel index)
Index n niveaux, le niveau k tant un index tri divis en paquets, possdant lui-mme un index
de niveau k+1, la cl de chaque entre de ce dernier tant la plus grande du paquet.

Un index hirarchis un niveau est un index tri, gnralement non dense, compos
de paquets de cls. Un index hirarchis n niveaux est un index hiarchis n 1
niveaux, possdant lui-mme un index un niveau. La figure III.14 illustre un index
hirarchis 3 niveaux. Le niveau 1 comporte trois paquets de cls. Le niveau 2 en
comporte deux qui contiennent les plus grandes cls des paquets de niveau infrieur.
Le niveau 3 est la racine et contient les plus grandes cls des deux paquets de niveau
infrieur. La notion dindex hirarchis est indpendante du nombre de niveaux, qui
peut grandir autant que ncessaire.
21

12

30

21

5.1.4. Arbres B

12

Niveau 3

30

14 18 21

23 25 30

Niveau 2

Niveau 1

Figure III.14 : Exemple dindex hirarchis

Afin de mieux caractriser la notion dindex hirarchis et de la rendre indpendante

des particularits dimplantation, on a t amen introduire une structure darbre,

Fichiers, hachage et indexation 85

avec un nombre variable de niveaux. Cette structure, appele arbre B [Bayer72,

Comer79], peut tre introduite formellement comme suit :
Notion III.26: Arbre B (B-tree)
Un arbre B dordre m est un arbre au sens de la thorie des graphes tel que :
1) Toutes les feuilles sont au mme niveau ;
2) Tout nud non feuille a un nombre NF de fils tel que m+1 NF 2m+1, sauf la racine, qui a

La figure III.15 reprsente un arbre balanc dordre 2. La racine a deux fils. Les deux
autres nuds non feuilles ont trois fils.

a,b

d,e

g,h

j,k

m,n

p,q

Figure III.15 : Arbre B dordre 2

s,t

v,w

y,z

Un arbre B peut tre utilis pour constituer un index hirarchis dun fichier. Dans ce
cas, les nuds reprsentent des pages de lindex. Ils contiennent des cls tries par
ordre croissant et des pointeurs de deux types : les pointeurs internes dsignent des
fils et permettent de dfinir les branches de larbre, alors que les pointeurs externes
dsignent des pages de donnes (en gnral, des adresses relatives darticles). La
figure III.16 prcise la structure dun nud. Une cl xi dun nud interne sert de
sparateur entre les deux branches internes adjacentes (Pi-1 et Pi). Un nud contient
entre m et 2m cls, lexception de la racine qui contient entre 1 et 2m cls.

86 BASES DE DONNES : OBJET ET RELATIONNEL

P0 x1

a1

P1 x2

a2

P2 ...

xi

ai

Pi

... xk

ak

Pk

Pi : Pointeur interne permettant de reprsenter l'arbre; les feuilles ne contiennent pas de pointeurs Pi ;
ai : Pointeur externe sur une page de donnes ;
xi : valeur de cl.

Figure III.16 : Structure dun nud dun arbre B

De plus, lensemble des cls figurant dans larbre B doit tre tri selon lordre postfix induit par larbre, cela afin de permettre les recherches en un nombre daccs gal
au nombre de niveaux. Plus prcisment, en dsignant par K(Pi) lensemble des cls
figurant dans le sous-arbre dont la racine est pointe, on doit vrifier que :
1. (x1, x2xK) est une suite croissante de cls ;
2. Toute cl y de K(P0) est infrieure x1 ;
3. Toute cl y de K(P1) est comprise entre xi et xi+1 ;
4. Toute cl y de K(PK) est suprieure xk.
La figure III.17 reprsente un exemple dindex sous forme darbre B dordre 2. Cet
arbre contient les valeurs de cl de 1 26. Les flches entre les nuds reprsentent les
pointeurs internes, les traits courts issus dune cl les pointeurs externes vers les
articles. Dans la suite, nous omettrons les pointeurs externes, qui seront donc implicites.
11

1 2 3 4

6 7

16

9 10

12 13 14 15

21

17 18 19 20

Figure III.17 : Exemple dindex sous forme darbre B

22 23 24 26

La recherche dune cl dans un arbre B seffectue en partant de la racine. En rgle

gnrale, les valeurs contenues dans un nud partitionnent les valeurs possibles de
cls en un nombre dintervalles gal au nombre de branches. Ainsi, si la valeur cher-

Fichiers, hachage et indexation 87

che est infrieure la premire cl du nud, on choisit la premire branche ; si elle

est comprise entre la premire cl et la deuxime cl, on choisit la deuxime branche,
etc. Si une cl nest pas trouve aprs recherche dans un nud terminal, cest quelle
nexiste pas.
Le nombre de niveaux dun arbre B est dtermine par son degr et le nombre de cls
contenues. Ainsi, dans le pire des cas, si larbre est rempli au minimum, il existe :
une cl la racine,

deux branches en partent avec m cls,

(m+1) branches partent de ces dernires avec m cls,

etc.

Pour un arbre de niveaux h, le nombre de cls est donc :

N = 1 + 2 m (1+ (m+1) + (m+1)2 + + (m+1)h-2)

soit, par rduction du dveloppement limit :

N = 1 + 2 ((m+1)h-1-1).

Do lon dduit que pour stocker N cls, il faut :

h = 1 + logm+1 ((N+1)/2) niveaux.

Par exemple, pour stocker 1 999 999 cls avec un arbre B de degr 99,
h = 1 + log100106 = 4. Au maximum, quatre niveaux sont donc ncessaires. Cela
implique quun article dun fichier de deux millions darticles avec un index hirarchis organis comme un arbre B peut tre cherch en quatre entres-sorties.

Linsertion dune cl dans un arbre B est une opration complexe. Elle peut tre dfinie simplement de manire rcursive comme suit :

a) Rechercher le nud terminal qui devrait contenir la cl insrer et ly insrer en

bonne place ;

b)Si le nombre de cls aprs insertion de la nouvelle cl est suprieur 2 m, alors

migrer la cl mdiane au niveau suprieur, en rptant la procdure dinsertion dans
le nud suprieur.
titre dexemple, la figure III.18 reprsente les tapes ncessaires linsertion de la
cl (25) dans larbre B reprsent figure III.17. Tout dabord, la place de la cl 25 est
recherche. Celle-ci doit tre insre dans le dernier nud droite (tape a). Cela provoque un clatement du nud qui a maintenant plus de 2 m cls, soit 4. La cl
mdiane 24 doit tre remonte au niveau suprieur. Elle est alors insre aprs 21
(tape b). Le nud ayant trois cls, aucun autre clatement nest ncessaire.

88 BASES DE DONNES : OBJET ET RELATIONNEL

(a)

11

16

12

13

14

(b)

15

21

17

18

19

20

22

23

24

25

26

11

16

12

13

14

15

17

21

18

24

19

20

22

Figure III.18 : Insertion de la cl 25

23

25

26

La suppression dune cl soulve galement des problmes. Tout dabord, si lon supprime une cl non terminale, il faut remonter la cl suivante pour garder le partitionnement. De plus, si un nud a moins de m cls, il faut le regrouper avec le prcdent
de mme niveau afin de respecter la dfinition et de conserver entre m et 2m cls dans
un nud non racine.
Une variante de larbre B tel que nous lavons dcrit pour raliser des index est
larbre B* [Knuth73, Comer79], dans lequel lalgorithme dinsertion essaie de redistribuer les cls dans un nud voisin avant dclater. Ainsi, lclatement ne se produit
que quand deux nuds conscutifs sont pleins. Les deux nuds clatent alors en trois.
Les pages des index de type arbre B* sont donc en gnral mieux remplies que celles
des index de type arbre B.

5.1.5. Arbre B+

Lutilisation des arbres B pour raliser des fichiers indexs tels que dcrits ci-dessus
conduit des traitements squentiels coteux. En effet, laccs selon lordre croissant des
cls lindex ncessite de nombreux passages des pages externes aux pages internes.
Pour viter cet inconvnient, il a t propos de rpter les cls figurant dans les nuds
internes au niveau des nuds externes. De plus, les pages correspondant aux feuilles sont
chanes entre elles. On obtient alors un arbre B+. Larbre B+ correspondant larbre B
de la figure III.17 est reprsent figure III.19. Les cls 11, 8 et 21 sont rptes aux
niveaux infrieurs. Les pointeurs externes se trouvent seulement au niveau des feuilles.

Fichiers, hachage et indexation 89

11

1 2 3 4 5

26

11

6 7 8

16

9 10 11

12 13 14 15 16

21

26

17 18 20 21

22 23 24 26

Figure III.19 : Exemple dindex sous forme darbre B+

Les arbres B+ peuvent tre utiliss pour raliser des fichiers index hirarchiss de
deux manires au moins :
Larbre B+ peut tre utilis pour implmenter seulement les index. Autrement dit,
les articles sont stocks dans un fichier squentiel classique et larbre B+ contient
toutes les cls ainsi que les adresses darticles. Une telle organisation est proche de
celle propose par IBM sur les AS 400. Pour des raisons historiques, cette mthode
sappelle IS3.
Larbre B+ peut tre utilis pour implmenter fichiers et index. Dans ce cas, les
pointeurs externes sont remplacs par le contenu des articles. Les articles sont donc
tris. Seules les cls sont dplaces aux niveaux suprieurs qui constituent un index
non dense. Cette mthode correspond lorganisation squentielle indexe rgulire
dIBM sur MVS connue sous le nom de VSAM, et galement celle de BULL sur
DPS7, connue sous le nom de UFAS.

5.2. ORGANISATION INDEXE IS3

Cette organisation est voisine de celle dveloppe tout dabord sur les systmes de la
srie 3 dIBM. Les articles sont rangs en squentiel dans un fichier dont lindex est
dense et organis sous forme dun arbre B+.
Notion III.27 : Fichier index (Indexed file)
Fichier squentiel non tri, dindex tri dense organis sous la forme dun arbre B+.

90 BASES DE DONNES : OBJET ET RELATIONNEL

Linterprtation de la dfinition que constitue la notion III.27 soulve plusieurs problmes. Tout dabord, comment est dfini lordre de larbre B+ qui constitue lindex ?
La solution consiste diviser lindex en pages (une page = 1 p secteurs). Lors de la
premire criture, les pages ne sont pas compltement remplies. Lors dune insertion,
si une page est pleine elle est clate en deux pages demi pleines. La cl mdiane est
remonte au niveau suprieur.
Un deuxime problme consiste garder un index dense. En fait, celui-ci est dense au
dernier niveau. Autrement dit, toutes les cls darticles sont gardes au plus bas niveau.
Ainsi, quand une page clate, la cl mdiane devient la plus grande cl de la page gauche
rsultant de lclatement. Cette cl est donc duplique au niveau suprieur de lindex. La
figure III.20 illustre une insertion dans un fichier index IS3. Linsertion provoque
lclatement de lunique page index et la cration dune page index de niveau suprieur.
(A) tat avant insertion de (7)

Fichier
1

12

15

5
12
15
Index
(B) tat aprs insertion de (7)
1

12

15

15

La cl 15 est reporte
pour permettre une
meilleure optimisation.

12
15

Figure III.20 : Insertion dans un fichier IS3

Un dernier problme est celui du stockage de lindex. Celui-ci peut tre stock en fin
de fichier. Il est ainsi possible de lire la page suprieure de lindex en mmoire centrale lors du dbut dun travail sur un fichier, puis de la rcrire en fin de travail. Il est
aussi possible, avec une telle mthode denregistrement des index, de garder les ver-

Fichiers, hachage et indexation 91

sions historiques des index condition que les nouveaux articles crits le soient aprs
le dernier index enregistr, cest--dire en fin de fichier.

La mthode daccs et lorganisation associe IS3 prsentent plusieurs avantages : linsertion des articles est simple puisquelle seffectue en squentiel dans le fichier ; il est possible de garder des versions historiques des index. Les performances de la mthode sont
satisfaisantes. Si m est le nombre de cls par page dindex, du fait de lorganisation de
lindex en arbre B+, le nombre dentres-sorties ncessaires pour lire un article dans un
fichier de N articles reste infrieur ou gal 2 + log(m/2) ((N+1)/2). Une criture ncessite
en gnral deux accs, sauf dans les cas dclatement de page index o il faut une lecture
et deux critures de plus par niveau clat. En pratique, et titre dexemple, un fichier de
moins de 106 articles ne ncessitera pas plus de trois entres-sorties en lecture.

Cette mthode prsente cependant trois inconvnients srieux :

Du fait de la sparation des articles et de lindex, les mouvements de bras des
disques sont en gnral importants.
La lecture en squentiel par cl croissante doit se faire par consultation de lindex et
est en consquence trs coteuse.
Lindex est dense et donc de grande taille si aucune technique de compactage de
cls nest mise en uvre.

5.3. ORGANISATION SQUENTIELLE INDEXE ISAM

5.3.1. Prsentation gnrale

Il sagit de lorganisation IBM utilise dans les systmes DOS, OS/VS, MVS et
connue sous le nom ISAM (Indexed Sequential Acces Method) [IBM78]. Le fichier
est organis physiquement selon un dcoupage en pistes et cylindres. Cette mthode
trs ancienne reste populaire malgr son manque dindpendance physique.
Notion III.28 : Fichier squentiel index (Indexed sequential file)
Fichier tri dindex tri non dense compos dune zone primaire et dune zone de dbordement ;
une piste sature dborde dans une extension logique constitue par une liste darticles en dbordement.

Un fichier ISAM comporte trois zones logiques :

une zone primaire o lon crit les articles la premire criture ;
une zone de dbordement o lon transfre les articles lors des additions au fichier ;
une zone dindex o lon crit les index.
Ci-dessous nous tudions successivement chacune des zones.

92 BASES DE DONNES : OBJET ET RELATIONNEL

5.3.2. tude de la zone primaire

La zone primaire se compose de cylindres successifs dont certaines pistes sont rserves pour lindex et les zones de dbordement. En zone primaire, les articles sont
enregistrs par ordre croissant des cls. Ils peuvent tre bloqus ou non. Lors de la
premire criture du fichier, les articles doivent tre dlivrs au systme de fichiers
par ordre croissant des cls. La figure III.21 illustre un fichier ISAM aprs une premire criture. Ce fichier est compos de deux cylindres. Chaque cylindre comporte
deux pistes de donnes et une piste rserve pour les index.

} Pistes dindex

5
14

7
17

Cylindre 0

21

23

29

27

31

Cylindre 1

} Pistes
de dbordement

Figure III.21 : Fichier ISAM aprs une premire criture des articles 1, 3, 5, 7, 9, 14, 17, 21, 23,
27, 29, 31 (dans lordre)

5.3.3. tude de la zone de dbordement

Il existe deux types de zones de dbordement : la zone de dbordement de cylindre

compose de quelques pistes sur chaque cylindre et la zone de dbordement indpendante, compose des derniers cylindres du fichier (voir figure III.22).

Zone de dbordement
de cylindre

Zone de dbordement
indpendante

Figure III.22 : Zones de dbordement dun fichier ISAM.

En zone de dbordement, les articles ne sont pas bloqus. Ils sont chans entre eux
afin de reconstituer la piste qui a dbord de manire logique. Quand un article est
insr, on recherche sa squence dans la piste logique. Sil est plac en zone primaire,
les articles suivants sont dplacs et le dernier est crit en zone de dbordement. Les

Fichiers, hachage et indexation 93

chanages sont mis jour. Sil vient en zone de dbordement, il est crit dans cette
zone et est insr en bonne place dans la chane des articles en dbordement.

La zone de dbordement de cylindre est tout dabord utilise. Lorsquelle est sature,
la zone de dbordement indpendante est utilise. Dans ce cas, comme le chanage est
effectu par ordre croissant des cls, il est possible quil parte de la zone de dbordement de cylindre, pointe en zone de dbordement indpendante, puis revienne en zone
de dbordement de cylindre, etc. Alors, la mthode devient particulirement peu performante pour rechercher un article dans une piste ayant dbord, du fait des dplacements de bras.

5.3.4. tude de la zone index

Il existe obligatoirement deux niveaux dindex et optionnellement trois : les index de

pistes, les index de cylindres et le (ou les) index matre(s).

Le premier niveau dindex obligatoire est lindex de piste. Il en existe un par cylindre,
en gnral contenu sur la premire piste du cylindre. Chaque entre correspond une
piste du cylindre et fournit la plus grande cl de la piste logique en zone de dbordement ainsi que ladresse du premier article en zone de dbordement sil existe. La
figure III.23 illustre le format de lindex de piste. Chaque piste est dcrite par une
double entre comportant, en plus des adresses, la plus grande cl en zone primaire et
la plus grande cl en zone de dbordement.
CD

PCP
Entre piste 0

PCD

Entre piste 1

PCP

PCD

Entre piste n

CD = Contrle de dbordement prcisant ladresse du dernier article de

la zone de dbordement.
PCP = Plus grande cl en zone primaire et adresse de la piste.
PCD = Plus grande cl en zone de dbordement et adresse du premier
article en zone de dbordement.

Figure III.23 : Format de lindex de piste

Le deuxime niveau de lindex obligatoire est lindex de cylindre. Il existe un index

de cylindre par fichier. Cet index contient une entre par cylindre comportant la plus
grande cl du cylindre ainsi que ladresse du cylindre. Lindex de cylindre est gnralement rang dans une zone particulire, par exemple en dbut de zone de dbordement indpendante. Cet index permet, partir dune cl darticle, de slectionner le
cylindre o doit se trouver larticle.
Le troisime niveau dindex est optionnel : cest lindex matre. Il est utilis quand
lindex de cylindre est trop grand afin dacclrer les recherches. Il existe une entre

94 BASES DE DONNES : OBJET ET RELATIONNEL

en index matre par piste de lindex de cylindre. Cette entre contient ladresse de la
piste et la valeur de la plus grande cl dans la piste.

5.3.5. Vue densemble

La figure III.24 donne une vue densemble dun fichier ISAM aprs insertion
darticles, avec seulement deux niveaux dindex. Bien que seulement les chanages du
premier cylindre soient reprsents, on notera le grand nombre de chanages. La premire piste logique est constitue des articles a0, a1, a2 et a4 ; a0, a1, a2 sont en zone
primaire ; a3 et a4 sont en zone de dbordement de cylindre. Les articles a5, a6, a7, a8
et a9 sont rangs dans la deuxime piste logique ; a8 est en dbordement de cylindre
et a9 en zone de dbordement indpendante.
Index cylindres et
Zone de dbordement
indpendante
a2 a4 a7 a9

Pistes dindex

a0
Zones
primaires
Zones de
dbordement

a5

a3 a4

a10

a11

a7

a14

a15

a8

Cylindre 0

a15
a15

a2

a1
a6

a11
a13

a9 a15
a9

a12 a13
Cylindre 1

Figure III.24 : Vue densemble dun fichier ISAM

(Les pointeurs issus du cylindre 1 ne sont pas reprsents.)

Cylindre 2

Les avantages de la mthode sont que le fichier est tri, ce qui facilite laccs en
squentiel tri, ainsi que les temps daccs tant que le fichier na pas dbord (3 E/S
pour lire un article). Les inconvnients sont essentiellement lis aux dbordements. La
gestion des dbordements est complexe et dgrade les performances, de sorte quil est
ncessaire de rorganiser priodiquement les fichiers ayant dbord. Le fait que la
mthode daccs ne soit pas indpendante des caractristiques physiques du support
(pistes, cylindres) amliore les performances, mais rend le changement de support
difficile. En fait, les performances dpendent des dbordements. Si une piste com-

Fichiers, hachage et indexation 95

porte des articles en dbordement, une lecture ncessitera approximativement 3+[d/2]

entres-sorties alors quune criture demandera 2+[d/2]+4 entres-sorties, cela afin de
trouver la position de larticle, de lcrire et de mettre jour les chanages. Cela peut
devenir trs coteux.

5.4. ORGANISATION SQUENTIELLE INDEXE

RGULIRE VSAM
5.4.1. Prsentation gnrale

Il sagit de lorganisation IBM utilise dans les systmes IBM et connue sous le nom
de VSAM (Virtual Sequential Acces Method) [IBM87]. la diffrence de ISAM,
VSAM assure lindpendance des fichiers au support physique et une rorganisation
progressive du fichier, sans gestion de dbordement. VSAM est une organisation
base sur les principes des arbres B+.
Notion III.29 : Fichier squentiel index rgulier (Virtual sequential file)
Fichier tri dindex tri non dense dont lensemble fichier plus index est organis sous forme dun
arbre B+.

Afin dassurer lindpendance des fichiers aux supports physiques, des divisions
logiques sont introduites. Le fichier est divis en aires, une aire tant un ensemble de
pistes du mme cylindre ou de cylindres contigus. Chaque aire est elle-mme divise
en intervalles, un intervalle tant gnralement compos dune partie de piste ou de
plusieurs pistes conscutives lue(s) en une seule entre-sortie. Lintervalle correspond
la feuille de larbre B+. Lorsquun intervalle est satur, il clate en deux intervalles ;
lorsquune aire est sature, elle clate aussi en deux aires, si bien que le fichier se
rorganise de lui-mme par incrments.
Cette organisation rsulte dune tude critique de ISAM. Cette fois, le fichier est plus indpendant de la mmoire secondaire : la piste est remplace par lintervalle qui peut tre une
fraction de piste ou plusieurs pistes, le cylindre est remplac par la notion daire. Les
dbordements ne perturbent plus lorganisation puisque le mcanisme de dbordement est
celui de larbre B+, cest--dire quun intervalle ou une aire saturs clatent en deux.

5.4.2. tude de la zone des donnes

Cette zone qui contient les articles est donc divise en intervalles et aires, comme sur la
figure III.25. Lors de la premire criture, comme avec des fichiers squentiels indexs
ISAM, les articles sont enregistrs tris, cest--dire que le programme doit les dlivrer
la mthode daccs dans lordre croissant des cls. Cette fois, les mises jour sont pr-

96 BASES DE DONNES : OBJET ET RELATIONNEL

vues: de la place libre est laisse dans chaque intervalle et des intervalles libres sont laisss dans chaque aire afin de permettre les insertions de nouveaux articles.
titre dexemple, le fichier de la figure III.25 a t cr avec les paramtres suivants :
pourcentage doctets libres par intervalle = 25 ;
pourcentage dintervalles libres par aire = 25.

Lors de la premire criture, le programme crant le fichier a dlivr au systme les

articles suivants (dans lordre) : 1, 5, 7, 9, 15, 20, 22, 27, 30, 31, 33, 37, 40, 43, 47, 51, 53.
Zone index
1

Zone index
15

31

51

27

43

47

37

20

22

40

33

53

30
Aire 0 compose de quatre intervalles

Aire 1 compose de quatre intervalles

Figure III.25 : Fichier squentiel index rgulier aprs premire criture

Lalgorithme dinsertion dun article consiste dterminer, grce aux index, lintervalle qui doit contenir larticle. Ensuite, deux cas sont possibles :
a) Si lintervalle nest pas plein, alors larticle est rang dans lintervalle, en bonne
place dans lordre lexicographique des cls. Par exemple, linsertion de larticle de
cl 10 conduira la substitution dintervalle reprsente figure III.26.
9

15

10

15

20

Insertion de 10
20

Figure III.26 : Insertion de larticle de cl 10 dans le fichier prcdent

b)Si lintervalle est plein, alors il clate en deux intervalles demi pleins. Deux souscas sont encore possibles :
b1) Sil existe un intervalle libre dans laire, celui-ci est utilis afin de stocker lun
des deux intervalles rsultant de lclatement. Par exemple, linsertion de

Fichiers, hachage et indexation 97

larticle de cl 13 dans le fichier obtenu aprs insertion de larticle de cl 10 (Fig.

III.26) conduit au fichier reprsent figure III.27.
b2) Sil nexiste pas dintervalle libre dans laire, on alloue alors une aire vide au
fichier et on clate laire sature en deux demi pleines ; pour cela, la moiti des
intervalles contenant les articles de plus grandes cls sont recopis dans laire
nouvelle. Par exemple, linsertion des articles de cls 11 et 12 dans le fichier de la
figure III.27 conduit au fichier reprsent figure III.28. Une nouvelle aire a t
cre afin de ddoubler la premire aire du fichier qui tait sature.
Zone index
1

7
22

Zone index
10

31

15

20

51

43

47

37

13
27

40

33

53

30
Aire 0 compose de quatre intervalles

Aire 1 compose de quatre intervalles

Figure III.27 : Fichier aprs insertion des articles de cls 10 et 13

Zone index
1

7
12

9
11

13

Zone index

Zone index
10

31

33

37

51

40

43

15

20

47

22

27

30

53

Figure III.28 : Fichier aprs insertion des articles 11 et 12

5.4.3. tude de la zone index

Il peut exister deux ou trois niveaux dindex. Le premier est appel index dintervalles. Il en existe un par aire. Chaque entre contient la plus grande cl de linter-

98 BASES DE DONNES : OBJET ET RELATIONNEL

valle correspondant ainsi que son adresse. Le deuxime niveau est appel index
daires. Il en existe un par fichier. Chaque entre contient la plus grande cl de laire
correspondante ainsi que ladresse de laire. Il est galement possible, dans le cas o
lindex daire est trop grand (par exemple plus dune piste), de faire grer au systme
un index de troisime niveau appel index matre et permettant daccder directement la partie pertinente de lindex daire. titre dillustration, la figure III.29
reprsente les index dintervalles et daires du fichier reprsent figure III.28. Chaque
entre reprsente une cl suivie dune adresse dintervalle ou daire.
7.0

11.1

13.2

37.0

Index dintervalles
aire 0

47.1

53.2

Index dintervalles
aire 1

20.0

30.1

Index dintervalles
aire 2
13.0

30.2

53.1

Index d'aires

Figure III.29 : Index du fichier reprsent figure III.28

5.4.4. Vue densemble

La figure III.30 donne une vue densemble dun autre fichier VSAM compos de
deux aires, avec seulement deux niveaux dindex. Chaque aire possde donc un index
dintervalles. Lindex daires constitue ici la racine de larbre B+. Il indique que 17 est
la plus grande cl de laire 0, alors que 32 est la plus grande de laire 1.
Les avantages de la mthode sont que le fichier est physiquement tri, ce qui facilite
les accs en squentiel tri, ainsi que les temps daccs un article : la lecture seffectue en gnral en trois entres-sorties. Les inconvnients sont peu nombreux.

Fichiers, hachage et indexation 99

Cependant lcriture peut parfois tre trs longue dans le cas dclatement dintervalles ou, pire, dans le cas dclatement daires. En fait, les critures ne seffectuent
pas en un temps constant : certaines sont trs rapides (4 E/S lorsquil ny a pas dclatement), dautres sont trs longues (lorsquil y a clatement daire).
17.0

3.0
1

9.1
2

17.2
5

32.1

21.0
7

19 21

27.1

32.2
22 27

14 17

30 32

Figure III.30 : Vue densemble dun fichier squentiel index rgulier

6. MTHODES DACCS MULTI-ATTRIBUTS

Les mthodes daccs tudies jusque-l permettent de dterminer ladresse dun

article dans un fichier partir de la valeur dune donne unique de larticle, appele
cl. Nous allons maintenant prsenter des mthodes qui permettent daccder rapidement un groupe darticles partir des valeurs de plusieurs donnes, aucune dentre
elles ntant en gnral discriminante.

6.1. INDEX SECONDAIRES

Le problme pos est de dterminer ladresse dun ou plusieurs articles partir de la

valeur de plusieurs donnes de cet article, aucune dentre elles ne permettant en principe de dterminer elle seule le ou les articles dsirs. La solution la plus simple est
dutiliser plusieurs index, chacun deux ntant pas discriminant. On appelle index
secondaire un index non discriminant.

100 BASES DE DONNES : OBJET ET RELATIONNEL

Notion III.30 : Index secondaire (Secondary Index)

Index sur une donne non discriminante, donnant pour chaque valeur de la donne la liste des
adresses darticles ayant cette valeur.

Par exemple, un index secondaire dun fichier dcrivant des vins pourra porter sur le
champ cru. Les entres correspondront aux diffrents crus (Chablis, Medoc, Volnay,
etc.) et donneront pour chaque cru la liste des adresses darticles correspondant ce
cru. Ainsi, en accdant lentre Volnay, on trouvera la liste des Volnay.

Un index secondaire est souvent organis comme un arbre B, bien que dautres organisations soient possibles. En particulier, un index secondaire peut tre un fichier
part, servant dindex au fichier principal. On parle alors de fichier inverse, le fichier
contenant lindex apparaissant comme une structure de donnes en quelque sorte renverse par rapport au fichier principal. Un fichier avec un index secondaire (ou un
fichier inverse) est en gnral index ou hach sur une cl discriminante (par exemple,
le numro de vin). On parle alors de cl primaire. Par opposition, le champ sur lequel
lindex secondaire est construit (par exemple, le cru) est appel cl secondaire. Un
fichier peut bien sr avoir plusieurs cls secondaires, par exemple cru et rgion pour
le fichier des vins.

La question qui se pose alors concerne la recherche dun article dans le fichier. Si plusieurs cls secondaires sont spcifies (par exemple, cru = Volnay et
rgion= Bourgogne), on peut avoir intrt choisir un index (ici le cru), puis lire
les articles correspondant en vrifiant les autres critres (ici, que la rgion est bien
Bourgogne). Dans certains cas o aucune donne nest a priori plus discriminante
quune autre, on aura au contraire intrt lire les diffrentes entres dindex slectionnes, puis faire lintersection des listes dadresses darticles rpondant aux diffrents critres. Finalement, un accs aux articles rpondant tous les critres (ceux
dont ladresse figure dans lintersection) sera suffisant.

Un autre problme pos par la gestion dindex secondaires est celui de la mise jour.
Lors dune mise jour dun article du fichier principal, il faut mettre jour les index
secondaires. Bien sr, si la valeur dindexation est change, il faut enlever larticle de
lentre correspondant lancienne valeur, puis linsrer dans lentre correspondant
la nouvelle valeur. Cette dernire doit tre cre si elle nexiste pas. Plus coteux,
avec les mthodes daccs utilisant lclatement de paquets, il faut aller modifier dans
les index secondaires les adresses des articles dplacs lors des dplacements
darticles. On peut avoir alors intrt garder des rfrences invariantes aux dplacements darticles dans les index secondaires. Une solution consiste garder les cls
primaires la place des adresses, mais cela cote en gnral un accs via un arbre B.
En rsum, bien que prsentant quelques difficults de gestion, les index secondaires
sont trs utiles pour acclrer les recherches darticles partir de valeurs de donnes.
Ils sont largement utiliss dans les SGBD. Sils permettent bien damliorer les temps

Fichiers, hachage et indexation 101

de rponse lors des interrogations, ils pnalisent les mises jour. Il faut donc indexer
les fichiers seulement sur les donnes souvent documentes lors de linterrogation.

6.2. HACHAGE MULTI-ATTRIBUT

Avec le hachage, il est possible de dvelopper des mthodes daccs portant sur de multiples champs (ou attributs) en utilisant plusieurs fonctions de hachage, chacune tant
applique un champ. En appliquant N fonctions de hachage N attributs dun article,
on obtient un vecteur constituant une adresse dans un espace N dimensions. Chaque
coordonne correspond au rsultat dune fonction de hachage. partir de cette adresse,
plusieurs mthodes sont possibles pour calculer le numro de paquet o ranger larticle.
Une telle approche est la base des mthodes dites de placement multi-attribut.
Notion III.31 : Placement multi-attribut (Multiattribute clustering)
Mthode daccs multidimensionnelle dans laquelle ladresse dun paquet darticles est dtermine
en appliquant des fonctions de hachage diffrents champs dun article.

6.2.1. Hachage multi-attribut statique

Une mthode simple est le placement multi-attribut statique. La mthode consiste

concatner les rsultats des fonctions de hachage dans un ordre prdfini. La chane
binaire obtenue est alors directement utilise comme adresse de paquet. On obtient
donc un hachage statique partir dune fonction portant sur plusieurs attributs. Si A1,
A2 An sont les attributs de placement, chacun est transform par application dune
fonction de hachage en bi bits de ladresse du paquet. Si hi est la fonction de hachage
applique lattribut bi, le numro de paquet o placer un article est obtenu par
a = h1(A1) || h2(A2) || hn(An), o la double barre verticale reprsente lopration
de concatnation. Le nombre total de bits du numro de paquet est B = b1+b2+ bn.
Pour retrouver un article partir de la valeur dun attribut, disons Ai, le systme devra
seulement balayer les paquets dadresse x || hi(Ai) ||y, o x reprsente toute squence
de b1 + bi-1 bits et y toute squence de bi+1+ bn bits. Ainsi, le nombre de
paquets balayer sera rduit de 2**B 2**(B-bi). Le nombre optimal de bits
allouer lattribut Ai dpend donc de la frquence dutilisation de cet attribut pour
linterrogation. Plus cette frquence sera leve, plus ce nombre sera important ;
lattribut sera ainsi privilgi aux dpens des autres.

6.2.2. Hachages multi-attributs dynamiques

Lutilisation de techniques de hachage dynamique est aussi possible avec des

mthodes de placement multi-attribut. Lapproche la plus connue est appele fichier

102 BASES DE DONNES : OBJET ET RELATIONNEL

grille, ou grid file en anglais [Nievergelt84]. La mthode peut tre vue comme une
extension du hachage extensible. Une fonction de hachage est associe chaque attribut de placement. Ladresse de hachage multidimensionnelle est constitue dun
nombre suffisant de bits choisi en prlevant des bits de chacune des fonctions de
hachage de manire circulaire. Cette adresse sert de pointeur dans le rpertoire des
adresses de paquets. Tout se passe donc comme avec le hachage extensible, mais avec
une fonction de hachage multi-attribut mixant les bits des diffrentes fonctions composantes.

Afin de clarifier la mthode, une reprsentation par une grille multidimensionnelle du

fichier est intressante. Pour simplifier, supposons quil existe seulement deux attributs de placement A1 et A2. Au dpart, le fichier est compos dun seul paquet qui
dlimite la grille (voir figure III.31.a). Quand le fichier grossit au fur et mesure des
insertions, le paquet sature. Il est alors clat en deux paquets B0 et B1 selon la
dimension A1 (voir figure III.31.b). Pour ce faire, le premier bit de la fonction de
hachage applique A1 (h1(A1)) est utilis. Quand lun des paquets, disons B0, est
plein, il est son tour clat en deux paquets B00 et B01, cette fois selon lautre
dimension. Le premier bit de la fonction de hachage applique A2 (h2(A2)) est utilis. Si lun des paquets B00 ou B01 devient plein, il sera son tour clat, mais cette
fois selon la dimension A1. Le processus dclatement continue ainsi alternativement
selon lune ou lautre des dimensions.

Pour retrouver un article dans un paquet partir de valeurs dattributs, il faut appliquer les fonctions de hachage et retrouver ladresse du ou des paquets correspondants
dans le rpertoire des paquets. Pour cela, la mthode propose un rpertoire organis
comme un tableau multidimensionnel. Chaque entre dans le rpertoire correspond
une rgion du fichier grille. Le rpertoire est stock continment sur des pages
disques, mais est logiquement organis comme un tableau multidimensionnel. Par
exemple, avec un placement bidimensionnel, ladresse dun paquet pour la rgion (i,j)
sera dtermin par une transformation dun tableau bidimensionnel un rpertoire
linaire : lentre 2**N*i + j sera accde, N tant le nombre maximal dclatement
dans la dimension A1. Ainsi, lors dun clatement un niveau de profondeur supplmentaire dune dimension, il faut doubler le rpertoire selon cette dimension. Cela
peut seffectuer par recopie ou chanage. En rsum, on aboutit une gestion de
rpertoire complexe avec un rpertoire qui grossit exponentiellement en fonction de la
taille des donnes.

Pour amliorer la gestion du rpertoire et obtenir une croissance linaire avec la taille
des donnes, plusieurs approches on t proposes. Une des plus efficaces est utilise
par les arbres de prdicats [Gardarin83]. Avec cette mthode, lensemble des fonctions
de hachage est ordonn selon les frquences dcroissantes daccs (les attributs les plus
souvent documents lors des interrogations dabord). Pour simplifier, supposons que
lordre soit de A0 An. Un arbre de placement permet dillustrer les clatement de
paquets (voir figure III.32). Au premier niveau, les paquets clatent progressivement

Fichiers, hachage et indexation 103

selon les bits de la fonction de hachage h(A1). Quand tous les bits sont exploits, on utilise la fonction h2(A2), etc. Ainsi, chaque paquet est une feuille de larbre de placement
caractrise par une chane de bits plus ou moins longue correspondant aux clatements
successifs. Cette chane de bits est appele signature du paquet.
A2

(a)
Paquet B
A1
A2

clatement 1

(b)
B0

B1
A1

A2

(c)

clatement 2

B01
B00
A1
A2

(d)

clatement 3

B010 B011

A1

Figure III.31 : clatement de paquets dans un fichier grille

Le rpertoire contient des doublets <signature de paquet, adresse de paquet>. Le

rpertoire est organis lui-mme comme un fichier plac par un arbre de prdicats correspondant aux bits de la signature (chaque bit est considr comme un attribut hach
par lidentit). Sa taille est donc linaire en fonction du nombre de paquets du fichier

104 BASES DE DONNES : OBJET ET RELATIONNEL

de donnes. Pour rechercher un article partir dattributs connus, un profil de signature est labor. Les bits correspondant aux attributs connus sont calculs et les autres
mis la valeur inconnue. Ce profil est utilis pour accder au rpertoire par hachage.
Il permet de dterminer les paquets balayer. Des valuations et des exprimentations
de la mthode ont dmontr son efficacit en nombre dentres-sorties [Gardarin83].
Dautres mthodes similaires ont t proposes afin de rduire la taille du rpertoire et
de profiter dun accs slectif [Freeston87].
Rpertoire
Signatures

Adresses paquets

00

10

01

011

111

Figure III.32 : Arbre de placement et rpertoire associ

6.3. INDEX BITMAP

Lutilisation dindex sous forme darbres B sur un champ ayant peu de valeur conduit
des difficults. En effet, pour de gros fichiers les listes dadresses relatives darticles
deviennent longues et lourdes manipuler. Il est bien connu quun index sur le sexe
dun fichier de personnes est inutile : il alourdit fortement les mises jour et naide
pas en interrogation, car il conduit accder directement la moiti des articles, ce
qui est pire quun balayage. Les index bitmap ont t introduits dans le SGBD
Model 204 [ONeil87] pour faciliter lindexation sur des attributs nombre de valeurs
limits. Ils ont t plus tard gnraliss [ONeil97, Chan98].
Notion : Index bitmap (Bitmap index)
Index sur une donne A constitu par une matrice de bits indiquant par un bit 1 en position (i, j)
la prsence de la je valeur possible de lattribut index A pour larticle i du fichier, et son absence
sinon.

Un index bitmap suppose lexistence dune fonction permettant dassocier les

N valeurs possibles de lattribut index A de 0 N-1. Cette fonction peut tre lordre

Fichiers, hachage et indexation 105

alphanumrique des valeurs. Cest alors une bijection. La figure III.33 donne un
exemple dindex bitmap pour un fichier de sportifs sur lattribut sport.
Donnes
Sport
Personne
Perrec
Cantona
Virenque
Leconte
Barthez
Jalabert
Pioline

Athltisme
Foot
Vlo
Tennis
Foot
Vlo
Tennis

Index bitmap
Athltisme Foot Tennis Vlo
1
0
0
0
0
0
0

0
1
0
0
1
0
0

Figure III.33 : Exemple dindex bitmap simple

0
0
0
1
0
0
1

0
0
1
0
0
1
0

Les index bitmap sont particulirement adapts la recherche. Par exemple, la

recherche des sportifs pratiquant le vlo seffectue par lecture de lindex, extraction de
la colonne Vlo et accs tous les articles correspondant un bit 1. On trouvera
ainsi Virenque et Jalabert. Laccs larticle seffectue partir du rang du bit, 3 pour
Virenque, 6 pour Jalabert. Pour faciliter cet accs, le fichier doit tre organis en
pages avec un nombre fixe p darticles par page. Si j est le rang du bit trouv, la page
j/p doit tre lue et larticle correspondant au je cherch dans cette page. Fixer le
nombre darticle par page peut tre difficile en cas darticles de longueurs variables.
Des pages de dbordement peuvent alors tre prvues.
Un index bitmap peut aussi permettre dindexer des attributs possdant des valeurs
continues en utilisant une fonction non injective, cest--dire en faisant correspondre
une colonne de la bitmap plusieurs valeurs dattributs. Une technique classique
consiste associer chaque colonne une plage de valeurs de lattribut index. Par
exemple, la figure III.34 illustre un index bitmap de lattribut Cot utilisant des plages
de valeurs de 0 100. Lors dune recherche sur valeur, on choisira la bonne plage,
puis on accdera aux articles correspondant aux bits 1, et on testera plus exactement
le critre sur les donnes de larticle. Par exemple, la recherche dun produit de
cot 150 conduira accder la 2e colonne, puis aux articles 1, 3, et 4. Seul larticle 3
sera finalement retenu.

Enfin, un index bitmap peut tre utilis pour indexer des attributs multivalus, tel
lattribut Produits figure III.34. Pour chaque article, les bits de chacune des
colonnes correspondant aux valeurs de lattributs sont positionns 1.

Les index bitmap sont particulirement utiles pour les accs sur des attributs multiples
ou sur des valeurs multiples dun mme attribut. Il suffit pour cela deffectuer des
unions ou intersections de vecteurs de bits. Par exemple, la slection des mnagres
ayant achet les produits P1 ou P2 avec un cot total suprieur 100 seffectuera par
union des colonnes 1 et 2 de la bitmap index produits, puis intersection avec la

106 BASES DE DONNES : OBJET ET RELATIONNEL

colonne 3 unit la colonne 2 de la bitmap index cot. On obtient alors un vecteur de

bits qui dsigne les mnagres 1 et 4. Les index bitmap sont donc trs utile pour les
accs multi-attributs. Ils sont aussi utiliss pour calculer des agrgats, voire extraire
des rgles des bases de donnes, comme nous le verrons plus tard. Les limites de cette
technique dveloppe rcemment sont encore mal cernes.
Index cot
Fichier de donnes
Mnagre

1
2
3
4
5

Produits

Cot

{P1, P3, P5}

{P2, P3}
{P4}
{P2, P5}
{P3,P4,P6}

120
70
150
110
220

0-100

100-200

200-300

0
1
0
0
0

1
0
1
1
0

0
0
0
0
1

Index produits
P1

P2

P3

P4

P5

P6

1
0
0
0
0

0
1
0
1
0

1
1
0
0
1

0
0
1
0
1

1
0
0
1
0

0
0
0
0
1

Figure III.34 : Exemple dindex bitmap plus complexes

7. CONCLUSION

Nous venons de passer en revue les fonctions essentielles et les techniques de base des
gestionnaires de fichiers. Dautres tudes peuvent tre trouves, par exemple dans
[Korth91] et [Widerhold83]. Il faut savoir quun gestionnaire de fichiers est de plus en
plus souvent la base dun systme de gestion de bases de donnes. Pour ce faire, des
niveaux de logiciels suprieurs sont gnralement implants pour assurer loptimisation des recherches, la description centralise des donnes des articles de fichiers, des
interfaces de gestion de donnes varies avec les programmes dapplication, etc.
La ncessit de pouvoir supporter un Systme de Gestion de Bases de Donnes
(SGBD) tend aujourdhui rendre le gestionnaire de fichiers de plus en plus labor.

Fichiers, hachage et indexation 107

Il est par exemple possible de trouver des systmes grant plusieurs index secondaires
pour un mme fichier plac selon un hachage extensible ventuellement multi-attribut. En effet, pour permettre la consultation des donnes selon des critres varis, les
SGBD ncessitent gnralement plusieurs chemins daccs un mme article. Nous
reviendrons sur les problmes de mthodes daccs et dorganisation de fichiers pour
les systmes de gestion de bases de donnes dans le chapitre spcifique aux modles
daccs, puis plus tard pour les donnes multimdias.

8. BIBLIOGRAPHIE

[Bayer72] Bayer R., McCreight C., Organization and Maintenance of Large Ordered
Index , Acta Informatica, vol. 1, n 3, 1972, p. 173-189.
Un des premiers articles introduisant lorganisation des index par arbres B et
dmontrant les avantages de cette organisation pour de gros fichiers.

[Chan98] Chan C-Y., Ioannidis Y.E., Bitmap index Design and evaluation , ACM
SIGMOD Intl. Conf., SIGMOD Record V 27, n 2, Seattle, USA, 1998.
Cet article tudie la conception dindex bitmap pour traiter des requtes complexes sur de grandes bases de donnes. En particulier, les techniques de mapping des valeurs dattributs sur les indices de colonnes sont prises en compte et
diffrents critres doptimalit des choix sont tudis.
[Comer79] Comer D., The Ubiquitous B-Tree , Computing Surveys, vol. 11, n 2,
juin 1979.
Une revue trs complte des organisations bases sur les arbres B. Diffrentes
variantes, dont les arbres B+, sont analyses.

[Daley65] Daley R.C., Neuman P.G., A General Pupose File System for Secondary
Storage , Fall Joint Computer Conference, 1965, p. 213-229.
Une prsentation de la premire version du systme de fichiers de MULTICS.
Ce systme introduit pour la premire fois une organisation hirarchique des
catalogues de fichiers. Lintrt de noms hirarchiques et bass pour dsigner
un fichier est dmontr. Le partage des fichiers par liens est introduit.

[Fagin79] Fagin R., Nivergelt J., Pippengar N., Strong H.R., Extendible Hahing A
Fast Access Method for Dynamic Files , ACM TODS, vol. 4, n 3, septembre
1979, p. 315-344.
Larticle de base sur le hachage extensible. Il propose dutiliser un rpertoire
dadresses de paquets adress par exploitation progressive des bits du rsultat
de la fonction de hachage. Les algorithmes de recherche et de mise jour sont
dtaills. Une valuation dmontre les avantages de la mthode aussi bien en
temps daccs quen taux de remplissage.

108 BASES DE DONNES : OBJET ET RELATIONNEL

[Freeston87] Freeston M., The BANG file A New Kind of Grid File , ACM SIGMOD, mai 1987, San Fransisco, ACM Ed., p. 260-269.
Cet article prsente une variante du fichier grille, avec laquelle le rpertoire
reste linaire en fonction de la taille des donnes. La technique est voisine de
celle des signatures dveloppes dans les arbres de prdicats, mais les attributs
ne sont pas ordonns et le rpertoire des signatures dispose dune organisation
particulire. Le BANG file a t implment lECRC le centre de recherche
commun BULL, ICL, SIEMENS Munich et a servi de base au systme de
bases de donnes dductives EKS.

[Gardarin83] Gardarin G., Valduriez P., Vimont Y., Predicate Tree An Integrated
Approach to Multi-Dimensional Searching , Rapport de recherche INRIA,
n 203, avril 1983.
Cet article prsente la mthode daccs multi-attributs des arbres de prdicats.
Cette mthode part dune spcification dune suite de collections de prdicats
disjoints, chaque collection portant sur un attribut. La suite de collection permet daffecter une signature chaque tuple constitue par la concatnation des
numros de prdicats satisfaits. La signature est exploite progressivement bit
bit pour placer les donnes sur disques. L ide cl est de permettre un accs
multicritres selon une hirarchie de prdicats. Cette mthode a t mise en
uvre dans le SGBD SABRINA.
[IBM78] IBM Corporation, Introduction to IBM Direct Access Storage Devices and
Organization Methods , Student text, Manual Form GC20-1649-10.
Une description des supports de stockage et des mthodes daccs supportes
par IBM en 1978. Ce manuel contient en particulier une description trs didactique de la mthode ISAM et une prsentation de la mthode VSAM.
[Knott71] Knott G.D., Expandable Open Addressing Hash Table Storage and
Retrieval , ACM SIGFIDET Workshop on Data Description, Access and
Control, 1971, ACM Ed., p. 186-206.
Le premier article proposant un hachage dynamique, par extension progressive
de la fonction de hachage en puissances de 2 successives. Larticle sintresse
seulement au cas de tables en mmoires.

[Knuth73] Knuth D.E., The Art of Computer Programming, Addisson-Wesley, 1973.

Le livre bien connu de Knuth. Une partie importante est consacre aux structures de donnes, plus particulirement lanalyse de fonctions de hachage.

[Korth91] Korth H., Silberschatz A., Database System Concepts, Mc Graw-Hill Ed.,
2e dition, 1991.
Un des livres les plus complets sur les bases de donnes. Deux chapitres sont
plus particulirement consacrs aux organisations de fichiers et aux techniques
dindexation.

Fichiers, hachage et indexation 109

[Larson78] Larson P., Dynamic Hashing , Journal BIT, n 18, 1978, p. 184-201.
Un des premiers schmas de hachage dynamique propos, avec clatement de
paquets quand un taux de remplissage est atteint.

[Larson80] Larson P., Linear Hashing with Partial Expansions , 6th Very Large
Data Bases, Montreal, octobre 1980, p. 224-232.
Une variante du hachage linaire ou les avances du pointeur dclatement
sont contrles par le taux de remplissage du fichier.

[Larson82] Larson P., Performance Analysis of Linear Hashing with Partial

Expansions , ACM TODS, vol. 7, n 4, dcembre 1982, p. 566-587.
Cet article rsume la mthode prsente dans [Larson80] et dmontre ses
bonnes performances par une tude analytique.

[Lister84] Lister A.M., Principes fondamentaux des systmes dexploitation, ditions

Eyrolles, 4e dition, 1984.
Cet excellent livre prsente les couches successives constituant un systme
dexploitation. Un chapitre est plus particulirement consacr aux techniques
dallocation mmoire.
[Litwin78] Litwin W., Virtual Hashing: A Dynamically Changing Hashing ,
4th Very Lare Data Bases, Berlin, septembre 1978, p. 517-523.
Sans doute le premier schma de hachage dynamique propos pour des
fichiers. Celui-ci est bas sur une table de bits pour marquer les paquets clats et sur un algorithme rcursif de parcours de cette table pour retrouver la
bonne fonction de hachage.

[Litwin80] Litwin W., Linear Hashing A New Tool for File and Table
Addressing , 6th Very Large Data Bases, Montreal, octobre 1980, p. 224-232.
Larticle introduisant le hachage linaire. Lide est de remplacer la table de bits
complexe du hachage virtuel par un simple pointeur circulant sur les paquets du
fichier. N bits de la fonction de hachage sont utiliss avant le pointeur, N+1
aprs. chaque dbordement, le paquet point par le pointeur est clat.

[Lomet83] Lomet D., A High Performance, Universal Key Associative Access

Method , ACM SIGMOD Intl. Conf., San Jos, 1983.
Une mthode daccs intermdiaire entre hachage et indexation, avec de trs
compltes valuations de performances.
[Lomet89] Lomet D., Salzberg B., Access Methods for Multiversion Data , ACM
SIGMOD Intl. Conf., Portland, 1989.
Cet article discute les techniques darchivage multiversion sur disques optiques.
De tels disques sont inscriptibles une seule fois. Ils ne peuvent tre corrigs, mais
peuvent bien sr tre lus plusieurs fois (Write Once Read Many times WORM).
Ils ncessitent des organisations spcifiques tudies dans cet article.

110 BASES DE DONNES : OBJET ET RELATIONNEL

[Nievergelt84] Nievergelt J., Hinterberger H., Sevcik K., The Grid File: An
Adaptable Symetric Multi-Key File Structure , ACM TODS, vol. 9, n 1, mars
1983.
Cet article introduit le fichier grille (Grid File). Lide est simplement
dtendre le hachage extensible en composant une fonction de hachage multiattribut, partir de diffrentes sous-fonctions portant sur un seul attribut. Une
prise en compte successive des bits de chaque fonction garantie la symtrie.
Diffrentes organisations de rpertoires dadresses sont possibles. Un tableau
dynamique n dimensions est propos.

[ONeil87] ONeil P. Model 204 Architecture and Performance , Springer

Verlag, LCNS n 359, Proc. of 2 nd Intl. Workshop on High Performance
Transactions Systems, p. 40-59, 1987.
Cet article dcrit larchitecture du SGBD Model 204 de Computer Corporation
of America. Il introduit pour la premire fois les index bitmap.

[ONeil97] ONeil P., Quass D., Improved Query Performance with Variant index ,
ACM SIGMOD Intl. Conf., SIGMOD Record V 26, n 2, Tucson, Arizona,
USA, 1997.
Cet article prsente les index bitmap comme une alternative aux index classiques listes dadresses. Il analyse les performances compares de ces types
dindex pour diffrents algorithmes de recherche.

[Samet89] Samet H., The Design and Analysis of Spatial Data Structures, AddisonWesley, 1989.
Ce livre prsente des mthodes daccs et organisations fondes sur les quadtrees pour stocker et retrouver des donnes spatiales, telles que des points, des
lignes, des rgions, des surfaces et des volumes. Les quadtrees sont des structures de donnes hirarchiques bases sur un dcoupage rcursif de lespace.
Par exemple, une image plane en noir et blanc peut tre dcoupe en deux rectangles, chaque rectangle tant son tour dcoup en deux jusqu obtention
de rectangles dune seule couleur. Les dcoupages successifs peuvent tre
reprsents par un arbre dont les feuilles sont 0 si le rectangle correspondant
est blanc, 1 sil est noir. Une telle structure est un quadtree. Elle permet de
constituer un index ou un arbre de placement utilisable pour une recherche efficace de motifs. Le livre de Samet tudie toutes les variantes des quadtrees.
[Scholl81] Scholl M., New File Organization Based on Dynamic Hashing , ACM
TODS, vol. 6, n 1, mars 1981, p. 194-211.
Une tude des performances des mthodes par hachage dynamique.

[Widerhold83] Widerhold G., Database Design, Mc Graw-Hill Ed., New York, 1983.
Ce livre, qui fut lun des premiers sur les bases de donnes, consacre une partie
importante aux disques magntiques, aux fichiers et aux mthodes daccs.

Chapitre IV

BASES DE DONNES RSEAUX

ET HIRARCHIQUES

1. INTRODUCTION
Les systmes tudis dans ce chapitre sont aujourdhui appels systmes lgataires
(legacy systems), car il nous sont lgus par le pass. Ils permettent de modliser des
articles stocks dans des fichiers ainsi que les liens entre ces articles. Ces modles
drivent avant tout dune approche systme au problme des bases de donnes qui
tend voir une base de donnes comme un ensemble de fichiers relis par des pointeurs. Ils privilgient loptimisation des entres-sorties. Cest pourquoi nous les appelons aussi modles daccs. ces modles sont associs des langages de manipulation
de donnes bass sur le parcours de fichiers et de liens entre fichiers, article par
article, appels langages navigationnels. Ces langages sont trs caractristiques des
modles daccs.
Nous prsentons successivement les deux modles les plus populaires, savoir le
modle rseau et le modle hirarchique, avec le langage de manipulation spcifique
associ chacun deux. Le modle rseau propos initialement par le groupe DBTG
du comit CODASYL fut et reste utilis avec diverses variantes possibles par de nombreux systmes tels que IDS.II (Bull), IDMS (Computer-Associate), EDMS (Xerox),

112 BASES DE DONNES : OBJET ET RELATIONNEL

DMS/1100 (Univac), DBMS (Digital), PHOLAS (Philips) et TOTAL (Cincom). Le

modle hirarchique tendu est employ par les systmes anciens que sont IMS (IBM)
et Systems 2000 (MRI-Intel), systmes encore trs rpandus dans lindustrie. Nous
concluons ce chapitre par une prsentation des avantages et inconvnients des
modles daccs.

2. LE MODLE RSEAU
Dans cette section, nous introduisons les principaux concepts du modle rseau pour
dfinir les bases de donnes et le langage associ du Codasyl.

2.1. INTRODUCTION ET NOTATIONS

Le modle rseau a t propos par le groupe DBTG du comit CODASYL
[Codasyl71]. Des rapports plus rcents [Codasyl78, Codasyl81] ont apport des amliorations notables, en particulier une sparation plus nette entre les concepts de
niveau interne et ceux de niveau conceptuel. Malheureusement, ces extensions ne sont
que rarement intgres dans les produits, pour la plupart construits au dbut des
annes 70. Le modle rseau type CODASYL 1971 reste encore aujourdhui utilis
par plusieurs systmes, le plus connu en France tant IDS.II de BULL. Notre prsentation est base sur cette implmentation. Vous trouverez une prsentation plus gnrale du modle dans [Taylor76].
La syntaxe de prsentation des clauses utilises est drive de CODASYL, modifie
et tendue comme suit :
les parenthses carres ([]) indiquent des lments optionnels ;
les pointills suivent un lment qui peut tre rpt plusieurs fois ;
les crochets groupent comme un seul lment une squence dlments ;
la barre verticale entre crochets du type {a | b | c | } signifie que lune des options
a ou b ou c ou doit tre choisie ;
un exposant plus (+) indique que llment qui prcde peut tre rpt n fois (n1),
chaque occurrence tant spare de la prcdente par une virgule ; llment doit
donc au moins apparatre une fois : il est obligatoire ;
un exposant multipli (*) indique que llment qui prcde peut tre rpt n fois
(n0), chaque occurrence tant spare de la prcdente par une virgule ; llment
peut apparatre 0 fois : il est facultatif.

Bases de donnes rseaux et hirarchiques 113

De plus, les mots cls obligatoires sont souligns. Les paramtres des clauses sont
prciss entre crochets triangulaires (<>).

2.2. LA DFINITION DES OBJETS

Les objets modliss dans la base de donnes sont dcrits laide de trois concepts :
latome, le groupe et larticle. Ces concepts permettent de dcrire les donnes constitutives des objets stocks dans des fichiers.
Notion IV.1 : Atome (Data Item)
Plus petite unit de donnes possdant un nom.

La notion datome correspond classiquement au champ dun article de fichier. Un

atome possde un type qui dfinit ses valeurs possibles et les oprations que lon peut
accomplir sur ces valeurs. Un atome est instanci par une valeur atomique dans la
base de donnes. Par exemple, CRU, DEGRE, AGE et NOM peuvent tre des atomes
dune base de donnes de vins et de buveurs. Le type du CRU sera chane de
8 caractres , alors que celui du degr sera rel .
Plusieurs atomes peuvent tre groups conscutivement pour constituer un groupe de
donnes.
Notion IV.2 : Groupe (Data Aggregate)
Collection datomes rangs conscutivement dans la base et portant un nom.

Il existe deux types de groupes : les groupes simples et les groupes rptitifs. Un
groupe simple est une suite datomes, alors quun groupe rptitif est une collection
de donnes qui apparat plusieurs fois conscutivement. Un groupe rptitif peut tre
compos datomes ou mme de groupes rptitifs. Un groupe rptitif compos dun
seul atome est appel vecteur. Par exemple, MILLESIME, compos dANNEE et
QUALITE, peut tre dfini comme un groupe simple apparaissant une seule fois dans
un vin. Au contraire, ENFANT compos de PRENOM, SEXE et AGE pourra apparatre plusieurs fois dans le descriptif dune personne : il sagit dun groupe rptitif.
Une personne pouvant avoir plusieurs prnoms, la donne PRENOM pourra tre un
vecteur apparaissant au plus trois fois. Notons que le modle rseau impose de limiter
le nombre de rptitions possibles dun groupe. Atomes et groupes permettent de
constituer les articles.
Notion IV.3: Article (Record)
Collection datomes et de groupes rangs cte cte dans la base de donnes, constituant lunit
dchange entre la base de donnes et les applications.

114 BASES DE DONNES : OBJET ET RELATIONNEL

Un article peut la limite ne contenir aucune donne. Les occurrences darticles sont
ranges dans des fichiers (AREA). Par exemple, un fichier de vins contiendra des
articles composs datomes NUMERO, CRU et du groupe rptitif MILLESIME,
rpt au plus cinq fois.
Les articles sont dcrits au niveau du type dans le schma au moyen dune clause :
RECORD NAME IS <nom-darticle>.

Par exemple, le type darticle VINS sera introduit par la clause RECORD NAME IS
VINS. Suivront ensuite les descriptions dtailles des donnes de larticle.
Chaque atome ou groupe est dfini par un nom prcd dun niveau ventuel. Les
donnes dun article sont donc dfinies au moyen dun arrangement hirarchique de
groupes dans larticle. Le groupe de niveau 1 est larticle proprement dit. Les donnes
de niveau 2 sont constitues par tous les atomes non agrgs dans un groupe. Les
groupes de niveau 3 sont composs de tous les groupes ntant pas lintrieur dun
autre groupe. Viennent ensuite les groupes internes un groupe (niveau 4), etc. Pour
chaque atome, une spcification de type prcise le domaine de la donne (dcimal,
binaire, caractres). Ainsi, la clause de dfinition dun atome est :
[<niveau>] <nom-datome> TYPE IS <spcification-de-type>

alors que celle de dfinition dun groupe est simplement :

[<niveau>] <nom-de groupe>.

Les types de donnes possibles sont les suivants (version minimale sous IDS.II):
dcimal sign condens ou non (n1 et n2 prcisent respectivement le nombre de
chiffre total et celui aprs la virgule) :
SIGNED [ {PACKED | UNPACKED} ] DECIMAL <n1>, [<n2>]

entier binaire long (signe plus 31 bits) ou court (signe plus 15 bits) :
SIGNED BINARY {15 | 31}

chane de caractres de longueur fixe (n1 caractres) :

CHARACTER <n1>.

Un atome ou un groupe peuvent tre rpts plusieurs fois (cas des vecteurs et des
groupes rptitifs). Cela est prcis par la clause OCCURS du langage de description
de donnes (n1 est un entier quelconque) :
OCCURS <n1> TIMES.

Afin dillustrer ces diffrentes clauses, nous dcrivons (figure IV.1) un type darticle
VINS regroupant les cinq derniers millsimes (caractriss par une anne et un degr)
dun vin dfini par un numro (NV) et un nom de cru (CRU). Nous dcrivons galement un type darticle PRODUCTEURS compos dun numro (NP), un nom
(NOM), un prnom (PRENOM) et un groupe simple ADRESSE, compos de RUE,
CODE et VILLE.

Bases de donnes rseaux et hirarchiques 115

RECORD NAME IS VINS;

02 NV TYPE IS SIGNED PACKED DECIMAL 5;
02 CRU TYPE IS CHARACTER 10;
02 MILLESIME OCCURS 5 TIMES;
03 ANNEE TYPE IS SIGNED UNPACKED DECIMAL 4;
03 DEGRE TYPE IS BINARY 15.
RECORD NAME IS PRODUCTEURS;
02 NP TYPE IS SIGNED PACKED DECIMAL 5;
02 NOM TYPE IS CHARACTER 10;
02 PRENOM TYPE IS CHARACTER 10;
02 ADRESSE
03 RUE TYPE IS CHARACTER 30;
03 CODE TYPE IS SIGNED PACKED DECIMAL 5;
03 VILLE TYPE IS CHARACTER 10;

Figure IV.1 : Description des donnes de deux types darticles

2.3. LA DFINITION DES ASSOCIATIONS

Les possibilits offertes pour modliser les associations entre objets constituent un des
lments importants dun modle de donnes. Historiquement, le modle rseau est
issu dune conceptualisation de fichiers relis par des pointeurs. De ce fait, il offre des
possibilits limites pour reprsenter les liens entre fichiers. Avec les recommandations du CODASYL, il est seulement possible de dfinir des associations entre un
article appel propritaire et n articles membres. Une instance dassociation est le plus
souvent une liste circulaire darticles partant dun article propritaire et parcourant n
articles membres pour revenir au propritaire. Ces associations, qui sont donc purement hirarchiques mais qui, utilises plusieurs niveaux, peuvent permettre de former aussi bien des arbres, des cycles que des rseaux, sont appeles ici liens (en
anglais set).
Notion IV.4 : Lien (Set)
Type dassociation oriente entre articles de type T1 vers articles de type T2 dans laquelle une
occurrence relie un article propritaire de type T1 n articles membres de type T2.

Un type de lien permet donc dassocier un type darticle propritaire un type

darticle membre ; une occurrence de lien permet dassocier une occurrence darticle
propritaire n occurrences darticles membres. Gnralement, les articles membres
seront dun type unique, mais la notion de lien peut thoriquement tre tendue afin
de supporter des membres de diffrents types.

116 BASES DE DONNES : OBJET ET RELATIONNEL

Un lien se reprsente au niveau des types laide dun diagramme de Bachman. Il

sagit dun graphe compos de deux sommets et dun arc. Les sommets, reprsents
par des rectangles, correspondent aux types darticles ; larc reprsente le lien de 1
vers n [Bachman69]. Larc est orient du type propritaire vers le type membre. Il est
valu par le nom du type de lien quil reprsente et chaque sommet par le nom du type
darticle associ.
Par exemple, les types darticles VINS et PRODUCTEURS dcrits ci-dessus seront
naturellement relis par le type de lien RECOLTE, allant de PRODUCTEURS vers
VINS. Une occurrence reliera un producteur tous les vins quil produit. La
figure IV.2 schmatise le diagramme de Bachman correspondant ce lien.

PRODUCTEURS

RCOLTE

VINS

Figure IV.2 : Exemple de diagramme de Bachman

Deux limitations sont importantes : (i) un type darticle ne peut tre la fois propritaire et membre dun mme lien ; (ii) une occurrence darticle ne peut appartenir
plusieurs occurrences du mme lien. Par exemple, deux producteurs ne pourront partager la rcolte dun mme vin, comme le montre la figure IV.3. Par contre, un type
darticle peut tre matre de plusieurs liens. Il peut aussi tre membre de plusieurs
liens. Deux types darticles peuvent aussi tre lis par des types de liens diffrents.
Afin dillustrer les concepts introduits, la figure IV.4 prsente le graphe des types
dune base de donnes vinicole compose des articles :
VINS dcrits ci-dessus,
BUVEURS composs des atomes numro de buveur, nom et prnom,
ABUS dcrivant pour chaque vin la quantit bue par un buveur et la date laquelle
celle-ci a t bue,
PRODUCTEURS dfinissant pour chaque vin le nom et la rgion du producteur,
COMMANDES spcifiant les commandes de vins passes par les buveurs aux producteurs.

Bases de donnes rseaux et hirarchiques 117

P2

P1

V11

V21

V13

V12

Figure IV.3 : Exemple de partage doccurrences de membres interdit

ABUS
CONSOMMATION

DGUSTATION

VINS

BUVEURS

RCOLTE

VENTE

PRODUCTEURS

ACHAT

COMMANDES

Figure IV.4 : Exemple de graphe des types

Les liens considrs sont :

RECOLTER qui associe un producteur aux vins rcolts,
RECEVOIR qui associe un vin aux commandes correspondantes,

118 BASES DE DONNES : OBJET ET RELATIONNEL

PASSER qui associe un buveur ses commandes,

BOIRE qui associe un buveur une quantit de vin bue,
PROVOQUER qui associe un vin toutes les quantits bues par les diffrents
buveurs.
Afin de mieux faire comprendre la notion de lien, il est possible de reprsenter une
base de donnes rseau par un graphe au niveau des occurrences. Dans ce cas, les
articles dune occurrence de lien sont relis par un cycle. Par exemple, la figure IV.5
reprsente des occurrences des articles VINS, ABUS et BUVEURS par des carrs
arrondis, et des occurrences des liens BOIRE et PROVOQUER par des chanes
doccurrences darticles.

Chablis

Volnay

10

20

15

Paul

10

Pierre

11

Jacques

Figure IV.5 : Exemple de graphe des occurrences

En CODASYL, la clause de dfinition dun lien utilise au niveau de la description

dun schma, qui se situe bien videmment au niveau des types, est structure comme
suit :
SET NAME IS <nom-de-lien>
OWNER IS <nom-darticle>
[MEMBER IS <nom-darticle>] *

Nous verrons ci-dessous les dtails des sous-clauses OWNER et MEMBER. Plusieurs
types de membres peuvent tre spcifis par rptition de la clause MEMBER.
CODASYL autorise la dfinition de liens singuliers avec une seule occurrence. Pour
cela, il suffit dutiliser la dfinition de propritaire :
OWNER IS SYSTEM

Bases de donnes rseaux et hirarchiques 119

Tous les articles membres sont alors chans entre eux dans une seule occurrence de
lien (une seule liste dont la tte de liste est gre par le systme). Cela permet de
rechercher un article parmi les membres comme dans une occurrence de lien normale,
et aussi de chaner des articles singuliers.

2.4. LORDONNANCEMENT DES ARTICLES

DANS LES LIENS
Les articles dans les occurrences de lien sont ordonns. Lordre est maintenu lors des
insertions et les articles sont prsents dans lordre dinsertion aux programmes
dapplication. Lors de linsertion dun article dont le type est membre dun lien, il faut
tout dabord choisir loccurrence de lien dans laquelle larticle doit tre plac. Les
mthodes possibles pour ce choix sont prsentes ci-dessous. Ensuite, larticle doit
tre insr dans la suite ordonne des articles composants les membres de loccurrence de lien. Les choix possibles de la position de larticle sont les suivants :
en dbut (FIRST) ou en fin (LAST) de la suite des membres,
juste avant (PRIOR) ou juste aprs (NEXT) le dernier article de la suite des
membres auquel a accd le programme effectuant linsertion,
par ordre de tri (SORTED) croissant ou dcroissant dune donne des articles
membres ; dans ce cas, la donne doit tre dfinie comme une cl (KEY) dans la
clause membre ; les cas de doubles doivent tre prvus ; de mme, si le lien comporte plusieurs types darticles, lordre des types doit tre prcis.
La figure IV.6 reprsente ces diverses possibilits pour linsertion dans une occurrence du lien BOIRE.
Ces possibilits doivent tre dfinies au niveau du schma laide de la clause
ORDER. Celle-ci est place dans la dfinition du type de lien (clause SET) juste aprs
la dfinition du type du propritaire (sous-clause OWNER). Sa syntaxe simplifie est
la suivante :
ORDER IS [ PERMANENT ] INSERTION IS
{FIRST | LAST | PRIOR | NEXT | SORTED <spcification de tri>}.

Une spcification de tri est dfinie comme suit :

<spcification de tri> ::=
[ RECORD-TYPE SEQUENCE IS <nom-darticle>+ ]
BY DEFINED KEYS
[ DUPLICATES ARE {FIRST | LAST | NOT ALLOWED} ]

Loption PERMANENT (obligatoire pour les liens tris) prcise quun programme
dapplication ne peut modifier lordre dun lien. Ainsi, tout changement effectu restera
local au programme et ne perturbera pas lordre des articles dj enregistrs dans la base.

120 BASES DE DONNES : OBJET ET RELATIONNEL

25

Article insrer

Last

First
Volnay

30

Prior

Sorted
10

20

Article courant
du programme

Next

Figure IV.6 : Possibilits dinsertion dans une occurrence de lien

Si un ordre de cl est prcis lintrieur de chaque type darticle (option SORTED),

il faut tout dabord prciser lordre entre les types darticles dans le cas o le lien est
htrogne (plusieurs types darticles membres). Cest lobjet de la clause RECORD
TYPE SEQUENCE IS. Ensuite, la clause DUPLICATES permet de spcifier si les
doubles sont possibles pour les cls dfinies au niveau de la clause MEMBER (clause
KEY ci-dessous) et, si oui, comment ils sont traits. Loption FIRST place les doubles
avant ceux dj existants ; loption LAST les place aprs.
Pour chacun des types darticles membres, si loption SORTED BY DEFINED KEYS
est retenue, il faut prciser la cl de tri ; celle-ci est spcifie par la clause optionnelle
KEY. La cl peut tre utilise pour un tri ascendant ou descendant. Elle est dfinie par
la clause suivante :
KEY IS {ASCENDING | DESCENDING} <nom-de-donne>

Bases de donnes rseaux et hirarchiques 121

2.5. LA SLECTION DOCCURRENCE

DUN TYPE DE LIEN
Il existe autant doccurrences dun lien que darticles propritaires. Lors dune insertion ou dune recherche, il y a donc ncessit de slectionner loccurrence choisie.
Cela est effectu par parcours dun chemin dans le graphe des occurrences de liens
depuis un article point dentre, jusqu larticle propritaire de loccurrence de lien
cherche.
La slection peut tre manuelle ou automatique. Si elle est manuelle, elle est effectue
par le programme qui peut par exemple parcourir les liens de proche en proche pour
trouver le bon propritaire. Si elle est automatique, le mode de slection doit tre prcis par la clause SET SELECTION.
Nous dcrivons maintenant la clause de slection dun chemin pour atteindre le propritaire dune occurrence de lien, utilise notamment afin dinsrer automatiquement
un article membre dans une occurrence de lien. Cette clause est une des plus complexe du langage de description CODASYL. Elle aboutit au lien dont une occurrence
doit tre slectionne (nom-de-lien1) en partant dun point dentre (propritaire du
nom-de-lien2). La descente seffectue de lien en lien en prcisant comment doit tre
slectionn le propritaire chaque niveau. La syntaxe simplifie de la clause de
slection est la suivante :
SET SELECTION [FOR <nom-de-lien1>] IS
THRU <nom-de-lien2> OWNER IDENTIFIED BY
{ APPLICATION
| DATA-BASE-KEY [EQUAL TO <nom-de-paramtre1>]
| CALC KEY [EQUAL TO <nom-de-paramtre2>]}
[ THEN THRU<nom-de-lien3>WHERE OWNER IDENTIFIED BY
{<nom-de-donne3> [EQUAL TO <nom-de-paramtre3>]}+ ]

La premire partie de la clause (THRU) permet de spcifier le mode de slection du

point dentre. Deux approches sont possibles :
par application, ce qui signifie que larticle propritaire a d tre, pralablement la
recherche ou linsertion, repr par le programme dapplication, comme nous le
verrons lors de ltude du langage de manipulation ;
par cl (DATA-BASE-KEY ou CALC KEY) fournie par le programme en paramtre ; le premier type de cl est une adresse base de donnes darticle (adresse
relative dans le fichier, gre par le systme) et le second une cl de hachage
(CALC KEY) servant au placement de larticle dans le fichier par application dune
fonction de hachage, comme nous le verrons ci-dessous.
La deuxime partie (THEN THRU) est optionnelle dans le cas o lon dsire parcourir un chemin de longueur suprieure un dans le graphe des liens. Elle permet, de
manire rcursive lorsquelle est rpte, de slectionner une occurrence de lien par

122 BASES DE DONNES : OBJET ET RELATIONNEL

recherche du propritaire dans les membres de loccurrence prcdemment slectionne. Cette recherche seffectue par balayage de loccurrence de lien de niveau suprieur jusquau premier article ayant pour valeur de la donne nom-de-donne3 la
valeur contenue dans nom-de-paramtre3 ; cette donne (nom-de-donne3) doit tre
discriminante dans loccurrence de lien (pas de doubles autoriss). Ainsi, il est possible de faire choisir loccurrence de lien dans lequel un article est automatiquement
insr par le SGBD, partir dun point dentre pralablement slectionn et de paramtres fournis par le programme.

2.6. LES OPTIONS DINSERTION DANS UN LIEN

Lors de linsertion dun article dans la base, celui-ci peut, pour chacun des liens dont
son type darticle est dclar membre :
tre insr automatiquement dans la bonne occurrence du lien slectionn par le
systme en accord avec la SET SELECTION (option INSERTION IS AUTOMATIC) ;
ne pas tre insr automatiquement par le systme; dans ce cas (option INSERTION
IS MANUAL), le programme devra, sil le dsire, faire linsertion par une commande spciale du langage de manipulation que nous tudierons plus loin..
De plus, une contrainte dintgrit spcifique peut tre prcise : lassociation entre
deux types darticles relis par un lien est dclare obligatoire (option MANDATORY) ou facultative (option OPTIONAL). Dans le premier cas, tout article du
type membre dun lien sera forcment membre dune occurrence de ce lien, alors quil
ne le sera pas forcment dans le second. Loption MANDATORY correspond un lien
fort (qui doit forcment exister) alors que loption OPTIONAL correspond un lien
faible (qui peut exister).
Ces options dinsertion sont prcises pour chaque type de membre, aprs la clause
MEMBER, par la clause :
INSERTION IS {AUTOMATIC | MANUAL}
RETENTION IS {MANDATORY | OPTIONAL}

2.7. LE PLACEMENT DES ARTICLES

Une base de donnes CODASYL est place dans un ensemble de fichiers appel
AREA (ou REALM dans la nouvelle version). Ces fichiers sont soit des fichiers relatifs (adressage par numro de page et par numro doctet dans la page), soit des
fichiers alatoires (adresse relative calcule par une fonction de hachage). Chaque
article est repr dans la base par une cl base de donnes (database key) qui lui est

Bases de donnes rseaux et hirarchiques 123

affecte sa cration et permet de lidentifier jusqu sa disparition. Un SGBD

CODASYL gre donc lidentit dobjets par des cls base de donnes.
Notion IV.5 : Cl Base de Donnes (Database key)
Adresse invariante associe un article lors de sa cration et permettant de lidentifier sans ambigut.

Bien que le comit DBTG CODASYL nait pas spcifi le format des cls base de donnes, la plupart des systmes rseaux attribuent une place fixe aux articles, si bien quune
cl base de donnes peut tre un numro de fichier, suivi dun numro de page et dun
dplacement dans la page permettant de retrouver len-tte de larticle. Certains systmes
grent en fin de page un index des en-ttes darticles contenus dans la page, si bien que le
dplacement dans la page est simplement le numro de len-tte en fin de page.
Le placement dun article consiste calculer son adresse dans la base, ainsi que sa cl
base de donnes qui en dcoule en gnral directement. Le mode de placement est
dfini dans le schma pour chaque type darticle selon plusieurs procds possibles.
Notion IV.6 : Placement CODASYL (CODASYL location mode)
Mthode de calcul de ladresse dun article et dattribution de la cl base de donnes lors de la premire insertion.

De manire surprenante, la cl base de donnes peut tre fournie directement par lutilisateur comme un paramtre du programme. Ce mode, appel placement direct (mot
cl DIRECT), est en gnral rserv aux programmeurs systme. Le mode le plus
facilement utilisable est le placement alatoire classique : une cl, pas forcment discriminante, est prcise et le systme calcule ladresse de larticle laide dune procdure de hachage. Ce mode de placement, appel placement calcul, est spcifi par
les mots cls CALC USING.
Un mode plus complexe, mais permettant en gnral de bonnes optimisations, est le
mode par lien, spcifi par le mot cl VIA. Il possde deux variantes selon que
larticle est plac dans le mme fichier que son propritaire via le lien considr, ou
dans un fichier diffrent. Dans le premier cas, larticle est plac proximit du propritaire, alors que dans le second il est plac dans un autre fichier que celui du propritaire par homothtie.
Le placement proximit consiste placer larticle aussi prs que possible du propritaire du lien retenu pour le placement, dans la mme page ou dans la premire page
voisine ayant de la place disponible.
Le placement par homothtie consiste calculer ladresse de la page dans laquelle on
place larticle (dnote Adresse Article AA) partir de ladresse de la page du propritaire (dnote Adresse Propritaire AP) par la formule AA = AP * TA/TP, o TA

124 BASES DE DONNES : OBJET ET RELATIONNEL

dsigne la taille du fichier contenant larticle et TP la taille du fichier contenant le

propritaire. Lavantage de cette mthode est quen gnral tous les articles ayant le
mme propritaire via le lien considr sont placs dans la mme page (ou des pages
voisines). Ainsi la mthode par homothtie rduit le temps de parcours des membres
dune occurrence de lien sans accrotre le temps de parcours du type darticle
membre, alors que la mthode par proximit rduit le temps de parcours des occurrences de lien mais en gnral accrot celui du type darticle membre.
La figure IV.7 illustre les diffrents types de placements couramment utiliss : placement calcul (CALC), proximit et par homothtie. Le choix entre ces diffrents
modes est laiss ladministrateur systme, qui doit chercher optimiser les performances des accs les plus frquents aux donnes.

F-PRODUCTEURS
PRODUCTEURS

CALC(nprod)

RCOLTE
via
rcolte

CALC
(nbuv)

F-BUVEURS

VINS

BUVEURS
DGUSTATION
CONSOMMATION

VENTE

ABUS

ACHAT

via dgustation

COMMANDES
via achat
F-COMMANDES

Figure IV.7 : Diffrents types de placements possibles

Les diverses possibilits de placement illustres ci-dessus sont dfinies au niveau du

schma par la clause LOCATION MODE. Il existe en fait quatre modes possibles, le

Bases de donnes rseaux et hirarchiques 125

mode SYSTEM spcifiant quun algorithme dfinit par le systme est choisi. On
retrouve les modes dcrits ci-dessus, DIRECT par adresse calcule par le programme,
CALC par cl et VIA par lien. Le fichier choisi peut tre celui du propritaire ou un
autre dans le cas VIA, ce qui diffrencie le placement proximit et le placement par
homothtie. Dans tous les cas, le fichier choisi est prcis par la clause WITHIN. La
syntaxe de la clause de placement est la suivante :
LOCATION MODE IS
{
SYSTEM
|
DIRECT <NOM-DE-PARAMETRE>
|
CALC USING <NOM-DE-DONNE>
[ DUPLICATES ARE [NOT] ALLOWED ]
|
VIA <NOM-DE-LIEN> SET}
WITHIN {<NOM-DE-FICHIER> | AREA OF OWNER}

2.8. EXEMPLE DE SCHMA

Afin dillustrer le langage de dfinition de schma CODASYL, la figure IV.8 propose
un schma possible pour la base de donnes dont le graphe des types a t prsent
figure IV.4. La base a t place dans trois fichiers (F-BUVEURS, F-PRODUCTEURS et F-COMMANDES). Les articles ABUS et VINS sont placs proximit
des propritaires, respectivement BUVEURS et PRODUCTEURS, eux-mmes placs
par hachage. Les articles COMMANDES sont placs dans le fichier F-COMMANDES par homothtie avec le fichier F-BUVEURS. Des choix sont faits pour les
ordres dinsertion, les contraintes de rtention et les modes de slection des liens. Ces
choix devront tre respects lors de lcriture des programmes de manipulation.
SCHEMA NAME IS VINICOLE ;
AREA NAME IS F-BUVEURS ;
AREA NAME IS F-PRODUCTEURS ;
AREA NAME IS F-COMMANDES ;
RECORD NAME IS BUVEURS ;
LOCATION MODE IS CALC USING NB DUPLICATES
NOT ALLOWED WITHIN F-BUVEURS ;
02 NB TYPE IS SIGNED PACKED DECIMAL 5 ;
02 NOM TYPE IS CHARACTER 10 ;
02 PRENOM TYPE IS CHARACTER 10 ;
RECORD NAME IS ABUS ;
LOCATION MODE IS VIA DEGUSTATION
WITHIN AREA OF OWNER ;
02 QUANTITE TYPE IS SIGNED BINARY 15 ;
RECORD NAME IS PRODUCTEURS ;
LOCATION MODE IS CALC USING NOM DUPLICATES
ALLOWED WITHIN F-PRODUCTEURS ;

126 MATRISER LES BASES DE DONNES

02 NOM TYPE IS CHARACTER 10 ;

02 REGION TYPE IS CHARACTER 8 ;
RECORD NAME IS VINS ;
LOCATION MODE IS VIA RECOLTE WITHIN AREA OF OWNER ;
02 NV TYPE IS SIGNED PACKED DECIMAL 5 ;
02 CRU TYPE IS CHARACTER 10 ;
02 MILLESIME OCCURS 5 TIMES ;
03 ANNEE TYPE IS SIGNED UNPACKED DECIMAL 4 ;
03 DEGRE TYPE IS SIGNED BINARY 15 ;
RECORD NAME IS COMMANDES ;
LOCATION MODE IS VIA ACHAT WITHIN F-COMMANDES ;
02 DATE TYPE IS CHARACTER 8 ;
02 QUANTITE TYPE IS SIGNED BINARY 15 ;
SET NAME IS DEGUSTATION ;
OWNER IS BUVEURS ;
ORDER IS PERMANENT INSERTION IS LAST ;
MEMBER IS ABUS ;
INSERTION IS AUTOMATIC RETENTION IS MANDATORY ;
SET SELECTION FOR DEGUSTATION IS
THRU DEGUSTATION OWNER IDENTIFIED BY CALC KEY ;
SET NAME IS CONSOMMATION ;
OWNER IS VINS ;
ORDER IS PERMANENT INSERTION IS NEXT ;
MEMBER IS ABUS ;
INSERTION IS AUTOMATIC RETENTION IS MANDATORY ;
SET SELECTION FOR CONSOMMATION IS
THRU CONSOMMATION OWNER IDENTIFIED
BY APPLICATIONS ;
SET NAME IS RECOLTE ;
OWNER IS PRODUCTEURS ;
ORDER IS PERMANENT INSERTION IS SORTED
BY DEFINED KEYS DUPLICATES ARE FIRST ;
MEMBER IS VINS ;
INSERTION IS MANUAL RETENTION IS OPTIONAL ;
KEY IS ASCENDING CRU ;
SET SELECTION IS
THRU RECOLTE OWNER IDENTIFIED BY CALC KEY ;
SET NAME IS VENTE ;
OWNER IS VINS ;
ORDER IS PERMANENT INSERTION IS SORTED
BY DEFINED KEYS DUPLICATES ARE NOT ALLOWED ;
MEMBER IS COMMANDES ;
INSERTION IS AUTOMATIC RETENTION IS MANDATORY ;
KEY IS DESCENDING DATE DUPLICATES NOT ALLOWED ;
SET SELECTION IS
THRU RECOLTE OWNER IDENTIFIED BY CALC KEY
THEN THRU VENTE WHERE OWNER IDENTIFIED BY NV ;
SET NAME IS ACHAT ;
OWNER IS BUVEURS ;

Bases de donnes rseaux et hirarchiques 127

ORDER IS PERMANENT INSERTION IS LAST ;

MEMBER IS COMMANDES ;
INSERTION IS AUTOMATIC RETENTION IS MANDATORY ;
SET SELECTION IS
THRU ACHAT OWNER IDENTIFIED BY APPLICATION ;
END-SCHEMA.

Figure IV.8 : Exemple de schma CODASYL

3. LE LANGAGE DE MANIPULATION
COBOL-CODASYL
Le langage de manipulation de donnes du CODASYL est fortement li COBOL,
bien que gnralis et utilisable depuis dautres langages de 3e gnration tel Fortran.

3.1. SOUS-SCHMA COBOL

Un schma externe en CODASYL est appel sous-schma. La notion de sous-schma
est en gnral plus restrictive que celle de schma externe. Il sagit dun sousensemble exact du schma sans restructuration possible. Au niveau dun sous-schma,
ladministrateur ne peut quomettre des types darticles, des fichiers (area), des liens
et des donnes dclars dans le schma. Certains systmes permettent cependant de
dfinir des donnes virtuelles, non stockes dans la base, mais calcules par le SGBD
partir de donnes de la base.
Notion IV.7 : Sous-schma (Sub-schema)
Sous-ensemble du schma vu par un programme dapplication, spcifiant la vision externe de la
base par le programme.

Outre la possibilit de ne dfinir quune partie des donnes, des articles, des liens et
des fichiers, dautres variations importantes peuvent exister entre le schma et un
sous-schma. En particulier :
lordre des atomes dans un article peut tre chang,
les caractristiques (types) dun atome peuvent tre changes,
les clauses SET SELECTION peuvent tre redfinies,
les noms de types darticles, dattributs et de liens peuvent tre changs.

128 BASES DE DONNES : OBJET ET RELATIONNEL

Un sous-schma COBOL se compose en principe de trois divisions : une division de

titre (title division) qui nomme le sous-schma et le relie au schma, une division de
transformation (mapping division) qui permet de dfinir les synonymes et une division des structures (structure division) o sont dfinis les fichiers (appels REALM en
COBOL car le mot AREA est utilis dautres fins), les articles et les liens vus par le
programme. Afin dillustrer le concept de sous-schma, la figure IV.9 propose un
sous-schma de la base vinicole que pourrait dfinir un administrateur pour des programmes sintressant seulement aux articles buveurs, commandes et abus ( lexception du numro de buveur).
TITLE DIVISION
SS CLIENT WITHIN SCHEMA VINICOLE
MAPPING DIVISION
ALIAS SECTION
AD SET BOIT IS DEGUSTATION
AD SET ACHETE IS ACHAT
STRUCTURE DIVISION
REALM SECTION
RD F-BUVEURS
RD F-COMMANDES
RECORD SECTION
01 BUVEURS
02 NV PICTURE IS 999
02 NOM PICTURE IS X(10)
02 PRENOM PICTURE IS X(10)
01 ABUS
02 QUANTITE PICTURE IS 999
01 COMMANDES
02 QUANTITE PICTURE IS 999
02 DATE PICTURE IS X(8)
SET SECTION
SD BOIT
SD ACHETE

Figure IV.9 : Exemple de sous-schma COBOL

3.2. LA NAVIGATION CODASYL

Une fois quun schma et des sous-schmas ont t dfinis, des programmes dapplications peuvent tre crits. Ceux-ci invoquent le systme de gestion de bases de donnes laide des verbes du langage de manipulation qui sont inclus dans un programme COBOL, ou dans un autre langage (C, FORTRAN, PL1 sont en particulier
supports). Les verbes de manipulation peuvent tre classs en quatre types :
la recherche darticles (FIND),

Bases de donnes rseaux et hirarchiques 129

les changes darticles (GET, STORE),

la mise jour (ERASE, CONNECT, DISCONNECT, MODIFY),
le contrle des fichiers (READY, FINISH).
Les changes darticles entre le SGBD et un programme dapplication seffectuent par
une zone de travail tampon appele USER WORKING AREA, dans laquelle les
articles fournis par le SGBD sont chargs (GET), et dans laquelle ceux fournis par le
programme sont placs avant dtre rangs dans la base (STORE). Chaque atome ou
article dcrit dans le sous-schma a une place fixe dans la zone de travail, affecte
lors du chargement du programme. Chaque objet peut tre rfrenc par le programme
en utilisant son nom dfini dans le sous-schma.
La recherche darticles ne provoque pas dchange de donnes entre le programme et
le SGBD. Seuls des pointeurs associs au programme et des collections darticles,
appels curseurs, sont dplacs par les ordres de recherche (FIND).
Notion IV.8 : Curseur (Currency)
Pointeur courant contenant la cl base de donnes du dernier article manipul dune collection
darticles, et permettant au programme de se dplacer dans la base.

Il existe plusieurs curseurs associs un programme en excution, chacun permettant

de mmoriser ladresse du dernier article manipul dans une collection darticles (en
gnral, un type) :
un curseur indique larticle courant du programme, cest--dire en principe le dernier article lu, crit ou simplement cherch par le programme ;
un curseur indique larticle courant de chaque type darticle rfrenc ;
un curseur indique larticle courant de chaque type de lien rfrenc ;
un curseur indique enfin larticle courant de chaque type de fichier rfrenc.
Le nombre de curseurs associs un programme se comptabilise en fonction des types du
sous-schma. Il est obtenu par la formule : (1 + Nombre de types darticles + Nombre de
type de liens + Nombres de fichiers). Les curseurs sont dplacs grce aux divers types de
FIND que nous allons tudier. Seul larticle point par le curseur du programme peut tre
lu par le programme en zone de travail. Ainsi, un programme se dplace dans la base en
dplaant son curseur : on dit quil navigue [Bachman73].

3.3. LA RECHERCHE DARTICLES

La recherche darticles consiste donc dplacer les curseurs dans la base. Elle seffectue laide de linstruction FIND. Lexcution dune telle instruction dplace toujours
le curseur du programme, mais il est possible dempcher slectivement le dplace-

130 BASES DE DONNES : OBJET ET RELATIONNEL

ment des autres curseurs. Sil na pas t spcifi quun curseur ne doit tre dplac,
celui-ci est repositionn ds quun article de la collection laquelle il est associ (type
darticles, liens, fichiers) est manipul (lu, crit ou travers).
Le format gnral de linstruction de recherche est :
FIND <EXPRESSION-DE-SLECTION> RETAINING CURRENCY FOR
{
MULTIPLE
|
REALM
|
RECORD
|
SETS
|
<NOM DE LIEN>+}

Lexpression de slection spcifie le critre de recherche. La rtention du dplacement

de tous les curseurs, lexception de celui du programme, seffectue par loption
RETAINING CURRENCY FOR MULTIPLE. Les autres choix de rtention de curseurs peuvent tre combins. Ci-dessous, nous examinons les diffrents types de
FIND rsultant des diverses expressions de slections possibles.

3.3.1. La recherche sur cl

Comme lindique le paragraphe IV.2, un article possde toujours une cl base de donnes (DATA BASE KEY) et peut possder une cl de hachage (avec ou sans double)
sil a t plac en mode calcul. On obtient ainsi trois possibilits de recherche sur
cls dont voici les syntaxes :
Recherche connaissant la cl base de donnes (adresse invariante)
FIND <nom-darticle> DBKEY IS <nom-de-paramtre>

Recherche connaissant la cl calcule unique (cl de hachage)

FIND ANY <nom-darticle>

Dans ce cas, la valeur de la cl de recherche doit pralablement tre charge par le

programme en zone de travail.
Recherche connaissant la cl calcule avec doubles
FIND DUPLICATE <nom-darticle>

Plusieurs FIND DUPLICATE permettront de retrouver les doubles successivement.

3.3.2. La recherche dans un fichier

Cette recherche est avant tout squentielle ou en accs direct. Il est ainsi possible de
slectionner le premier article (option FIRST), le dernier (option LAST), larticle suivant (option NEXT) ou prcdent (option PRIOR) larticle courant, ainsi que le
ie article dun fichier. Le numro de larticle slectionner peut tre spcifi par un
paramtre du programme. Le format de linstruction de recherche dans un fichier est :

Bases de donnes rseaux et hirarchiques 131

FIND
{FIRST | LAST | NEXT | PRIOR | <i> | <paramtre>}
<nom-darticle> WITHIN <nom-de-fichier>

3.3.3. La recherche dans une occurrence de lien

De mme que dans un fichier, il est possible de slectionner le premier article, le dernier, larticle suivant ou prcdent larticle courant et le ie article de loccurrence courante dun lien. Le format de linstruction est identique celui de la recherche en
fichier :
FIND
{FIRST | LAST | NEXT | PRIOR | <i> | <paramtre>}
<nom-darticle> WITHIN <nom-de-lien>

Il est galement possible de rechercher un article partir dune valeur de donne dans
loccurrence courante dun lien. La donne dont la valeur est utilise pour ce type de
recherche associative dans une occurrence de lien est cite en argument du mot cl
USING. Cette valeur doit bien sr tre pralablement charge en zone de travail.
Selon que lon recherche la premire (ou lunique) occurrence darticle ou la suivante,
on emploie :
FIND <nom-darticle> WITHIN <nom-de-lien>
USING <nom-de-donne>+
FIND DULICATE WITHIN <nom-de-lien>
USING <nom-de-donne>+

Un lien peut tre parcouru depuis un article membre vers le propritaire, donc en sens
inverse de larc qui le reprsente dans le diagramme de Bachman. Ainsi, il est possible de slectionner le propritaire de loccurrence courante dun lien par la commande :
FIND OWNER WITHIN <nom-de-lien>

Une telle instruction permet en gnral de passer depuis un membre dun lien un
propritaire, donc de remonter les arcs du graphe des types dune base de donnes
CODASYL.
Il est aussi possible de tester des conditions concernant lappartenance de larticle
courant dun programme un lien. La condition est vraie si larticle courant du programme est propritaire (option OWNER), membre (option MEMBER) ou plus gnralement participant (option TENANT) lintrieur dune occurrence du lien cit. La
forme de la commande est :
IF [NOT] <nom-de-lien> {OWNER | MEMBER | TENANT}
EXECUTE <instructions>

Il est enfin possible de tester si une occurrence de lien slectionne par un article propritaire ne possde aucun membre en utilisant la commande :
IF <nom-de-lien> IS [NOT] EMPTY EXECUTE <instructions>

132 BASES DE DONNES : OBJET ET RELATIONNEL

3.3.4. Le positionnement du curseur de programme

chaque recherche, le curseur du programme est positionn. Par suite, les FIND provoquent des changements successifs de la position du curseur du programme : on dit
que le programme navigue dans la base CODASYL [Bachman73]. Aprs des navigations successives, il peut tre utile de revenir se positionner sur larticle courant dun
type darticle dun fichier ou dun lien. Cela peut tre fait laide de la commande :
FIND CURRENT [<nom-darticle>]
[ WITHIN {<nom-de-fichier> | <nom-de-lien>} ]

Cette commande a donc pour effet de forcer le curseur du programme celui du nomdarticle spcifi, ou celui du fichier ou du lien spcifi, ventuellement selon un
type darticle prcis.

3.4. LES CHANGES DARTICLES

Larticle point par le curseur dun programme peut tre amen en zone de travail du
programme pour traitement. Seules certaines donnes de cet article peuvent tre lues.
Cette opration seffectue laide de la commande :
GET {[<type-darticle>] | {<nom-de-donne>} *}

Les arguments peuvent tre soit le type darticle qui doit alors tre le mme que celui
de larticle point par le curseur du programme, soit une liste des donnes du type de
larticle courant que lon souhaite amener en zone de travail. Si aucun nom de donne
nest prcis, toutes les donnes sont lues.
Le rangement dun article dans la base seffectue, aprs chargement de larticle en
zone de travail, par excution de la commande STORE. En principe, tous les curseurs
sont modifis par la commande STORE : tous pointent aprs excution sur le nouvel
article stock. Il est possible de retenir le dplacement de certains curseurs en utilisant
loption RETAINING, de manire identique FIND. Le format de la commande
STORE est le suivant :
STORE <nom darticle> RETAINING CURRENCY FOR
{
MULTIPLE
|
REALM
|
RECORD
|
SETS
|
<nom de lien>+}

3.5. LES MISES JOUR DARTICLES

Elles incluent la fois les suppressions et les modifications de donnes. Alors que la
suppression est simple, la modification soulve des problmes au niveau des liens qui
peuvent ou non tre modifis.

Bases de donnes rseaux et hirarchiques 133

3.5.1. Suppression darticles

Avant de supprimer un article, il faut bien sr le rechercher. Il devient alors le courant
du programme. La suppression de larticle courant dun programme seffectue par la
commande :
ERASE [ALL] [<nom-darticle>].

Si cet article est propritaire doccurrences de lien, tous ses descendants sont galement
supprims seulement dans le cas o le mot cl ALL est prcis. Une suppression est ainsi
cascade tous les articles dpendants, et cela de proche en proche. Le nom darticle permet optionnellement au systme de vrifier le type de larticle courant dtruire.

3.5.2. Modification darticles

La modification de larticle courant dun programme seffectue en principe aprs avoir
retrouv larticle modifier comme le courant du programme. Les donnes modifier
doivent tre places en zone article dans le programme (zone de travail). Seules certaines donnes sont modifies, en principe celles spcifies par la commande ou toutes
celles dont la valeur en zone article est diffrente de celle dans la base. Les liens spcifis sont changs en accord avec les clauses de slection de liens (SET SELECTION)
prcises dans le schma. Le format de la commande est le suivant :
MODIFY {[<nom-darticle>] | [<nom-de-donne>]}
[ INCLUDING {ALL | ONLY <nom-de-lien>+} MEMBERSHIP ]

Les donnes modifier peuvent tre prcises ou non ; dans le dernier cas, le systme
modifie toutes celles qui sont changes dans larticle en zone de travail. On doit aussi
prciser les modifications apporter aux liens dont larticle est membre ; plusieurs
options sont possibles. Il est possible de demander la rvaluation, en accord avec la
clause du schma SET SELECTION de toutes (INCLUDING ALL) ou de certaines
(INCLUDING liste de noms de liens) appartenances des occurrences de liens. Il est
aussi possible de ne modifier aucune donne, mais seulement les appartenances aux
liens (option MODIFY ONLY).

3.5.3. Insertion et suppression dans une occurrence de lien

Linsertion dun article dans une occurrence de lien peut tre effectue par le SGBD ou
par le programme, selon le choix lors de la dfinition du schma. Deux commandes permettent dinsrer et denlever larticle courant dun programme dune occurrence de
lien : CONNECT et DISCONNECT. Leur utilisation ncessite que le mode dinsertion
dans le lien ait t dfini comme manuel (MANUAL) ou alors que lappartenance au
lien soit optionnelle (OPTIONAL). La syntaxe de ces commandes est la suivante :
CONNNECT [<nom-darticle>] TO <nom-de-lien>.
DISCONNECT [<nom-darticle>] FROM <nom-de-lien>.

Le nom darticle permet de vrifier le type de larticle courant.

134 BASES DE DONNES : OBJET ET RELATIONNEL

3.6. LE CONTRLE DES FICHIERS

Avant de travailler sur un fichier, un programme doit louvrir en spcifiant le mode de
partage souhait. Le fichier peut tre ouvert en mode exclusif (seul lutilisateur peut
alors accder) ou en mode protg (les accs sont alors contrls au niveau des
articles), fin de recherche (RETRIEVAL) ou de mise jour (UPDATE). Cette ouverture seffectue laide de la commande :
READY {<nom-de-fichier> [USAGE-MODE IS
{EXCLUSIVE | PROTECTED} {RETRIEVAL | UPDATE}]} +

En fin de travail sur un fichier, il est ncessaire de le fermer laide de la commande :

FINISH {<nom-de-fichier>} +

3.7. QUELQUES EXEMPLES DE TRANSACTION

Voici diffrents types daccs raliss par des transactions simples. Ces transactions
utilisent le sous-schma CLIENT de la figure VI.9. La signification des transactions
apparat en lgende de la figure correspondante.
READY F-BUVEURS USAGE-MODE PROTECTED
RETRIEVAL
MOVE 100 TO NB IN BUVEURS.
FIND ANY BUVEURS.
PRINT NOM, PRENOM IN BUVEURS.
FINISH F_BUVEURS.

Figure IV.10 : Accs sur cl calcule unique

READY F-BUVEURS, F-COMMANDES.
FIND FIRST BUVEURS WITHIN F-BUVEURS.
PERFORM UNTIL FIN-DE-FICHIER
GET BUVEURS.
PRINT NOM, PRENOM IN BUVEURS.
FIND FIRST COMMANDE WITHIN ACHETE.
PERFORM UNTIL FIN-DOCCURENCE-DENSEMBLE
GET COMMANDES.
PRINT QUANTITE, DATE IN COMMANDE.
FIND NEXT COMMANDE WITHIN ACHETE.
END-PERFORM.
FIND NEXT BUVEURS WITHIN F-BUVEURS.
END-PERFORM.
FINISH.

Figure IV.11 : Accs squentiel un fichier et des occurrences de lien

Bases de donnes rseaux et hirarchiques 135

READY F-BUVEURS, F-COMMANDES.

MOVE 100 TO NB IN BUVEURS.
FIND ANY BUVEURS.
MOVE 10-02-81 TO DATE IN COMMANDES.
FIND COMMANDE WITHIN ACHETE USING DATE.
PERFORM UNTIL PLUS-DE-COMMANDE
GET COMMANDE.
PRINT QUANTITE, DATE IN COMMANDE.
FIND DUPLICATE WITHIN ACHETE USING DATE.
END-PERFORM.
FINISH.

Figure IV.12 : Accs associatif dans une occurrence de lien

READY F-BUVEURS, F-COMMANDES.
FIND FIRST ABUS WITHIN F-BUVEURS.
PERFORM UNTIL FIN-DE-FICHIER
GET ABUS.
IF QUANTITE IN ABUS > 100
FIND OWNER WITHIN BOIT.
IF ACHETE IS NOT EMPTY
GET BUVEURS.
PRINT NOM, PRENOM IN BUVEURS.
END-IF.
END-IF.
FIND NEXT ABUS WITHIN F-BUVEURS.
FINISH.

Figure IV.13 : Accs au propritaire et utilisation dune condition

READY F-BUVEURS, F-COMMANDES.
MOVE 100 TO NB IN BUVEURS.
FIND ANY BUVEURS.
ERASE ALL BUVEURS.
FINISH.

Figure IV.14 : Suppression dun article et de ses descendants

READY F-BUVEURS.
MOVE 7 TO I.
MOVE 200 TO NB IN BUVEURS.
FIND ANY BUVEURS.
FIND I ABUS IN BOIT.
GET ABUS.
ADD 10 TO QUANTITE IN ABUS.
MODIFY ABUS.
FINISH.

Figure IV.15 : Modification dun article

136 BASES DE DONNES : OBJET ET RELATIONNEL

4. LE MODLE HIRARCHIQUE
Les bases de donnes modlisent des informations du monde rel. Puisque le monde
rel nous apparat souvent au travers de hirarchies, il est normal quun des modles
les plus rpandus soit le modle hirarchique. Quelques systmes sont encore bass
sur ce modle [MRI74, IBM78]. Vous trouverez une prsentation dtaille du modle
hirarchique dans [Tsichritzis76]. Nous rsumons ici les aspects essentiels.

4.1. LES CONCEPTS DU MODLE

Le modle hirarchique peut tre vu comme un cas particulier du modle rseau,
lensemble des liens entre types darticles devant former des graphes hirarchiques.
Cependant, les articles ne peuvent avoir de donnes rptitives. De plus, le modle
introduit en gnral des concepts spcifiques afin de modliser les objets. Un champ
est exactement lquivalent dun atome du modle rseau. Il sagit dune donne lmentaire valeur simple.
Notion IV.9 : Champ (Field)
Plus petite unit de donnes possdant un nom.

Un segment correspond un article sans groupe rptitif. Une occurrence de segment

est en gnral de taille fixe. Les champs dun segment sont tous au mme niveau, si
bien quune occurrence de segment est parfois qualifie darticle plat. Un segment
peut avoir un champ discriminant appel cl. La valeur de la cl permet alors de dterminer une occurrence unique dans le segment.
Notion IV.10 : Segment (Segment)
Collection de champs rangs conscutivement dans la base, portant un nom et dont une occurrence
constitue lunit dchange entre la base de donnes et les applications.

Les segments sont relis par des liens de 1 vers N qui un segment pre font correspondre N segments fils (N est un entier positif quelconque), aussi bien au niveau des
types quau niveau des occurrences. Ainsi, un type de segment possde en gnral
plusieurs types de segments descendants. De mme, une occurrence de segment est
relie plusieurs occurrences de chacun des segments descendants. Pour reprsenter
une descendance de segments relis par des associations pre-fils, on construit des
arbres de segments.
Notion IV.11 : Arbre de segments (Segment tree)
Collection de segments relis par des associations pre-fils, organise sous la forme dune hirarchie.

Bases de donnes rseaux et hirarchiques 137

Les types de segments sont donc organiss en arbre. Un type racine possde N1 types
fils, qui leur tour possdent chacun N2 types fils, et ainsi de suite jusquaux segments feuilles. Il est aussi possible de considrer une occurrence dun arbre de segments : une occurrence dun segment racine possde plusieurs occurrences de segments fils. Parmi celles-ci, certaines sont dun premier type, dautres dun second, etc.
leur tour, les occurrences des fils peuvent avoir des fils, et ainsi de suite jusquaux
occurrences des feuilles.
Finalement, une base de donnes hirarchique peut tre considre comme un
ensemble darbres, encore appel fort, dont les nuds sont des segments. La dfinition sapplique aussi bien au niveau des types quau niveau des occurrences. Les
arbres sont en principe indpendants. Chaque arbre possde un segment racine
unique, des segments internes et des segments feuilles. Le niveau dun segment caractrise sa distance la racine.
Notion IV.12 : Base de donnes hirarchique (Hierarchical data base)
Base de donnes constitue par une fort de segments.

Une reprsentation par un graphe dune base de donnes hirarchique dcoule de la

dfinition. Les nuds du graphe sont les segments alors que les arcs reprsentent les
associations pre-fils ; ces arcs sont orients du pre vers le fils. Il est possible de
considrer un graphe des types ou un graphe doccurrences (voir figure IV.16).
Type de segment
Occurrence de segment

Figure IV.16 : Graphe hirarchique de type et doccurrence

138 BASES DE DONNES : OBJET ET RELATIONNEL

Les deux graphes sont bien sr des forts, cest--dire des ensembles de hirarchies
sans lien entre elles. Un graphe des types nest pas diffrent dun diagramme de
Bachman dune base de donnes rseau ; cependant, de chaque segment est issu au
plus un lien allant vers son fils. Les liens ne sont pas nomms.
titre dexemple, nous avons dfini une base de donnes hirarchique partir de la base
vinicole. Il nest videmment pas possible de reprsenter un rseau de liens tel que dfini
figure IV.4. Afin de ne pas perdre dinformations, on est conduit dupliquer certaines
donnes, par exemple le cru du vin dans les segments ABUS et le nom du buveur dans
les segments COMMANDES (Champ CLIENT). Comme les segments ne sont pas hirarchiques, le type darticle VINS doit tre clat en deux segments CRUS et MILLESIMES. La figure IV.17 schmatise une reprsentation hirarchique de la base vinicole.

PRODUCTEURS

BUVEURS

CRUS

ABUS

MILLSIMES

COMMANDES

Figure IV.17 : Exemple de base hirarchique

Certains modles hirarchiques autorisent les liens entre arbres pour permettre de
modliser des associations de 1 vers N sans avoir dupliquer des segments. Tout segment dun arbre peut alors pointer vers un segment dun autre arbre. Cela peut tre
limit un seul pointeur par segment : on parle de lien frre, pour distinguer ce lien
du lien vers le fils. On aboutit alors des modles hirarchiques tendus dont les possibilits se rapprochent de celles du modle rseau [IBM78].

4.2. INTRODUCTION AU LANGAGE DL1

DL1 est un langage de manipulation de bases de donnes hirarchiques propos par
IBM dans son produit IMS [IBM78]. Nous allons ci-dessous en donner quelques prin-

Bases de donnes rseaux et hirarchiques 139

cipes afin dillustrer la manipulation de bases hirarchiques. Le langage DL1 est un

langage trs complexe qui permet de naviguer dans une base hirarchique partir de
programmes crits en PL1, COBOL ou FORTRAN. Vous trouverez diverses prsentations de ce langage dans [Tsichritzis76, Cardenas85].
Les recherches seffectuent en naviguant dans les arbres doccurrences. Un ordre de
parcours des arbres de la racine vers les fils, et de gauche droite, est impos. Plus
prcisment, cet ordre est dfini comme suit :
1. Visiter le segment considr sil na pas dj t visit.
2. Sinon, visiter le fils le plus gauche non prcdemment visit sil en existe un.
3. Sinon, si tous les descendants du segment considr ont t visits, remonter son
pre et aller 1.
Cet ordre de parcours des arbres est illustr figure IV.18 sur une fort doccurrences
de lun des arbres des types de segments dune base hirarchique. Une telle fort est
suppose avoir une racine virtuelle de tous les arbres pour permettre le passage dun
arbre un autre, reprsente par une ligne sur le schma. Lordre de parcours est utilis pour les recherches doccurrences de segments satisfaisant un critre, mais aussi
pour les insertions de nouvelles occurrences.

Arbre 1

Arbre 2

Figure IV.18 : Ordre de parcours des arbres en DL1

DL1 est un langage de manipulation navigationnel, en ce sens que des curseurs permettent de mmoriser un positionnement sur la base. Ces curseurs, appels PCB, sont
stocks dans des structures de donnes passes en arguments des appels DL1 effectus comme des appels de procdure depuis les programmes utilisateurs. Les PCB

140 BASES DE DONNES : OBJET ET RELATIONNEL

permettent en particulier de mmoriser des positionnements sur la base de donnes

par des cls base de donnes (adresses doccurrences de segments). Une cl base de
donnes est souvent la concatnation des cls des segments traverss depuis la racine
jusquau segment de niveau le plus bas slectionn. Les PCB permettent aussi de
rcuprer un code rponse STATUS du systme aprs chaque appel une commande
de recherche ou de mise jour. La figure IV.19 illustre la structure simplifie dun
PCB. Outre le nom de la base et le code rponse, on notera la prsence de la cl base
de donnes indiquant le positionnement courant du PCB.
01
02
02
02
02
02

PCB /* BLOC DE CONTROLE DE PROGRAMME */

NOM DE BASE /* BASE DE DONNES RFRENCES */
NIVEAU /* NIVEAU MAXIMUM CONSIDR */
STATUS /* CODE RPONSE AUX REQUETES */
LONGUEUR CLE /* LONGUEUR DU CHAMP SUIVANT */
CLE BASE DE DONNES/* POSITIONNEMENT COURANT SUR LA BASE */

Figure IV.19 : Curseurs de programme en DL1

Une qualification de chemin peut tre associe un appel DL1. Elle se compose
dune suite de qualifications de segments (Search Segment Argument); une qualification de segments est une structure dont une vue simplifie est reprsente
figure IV.20. Il sagit en fait dune expression logique parenthse ou conjonctive (ET
de OU) de critres de comparaisons portant sur un segment. Outre le nom du segment
concern, chaque prdicat lmentaire contient un code commande permettant de spcifier des options telles que recherche ou insertion demande, un nom de champ, un
comparateur et une valeur. Les prdicats lmentaires sont connects par le connecteur logique. Ils se suivent dans un SSA. Des parenthses peuvent tre utilises pour
marquer des priorits.
01
02
02
02
02
02
02

SSA /*(QUALIFICATION DE SEGMENTS)*/

NOM-DE-SEGMENT
CODE-COMMANDE /*(DIVERSES OPTIONS POSSIBLES)*/
NOM-DE-CHAMP
OPERATEUR-DE-COMPARAISON /*(<, , >, , =, )*/
VALEUR
CONNECTEUR /*(AND, OR) */

Figure IV.20 : Qualification de segment en DL1

Un ensemble de qualifications de segments suivant la hirarchie des segments constitue une qualification de chemin. Une telle qualification spcifie un chemin depuis la
racine jusquau segment cherch dans un arbre du graphe des types en permettant de
slectionner certaines occurrences de segment chaque niveau. Certains niveaux peu-

Bases de donnes rseaux et hirarchiques 141

vent tre absents, ce qui implique un balayage squentiel du segment de ce niveau. Le

code commande permet en particulier de spcifier si loccurrence de segment slectionne doit ou non tre lue en zone de travail lors de lutilisation du SSA dans une
commande de recherche au SGBD. Lors dune insertion dune hirarchie de segments, ce code permet de prciser si le segment du niveau doit tre insr. partir de
ces lments (PCB et qualification de chemin), diffrents types dappels au SGBD
peuvent tre effectus. Les plus importants sont explicits ci-dessous.
GET UNIQUE (GU) permet de rechercher directement la premire occurrence de
segment satisfaisant la qualification, par exemple pour une recherche sur cl. Le PCB
pass en argument est utilis pour mmoriser la cl base de donnes du segment
trouv ; le contenu des segments retrouvs chaque niveau est charg en mmoire
pour les segments dont le SSA demande la lecture dans le code commande.
GET NEXT (GN) permet de rechercher loccurrence de segment suivant celle
mmorise dans le PCB (en gnral la dernire trouve) satisfaisant la qualification si
elle existe. Le parcours du graphe seffectue selon lordre indiqu ci-dessus en
balayant squentiellement chaque occurrence de segment, sans tenir compte des liens
de filiation.
GET NEXT WITHIN PARENT (GNP) a la mme fonction que GET NEXT, mais il
autorise la recherche seulement lintrieur des descendants du segment courant. Il
permet donc de parcourir un lien depuis un parent.
INSERT (ISRT) permet dinsrer un nouveau segment en-dessous du parent slectionn par la qualification.
DELETE (DLET) permet de supprimer loccurrence du segment courant. Celle-ci a
d tre prcdemment slectionne par une instruction spciale du type GET HOLD
UNIQUE (GHU) ou GET HOLD NEXT (GHN) ou GET HOLD NEXT WITHIN
PARENT (GHNP) afin dassurer la non slection simultane par plusieurs utilisateurs.
La suppression dtruit loccurrence de segment prcdemment slectionne ainsi que
tous ses descendants sil en existe. Il sagit donc dune suppression en cascade.
REPLACE (REPL) permet de modifier loccurrence du segment courant. Celle-ci a
d tre prcdemment lue par une instruction spciale du type GET HOLD, comme
pour la suppression. La cl dun segment nest pas modifiable par la commande
REPLACE.

4.3. QUELQUES EXEMPLES DE TRANSACTIONS

Voici quelques types daccs par des transactions simples. La syntaxe utilise est trs
loin de la syntaxe pnible de DL1 [IBM78]. Il sagit en fait dune abstraction de cette
syntaxe compatible avec les commandes dcrites ci-dessus.

142 BASES DE DONNES : OBJET ET RELATIONNEL

/*DECLARATIONS*/
DCL 1 SSA
2 SEGMENT
2 CHAMP
2 OPERATEUR
2 VALEUR
DCL 1 PCB
..........
2 STATUS

=
=
=
=

BUVEURS
NB
=
100

/*PROGRAMME*/
GU (PCB, BUVEUR, SSA)
PRINT BUVEUR.NOM, BUVEUR.PRENOM

Figure IV.21 : Accs sur cl

/*DECLARATIONS*/
DCL 1 SSA1
2 SEGMENT
2 CHAMP
2 OPERATEUR
2 VALEUR
DCL 1 SSA2
2 SEGMENT
2 CHAMP
2 OPERATEUR
2 VALEUR
DCL 1 PCB
..........
2 STATUS

=
=
=
=

PRODUCTEURS
NOM
=
MARTIN

=
=
=
=

CRUS
CRU
=
BEAUJOLAIS

/*PROGRAMME*/
GU (PCB, CRUS, SSA1, SSA2)
WHILE STATUS fin-de-descendance
GNP
PRINT segment lu
END-WHILE

Figure IV.22 : Balayage des descendants dune occurrence de segment

Bases de donnes rseaux et hirarchiques 143

/*DECLARATIONS*/
DCL 1 SSA1
2 SEGMENT
2 CHAMP
2 OPERATEUR
2 VALEUR
DCL 1 SSA2
2 SEGMENT
2 CHAMP
2 OPERATEUR
2 VALEUR
DCL 1 SSA3
2 SEGMENT
2 CHAMP
2 OPERATEUR
2 VALEUR
2 CONNECTEUR
2 CHAMP
2 OPERATEUR
2 VALEUR
DCL 1 PCB
..........
2 STATUS

=
=
=
=

PRODUCTEURS
NOM
=
MARTIN

=
=
=
=

CRUS
CRU
=
BEAUJOLAIS

=
=
=
=
=
=
=
=

COMMANDES
DATE
=
10-02-81
AND
CLIENT
=
DUPONT

/*PROGRAMME*/
GHU (PCB, COMMANDES, SSA1, SSA2, SSA3)
COMMANDES.QUANTITE = COMMANDES.QUANTITE + 100
RPL

Figure IV.23 : Mise jour dune occurrence de segment

5. CONCLUSION
Dans ce chapitre, nous avons prsent les principaux modles daccs, cest--dire
ceux directement issus de la modlisation dorganisation darticles stocks dans des
fichiers et relis entre eux par des pointeurs. Ces modles sont encore trs utiliss :
une part significative des grandes bases de donnes sont sans doute encore hirarchiques ou organises en rseaux. Ces modles sont aussi trs performants car trs
proches du niveau physique. Le modle rseau permet des organisations de liens plus
gnrales que le modle hirarchique, bien que celui-ci ait souvent t tendu par des
liens inter-hirarchies.
Compte tenu de laccroissement des possibilits des machines, les modles daccs sont
aujourdhui inadapts en tant que modles conceptuels ou externes de donnes. Ils assu-

144 BASES DE DONNES : OBJET ET RELATIONNEL

rent en effet une faible indpendance des programmes aux donnes. Ils peuvent rester
trs comptitifs au niveau interne. Les critiques proviennent sans doute aussi de la complexit des langages de manipulation historiquement associs ces modles, bass sur la
navigation. Cependant, il est tout fait possible de dfinir des langages de plus haut
niveau fonds sur la logique des prdicats pour un modle hirarchique ou rseau.
Finalement, la question sest pose de savoir si le modle entit-association est un
meilleur candidat pour modliser les donnes au niveau conceptuel que le modle
rseau. La rponse est positive. En effet, un modle se voulant un cadre conceptuel
pour dfinir une large classe de base de donnes structures et un mdiateur entre des
reprsentations de donnes stockes et des vues usagers, devrait probablement avoir
au moins quatre caractristiques [Codd79] :
1. permettre une reprsentation sous forme de tableaux de donnes ;
2. permettre une interrogation ensembliste afin dautoriser des requtes sans prciser
les ordres lmentaires de navigation dans la base ;
3. permettre une interprtation des objets en termes de formules de la logique des prdicats afin de faciliter les infrences de connaissances ;
4. supporter une reprsentation graphique simple afin de pouvoir visualiser les objets
et leurs associations pour concevoir la base.
Ajoutons galement que la simplicit est une caractristique essentielle dun modle.
Cest l un avantage important du modle relationnel que nous allons tudier dans la
partie suivante de cet ouvrage.

6. BIBLIOGRAPHIE
[Bachman64] Bachman C., Williams S., A General Purpose Programming System
for Random Access Memories , Fall Joint Computer Conference, vol. 26,
AFIPS Press, p. 411-422.
La premire prsentation du systme IDS, ralis General Electric au dbut
des annes 60.
[Bachman69] Bachman C., Data Structure Diagrams , Journal of ACM, SIGBDP
vol. 1, n 2, mars 1969, p. 4-10.
Cet article introduit les diagrammes de Bachman. Ceux-ci permettent de modliser les types darticles par des botes et les liens (sets) par des flches depuis
le propritaire vers le membre. Ils modlisent une base de donnes comme un
graphe dont les nuds sont les types darticles et les arcs les associations de 1
vers n articles. Ce type de modlisation est toujours trs utilis, notamment
dans loutil de conception BACHMAN, du nom de linventeur.

Bases de donnes rseaux et hirarchiques 145

[Bachman73] Bachman C., The Programmer as Navigator , Communication of the

ACM, vol. 16, n 1, novembre 1971.
Cet article correspond la prsentation de Charlie Bachman lorsquil a reu le
Turing Award en 1973. Bachman compare le programmeur un navigateur qui
suit les chemins daccs aux bases de donnes laide de curseurs, afin
datteindre les articles dsirs.
[Cardenas85] Cardenas A., Data Base Management Systems, 2nd Edition, Allyn and
Bacon, Boston, Ma, 1985.
Ce livre prsente plus particulirement les techniques de base des modles
rseau et hirarchique. Il dcrit de nombreux systmes dont TOTAL, IDS II,
SYSTEM 2000 et IMS.
[Codasyl71] Codasyl Database Task Group, DBTG April 71 Report, ACM Ed., New
York, 1971.
Les spcifications de rfrence des langages de description et de manipulation
du CODASYL. La prsentation effectue dans ce chapitre est trs proche de ces
propositions.
[Codasyl78] Codasyl Database Task Group, Codasyl Data Description Language
Journal of Development, Codasyl Ed., New York, 1978.
La nouvelle version du langage de dfinition de donnes du CODASYL. Cette
version est probablement moins implmente que la prcdente.
[Codasyl81] Codasyl Database Task Group, Codasyl Data Description Language
Journal of Development Draft Report, Codasyl Ed., New-York, 1981.
Encore une nouvelle version du langage de dfinition et de manipulation de
donnes du CODASYL. Cette version na jamais t adopte.
[IBM78] IBM Corporation, Information Management System/ Virtual Storage
General Information , IBM Form Number GH20-1260, SH20-9025-27.
La description gnrale du systme IMS II dIBM.
[MRI74] MRI Systems Corporation, System 2000 Reference Manual, Document
UMN-1, 1974.
Le manuel de rfrence de la premire version de System 2000.
[Taylor76] Taylor R.W., Frank R.L., Codasyl Data Base Management Systems ,
ACM Computing Surveys, vol. 8, n 1, mars 1976.
Un panorama trs complet rsumant les caractristiques et les volutions du
modle rseau.
[Tsichritzis76] Tsichritzis D.C., Lochovsky F.H., Hierarchical Database
Management A Survey , ACM Computing Surveys, vol. 8, n 1, mars 1976.
Un panorama trs complet rsumant les caractristiques et les volutions du
modle hirarchique.

Chapitre V

LOGIQUE ET BASES DE DONNES

1. INTRODUCTION
Historiquement, les chercheurs ont tout dabord essay de modliser les langages
dinterrogation de bases de donnes par la logique. Ainsi sont ns les calculs relationnels, vritables langages dinterrogation fonds sur la logique du premier ordre. Ce
nest qu partir de la fin des annes 70 que lon a cherch comprendre globalement
les bases de donnes par la logique. Cela a permis de montrer quun SGBD tait un
dmonstrateur de thormes trs particulier, raisonnant sur des faits et donnant les
preuves dun thorme reprsentant la question.
Les travaux sur lintroduction dans les SGBD de raisonnements gnraux incluant
non seulement des faits, mais aussi des rgles dductives exprimes en logique du
premier ordre, ont dbut principalement au CERT Toulouse la fin de la dcennie
1970-1980 [Gallaire78]. Ils se sont surtout concentrs sur la comprhension des bases
de donnes dductives par la logique. Afin de permettre la gestion de grandes bases
de connaissances (quelques milliers de rgles associes quelques millions voire milliards de faits), des problmes de recherche complexes ont d tre rsolus. Ces problmes sont la croise des chemins des bases de donnes et de lintelligence artificielle et prsentent des aspects la fois thoriques et pratiques. Dun point de vue
thorique, les approches par la logique permettent une meilleure comprhension des
langages des SGBD, des mcanismes de raisonnements sous-jacents et des techniques
doptimisation. Dun point de vue pratique, le dveloppement de SGBD bass sur la

148 BASES DE DONNES : OBJET ET RELATIONNEL

logique supportant la dduction a conduit des prototypes oprationnels, mais encore

rarement des produits.
Ce chapitre se propose tout dabord dintroduire les notions de base de logique ncessaires la bonne comprhension des bases de donnes. Nous dfinissons ce quest une
base de donnes logique vue comme une interprtation dun langage logique. Il sagit
simplement dun ensemble de faits lists dans des tables. Historiquement, cette vision
est une comprhension des bases de donnes relationnelles proposes par Gallaire,
Minker et Nicolas la fin des annes 70 [Gallaire81]. Cest une vision lmentaire
appele thorie du modle (ou de linterprtation). Pour beaucoup, le terme BD
logique inclut les facilits dductives que nous tudierons dans le chapitre sur les BD
dductives.
Dans ce chapitre, nous introduisons aussi les langages logiques dinterrogation de
bases de donnes que sont les calculs de domaines et de tuples. Ils sont une formalisation des langages des bases de donnes relationnelles que nous tudierons dans la partie suivante. Pour bien les comprendre, il est bon davoir quelques notions sur les BD
relationnelles, mais ce nest sans doute pas indispensable.
Ce chapitre comporte cinq sections. Aprs cette introduction, la section 2 introduit la
logique du premier ordre et les manipulations de formules. La section 3 dfinit ce
quest une BD logique non dductive. La section 4 est consacre au calcul de domaine
et son application pratique, le langage QBE. La section 5 traite de la variante calcul
de tuple, qui tait la base du langage QUEL, somme toute assez proche de SQL. La
section 6 introduit les techniques de raisonnement et de preuve de thorme. Il est
ncessaire de connatre un peu ces techniques pour aborder ultrieurement les bases
de donnes dductives.

2. LA LOGIQUE DU PREMIER ORDRE

Dans cette partie, nous rappelons les principes de la logique du premier ordre et nous
introduisons la mthode de rcriture sous forme de clauses. La logique permet une
modlisation simple des bases de donnes, lintroduction de langages de requtes formels et le support de la dduction.

2.1. SYNTAXE DE LA LOGIQUE DU PREMIER ORDRE

Rappelons que la logique du premier ordre, aussi appele calcul de prdicats, est un
langage formel utilis pour reprsenter des relations entre objets et pour dduire de

Logique et bases de donnes 149

nouvelles relations partir de relations connues comme vraies. Elle peut tre vue
comme un formalisme utilis pour traduire des phrases et dduire de nouvelles
phrases partir de phrases connues.
La logique du premier ordre repose sur un alphabet qui utilise les symboles suivants :
1. Des variables gnralement notes x, y, z
2. Des constantes gnralement notes a, b, c
3. Des prdicats gnralement notes P, Q, R , chaque prdicat pouvant recevoir un
nombre fixe darguments (n pour un prdicat n-aire).
4. Les connecteurs logiques , , , .
5. Des fonctions gnralement dnotes f, g, h, chaque fonction pouvant recevoir un
nombre fixe darguments (n pour une fonction n-aire).
6. Les quantificateurs et .
Des rgles syntaxiques simples permettent de construire des formules. Un terme est
dfini rcursivement comme une variable ou une constante ou le rsultat de lapplication dune fonction un terme. Par exemple, x, a, f(x) et f(f(x)) sont des termes. Une
formule est une phrase bien construite du langage. Une formule est dfinie comme
suit :
1. Si P est un prdicat n arguments (n places) et t1, t2tn des termes, alors
P(t1,t2tn) est une formule atomique.
2. Si F1 et F2 sont des formules, alors F1 F2, F1 F2, F1 F2 et F1 sont des
formules.
3. Si F est une formule et x une variable non quantifie (on dit aussi libre) dans F,
alors x F et x F sont des formules.
Nous rsumons ci-dessous les concepts essentiels introduits jusque-l sous forme de
notions.
Notion V.1 : Terme (Term)
Constante, variable ou fonction applique un terme.
Notion V.2 : Formule atomique (Atomic Formula)
Rsultat de lapplication dun prdicat n-places n termes, de la forme P(t1,t2tn).
Notion V.3 : Formule (Formula)
Suite de formules atomiques ou de ngation de formules atomiques spares par des connecteurs
logiques et, ou, implique, avec dventuelles quantifications des variables.

Pour indiquer les priorits entre connecteurs logiques, il est possible dutiliser les
parenthses : si F est une formule valide, (F) en est aussi une. Afin dviter les paren-

150 BASES DE DONNES : OBJET ET RELATIONNEL

thses dans certains cas simples, nous supposerons une priorit des oprateurs
logiques dans lordre descendant , , , et . Voici quelques exemples de formules
formelles :
P(a,x) Q(x,y),
Q(x,y),
x y (Q(x,y) P(a,x)),
x (R(x) Q(x,a) P(b,f(x))).
Afin de donner des exemples plus lisibles de formules, nous choisirons un vocabulaire
moins formel, les prdicats et fonctions tant des noms ou des verbes du langage courant et les constantes des chanes de caractres dsignant par exemple des services ou
des employs. Voici quelques exemples de formules proches du langage naturel :
SERVICE(informatique,pierre) EMPLOYE (informatique,marie)
x ((DIRIGE(pierre,x) EMPLOYE(informatique,x) EMPLOYE(finance,x))
x y ((DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y))

2.2. SMANTIQUE DE LA LOGIQUE

DU PREMIER ORDRE
Une formule peut tre interprte comme une phrase sur un ensemble dobjets : il est
possible de lui donner une signification vis--vis de cet ensemble dobjets. Pour ce
faire, il faut assigner un objet spcifique chaque constante. Par exemple, on assigne
un objet la constante a, le service Informatique de lentreprise considre la
constante informatique, lemploye Marie la constante marie, etc. Lensemble
dobjets considrs est appel le domaine de discours ; il est not D. Chaque fonction n arguments est interprte comme une fonction de Dn dans D. Un prdicat
reprsente une relation particulire entre les objets de D, qui peut tre vraie ou fausse.
Dfinir cette relation revient dfinir les tuples dobjets qui satisfont le prdicat.
Lensemble des tuples satisfaisants le prdicat constitue son extension.
Notion V.4 : Domaine de discours (Domain of Discourse)
Ensemble dobjets sur lequel une formule logique prend valeur par interprtation des constantes
comme des objets particuliers, des variables comme des objets quelconques, des prdicats comme
des relations entre objets et des fonctions comme des fonctions particulires entre objets.

Par exemple, la formule :

x y ((DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y))
peut tre interprte sur lensemble des personnes {Pierre, Paul, Marie}, qui constitue
alors le domaine de discours. DIRIGE peut tre interprt comme la relation binaire
est chef de ; MEMESERVICE peut tre interprt comme la relation binaire tra-

Logique et bases de donnes 151

vaille dans le mme service . La formule est vraie si Pierre, Paul et Marie travaillent
dans le mme service.
Un univers de discours infini peut tre retenu pour interprter la formule
x (x < SUCC(x)). En effet, cette formule peut tre interprte sur lensemble des
entiers positifs {1,2,3} qui est infini. < est alors la relation est infrieur et
SUCC la fonction qui tout entier associe son successeur. Il est clair que cette formule est vraie sur les entiers.
Ainsi, tant donn une interprtation dune formule sur un domaine de discours, il est
possible dassocier une valeur de vrit cette formule. Pour viter les ambiguts (les
formules pouvant avoir plusieurs valeurs de vrit), nous considrons seulement les
formules dans lesquelles toutes les variables sont quantifies, appeles formules fermes. Toute formule ferme F a une unique valeur de vrit pour une interprtation
donne sur un domaine de discours D. Cette valeur note V(F) se calcule ainsi :
V(F1 F2) = V(F1) V(F2)
V(F1 F2) = V(F1) V(F2)
V( F1) = V(F1)
V(x F) = V(F x=a) V(F x=b) o a, b, sont les constantes de D.
V(x F) = V(F x=a) V(F x=b) o a, b, sont les constantes de D.
V(P(a,b)) = Vrai si [a,b] satisfait la relation P et Faux sinon.
Un modle dune formule logique est une interprtation sur un domaine de discours
qui rend la formule vraie. Par exemple, les entiers sont un modle pour la formule
x (x < SUCC(x)) avec linterprtation indique ci-dessus. En effet, en appliquant les
rgles ci-dessus, on calcule :
V(x (x < SUCC(x))) = V(1 < 2) V(2<3) V(3<4) = Vrai.

2.3. FORME CLAUSALE DES FORMULES FERMES

Toute formule ferme, cest--dire variables quantifies, peut se simplifier et scrire
sous une forme canonique sans quantificateurs, appele forme clausale. La forme
clausale ncessite dcrire la formule comme un ensemble de clauses.
Notion V.5 : Clause (Clause)
Formule de la forme P1 P2 Pn Q1 Q2 Qm, ou les Pi et les Qj sont des littraux
positifs (cest--dire des prdicats atomiques sans ngation devant).

Une clause ayant un seul littral situ aprs limplication (on dit en tte de clause),
donc un seul Qi, est dite clause de Horn.

152 BASES DE DONNES : OBJET ET RELATIONNEL

Notion V.6 : Clause de Horn (Horn Clause)

Clause de la forme P1 P2 Pn Q1.

Par exemple :
ENTIER(x) (x > 0) (x < SUCC(x)) (x > SUCC(x))
DIRIGE(x,y) MEMESERVICE(x,y) AIME(x,y) DETESTE(x,y)
sont des clauses.
ENTIER(x) (x > 0) (x < SUCC(x))
DIRIGE(x,y) MEMESERVICE(x,y) AIME(x,y)
sont des clauses de Horn.
La transformation dune formule ferme en clauses seffectue par des transformations
successives que nous dcrivons brivement ci-dessous. Nous illustrons les transformations avec la formule :
x y ((DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y)).
1. limination des implications. Ceci seffectue simplement en remplaant toute
expression de la forme A B par A B. En effet, ces expressions sont quivalentes du point de vue logique. La formule choisie en exemple devient :
x y ( (DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y)).
2. Rduction de la porte des ngations. Le but est de faire que les ngations
sappliquent directement des prdicats atomiques. Pour cela, on utilise de manire
rpte les transformations :
(A B) devient A B;
(A B) devient A B;
(xA) devient xA;
(xA) devient xA;
( A) devient A.
Lexemple devient :
x y (( DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y)).
3. Mise en forme prenex. Il sagit simplement de mettre les quantificateurs avec la
variable quantifie en-tte de formule. Cette tape peut ncessiter de renommer les
variables afin dviter les confusions de quantification. Notre exemple reste ici
inchang.
4. limination des quantificateurs. Afin de simplifier encore, les variables quantifies existentiellement sont remplaces par une constante paramtre dite constante
de Skolem. En effet, sil existe x satisfaisant une formule, il est possible de choisir
une constante s dsignant cette valeur de x. Attention, si une variable quantifie par
quel que soit apparat avant la variable quantifie par il existe , la constante
choisie dpend de la premire variable. Par exemple, dans le cas x y (pour tout x,

Logique et bases de donnes 153

il existe y, mais le y dpend de x), on remplacera donc y par s(x), cest--dire une
fonction de Skolem qui matrialise la constante y dpendant de x. Ainsi, il est possible dliminer les variables quantifies par il existe . Aprs cette transformation, toute variable restante est quantifie par quel que soit . On peut donc
oublier dcrire les quantificateurs (cest implicitement ). Notre exemple devient
alors :
(( DIRIGE(x,s(x)) DIRIGE(s(x),x)) MEMESERVICE(x,s(x))).
5. Mise en forme normale conjonctive. La formule restante est une combinaison par
des ou et des et de littraux positifs ou ngatifs (prdicats atomiques prcds ou non dune ngation). Elle peut tre crite comme une conjonction () de disjonction () en distribuant les et par rapport aux ou laide de la rgle :
A (B C) devient (A B) (A C).
Lexemple devient ainsi :
( DIRIGE(x,s(x)) MEMESERVICE(x,s(x))) ( DIRIGE(s(x),x))
MEMESERVICE(x,s(x))).
6. criture des clauses. Finalement, il est simple dcrire chaque clause sur une ligne
en remplaant les et par des changements de lignes. De plus, profitant du fait
que A s crit A , on peut crire tous les prdicats ngatifs dabord en
liminant la ngation et en les connectant par , puis tous les prdicats positifs
connects par . On obtient bien ainsi une suite de clauses, dfinies comme ci-dessus. Avec lexemple, on obtient deux clauses (dailleurs de Horn):
DIRIGE(x,s(x)) MEMESERVICE(x,s(x))
DIRIGE(s(x),x)) MEMESERVICE(x,s(x))).

3. LES BASES DE DONNES LOGIQUES

La notion de base de donnes logique a t introduite en particulier Toulouse la fin
des annes 70 [Gallaire84]. Nous dfinissons ici ce quest une base de donnes
logique non dductive. Il sagit dune premire approche simple des bases de donnes
par la logique. Nous verrons plus loin que cette approche peut tre tendue avec la
dduction.

3.1. LA REPRSENTATION DES FAITS

Une base de donnes peut tre dfinie comme linterprtation dun langage logique
du premier ordre L. En pratique, dfinir linterprtation consiste dfinir les prdicats

154 BASES DE DONNES : OBJET ET RELATIONNEL

vrais. Le langage permet dexprimer les requtes, comme nous le verrons ci-dessous.
Une contrainte dintgrit peut tre vue comme une requte toujours vraie, donc
exprime avec le langage.
Notion V.7 : Base de donnes logique (Logic database)
Ensemble de faits constituant linterprtation dun langage du premier ordre avec lequel il est possible dexprimer des questions et des contraintes dintgrit sur les faits.

En premire approche, le langage logique L ne comporte pas de fonctions. Plus particulirement, L se compose :
1. de prdicats n arguments, chaque argument correspondant un type de donnes
lmentaire ;
2. de constantes, une pour chaque valeur possible des type de donnes lmentaires.
Comme dans toute interprtation dun langage logique, un prdicat reprsente une
relation particulire entre les objets du domaine de discours, qui peut tre vraie ou
fausse. Ici les objets du domaine de discours sont donc les valeurs possibles de la
base. Dfinir cette relation revient dfinir les articles ou n-uplets qui satisfont le prdicat. Lensemble des n-uplets satisfaisant le prdicat constitue son extension. Cette
extension peut tre assimile un fichier dans une base en rseau ou une table relationnelle, comme nous le verrons plus loin. Pour rester cohrent avec les bases de
donnes relationnelles qui peuvent tre perues comme une implmentation simple
des bases de donnes logiques, nous appellerons lextension dun prdicat une table.
Chaque colonne correspond un argument et est aussi appele attribut dans le
contexte relationnel. Comme dj dit, une base de donnes logique pourra tre complte par des rgles de dduction : nous parlerons alors de base de donnes dductive (voir partie 4 de cet ouvrage).
La figure V.1 illustre une base de donnes logique. En termes de tables, cette base correspond celles reprsentes figure V.2. Elle est compose de trois prdicats dfinis
comme suit :
PRODUIT avec les arguments Numro de produit (NPRO), nom de produit
(NPRO), quantit en stock (QTES), et couleur (COULEUR) ;
VENTE avec les arguments numro de vente (NVEN), nom du client (NOMC),
numro du produit vendu (NPRV), quantit vendue (QTEV) et date (DATE) ;
ACHAT avec les arguments numro dachat (NACH), date de lachat (DATE), numro
du produit achet (NPRA), quantit achete (QTEA) et nom du fournisseur (NOMF).
Comme on le voit, seul les faits positifs, cest--dire ceux satisfaisant lun des trois
prdicats, sont enregistrs dans la base. Ceci constitue lhypothse du monde ferm.
Les faits non enregistrs dans une extension de prdicat sont supposs faux. Il est vrai
que si vous interrogez la base de donnes que gre votre banque et que vous ne voyez
pas de chque de 100 000 euros crdits ce jour, cest que le fait que cette somme ait

Logique et bases de donnes 155

t crdite sur votre compte est faux ! Des chercheurs ont essay de lever cette hypothse : on tombe alors dans lhypothse du monde ouvert, ou un fait non enregistr
peut tre inconnu [Reiter78].
PRODUIT (100, BILLE, 100
, VERTE)
PRODUIT (200, POUPEE, 50, ROUGE)
PRODUIT (300, VOITURE, 70, JAUNE)
PRODUIT (400, CARTE, 350, BLEU)
VENTE (1, DUPONT, 100, 30, 08-03-1999)
VENTE (2, MARTIN, 200, 10, 07-01-1999)
VENTE (3, CHARLES, 100, 50, 01-01-2000)
VENTE (4, CHARLES, 300, 50, 01-01-2000)
ACHAT (1, 01-03-1999, 100, 70, FOURNIER)
ACHAT (2, 01-03-1999, 200, 100, FOURNIER)
ACHAT (3, 01-09-1999, 100, 50, DUBOIS)

Figure V.1 : Faits constituant une base de donnes logique

PRODUIT

NPRO
100
200
300
400

NOMP
Bille
Poupe
Voiture
Carte

QTES
100
50
70
350

COULEUR
Verte
Rouge
Jaune
Bleu

VENTE

NVEN
1
2
3
4

NOMC
Dupont
Martin
Charles
Charles

NPRV
100
200
100
300

QTEV
30
10
50
50

DATE
08-03-1999
07-01-1999
01-01-2000
01-01-2000

ACHAT

NACH
1
2
3
4

DATE
01-03-1999
01-03-1999
01-09-1999
01-09-1999

NPRA
100
200
100
300

QTEA
70
100
50
50

NOMF
Fournier
Fournier
Dubois
Dubois

Figure V.2 : Tables reprsentant la base de donnes logique

3.2. QUESTIONS ET CONTRAINTES DINTGRIT

Les questions et les contraintes dintgrit sur la base peuvent alors tre exprimes
comme des formules dans le langage logique. Cependant, celui-ci doit tre tendu

156 BASES DE DONNES : OBJET ET RELATIONNEL

pour inclure les oprateurs de comparaison arithmtique {=, <, , >, , } comme des
prdicats particuliers, dont la valeur de vrit est calcule par les oprations usuelles
des calculateurs.
La rponse une question F(x1, , xn) o x1, xn sont des variables libres dans la
formule F est alors lensemble des n-uplets <e1, ,ep> tels que F(e1, ep) est
vraie. Certaines formules doivent tre toujours vraies sur linterprtation que constitue
la base : ce sont alors des contraintes dintgrit. Cette vue logique des bases de donnes a donn naissance deux calculs permettant dexprimer des questions et des
contraintes dintgrit sur les bases : le calcul de domaine et le calcul de tuple. Dans
le premier, les objets de linterprtation logique sont les valeurs atomiques de
donnes ; dans le second ce sont les faits composites correspondant aux n-uplets,
encore appels tuples. Nous tudions ces deux calculs ci-dessous.

4. LE CALCUL DE DOMAINES
Les calculs relationnels de domaine et de tuples [Codd72] permettent dexprimer des
requtes laide de formules du premier ordre sur une base de donnes logique, ou sa
reprsentation tabulaire qui est une base de donnes relationnelles. Ils ont t utiliss
pour formaliser les langages dinterrogation pour les bases de donnes relationnelles.
Ci-dessous, nous tudions tout dabord le calcul de domaine et sa reprsentation bidimensionnelle QBE [Zloof77], puis le calcul de tuples. Le langage QUEL introduit
au chapitre II peut tre peru comme un paraphrasage en anglais du calcul de tuples.

4.1. PRINCIPES DE BASE

Le calcul relationnel de domaines [Codd72] se dduit donc de la logique du premier
ordre. Les donnes sont les constantes. Les prdicats utiliss sont :
1. les prdicats extensionnels contenant les enregistrements de la base ; chaque enregistrement est un tuple typ selon un prdicat extensionnel ; les prdicats tant naire, une variable ou une constante est utilise comme argument de prdicat ; les
variables sont alors implicitement types selon le type de largument pour lequel
elles apparaissent ;
2. les prdicats de comparaison entre une variable et une constante, ou entre deux
variables, construits laide des oprateurs {=, , <, , >, }.
Une question en calcul relationnel de domaine scrit donc sous la forme suivante :
{x, y | F(x,y, )}

Logique et bases de donnes 157

F est une formule logique compose partir de prdicats extensionnels et de comparaison ; les variables rsultats x, y, , sont des variables libres dans F.
La notion suivante rsume la dfinition du calcul de domaine.
Notion V.8 : Calcul relationnel de domaines (Domain relational calculus)
Langage dinterrogation de donnes formel permettant dexprimer des questions partir de formules bien formes dont chaque variable est interprte comme variant sur le domaine dun argument dun prdicat.

La BNF du calcul relationnel de domaine est dfinie figure V.3. Pour simplifier, les
formules sont crites en forme prenex (quantificateurs devant). En pratique, une simplification dcriture permet de regrouper des prdicats de restriction du type (x = a)
et des prdicats de dfinition de variable du type P (x, ) en crivant P (a, ). Toute
variable apparaissant dans le rsultat doit tre dfinie dans un prdicat extensionnel et
doit rester libre dans la formule spcifiant la condition. Une variable non utilise ni en
rsultat ni dans un critre de comparaison peut tre remplace par la variable muette
positionnelle note .
<question> : := { (<rsultat>) | <formule> }
<rsultat> : := <variable> | <variable>, <rsultat>
<formule> : := <quantification> <formule libre> | <formule libre>
<quantification> ::= <variable> | <variable>
| <quantification> <quantification>
<formule libre> : := <formule atomique>
| <formule libre> <formule atomique>
| <formule libre> <formule atomique>
| <formule libre> <formule libre>
| <formule libre>
| (<formule libre>)
<formule atomique> : := <prdicat extensionnel> (<arguments>)
| <terme> <comparateur> <terme>
<arguments> : := <terme> | <terme>, <terme>
<terme> : := <variable> | <constante>
<comparateur> : := = | < | | > | |

Figure V.3 : BNF du calcul relationnel de domaines

4.2. QUELQUES EXEMPLES DE CALCUL DE DOMAINE

Nous illustrons le calcul de domaine sur la base logique introduite ci-dessus dcrivant
des achats et des ventes de produits stocks dans un magasin. Le schma de la base
est le suivant :

158 BASES DE DONNES : OBJET ET RELATIONNEL

PRODUIT (NPRO, NOMP, QTES, COULEUR)

VENTE (NVEN, NOMC, NPRV, QTEV, DATE)
ACHAT (NACH, DATE, NPRA, QTEA, NOMF)

Le prdicat extensionnel PRODUIT se compose des attributs numro de produit

(NPRO), nom du produit (NOMP), quantit en stock (QTES) et couleur (COULEUR).
Le prdicat VENTE dcrit les ventes de produits effectues et se compose des attributs numro de vente (NVEN), nom du client (NOMC), numro du produit vendu
(NPRV), quantit vendue (QTEV) et date de la vente (DATE). Le prdicat ACHAT
dfinit les achats effectus aux fournisseurs. Il contient les attributs numro dachat
(NACH), date dachat (DATE), numro du produit achet (NPRA), quantit achete
(QTEA) et nom du fournisseur (NOMF). Pour simplifier la lecture, nous utilisons des
variables rappelant le nom du domaine. Notez que les quantificateurs existentiels dans
les formules peuvent tre omis, car ils sont implicites si la variable est libre et ne
figure pas en rsultat.
(Q1) Donner la liste des noms et des couleurs de tous les produits :
{(p,c) | PRODUIT (,p,,c)}
(Q2) Donner les noms et les quantits en stock des produits de couleur rouge :
{(p,q) | PRODUIT (, p, q, Rouge)}
(Q3) Donner, pour chaque produit en stock, le nom du fournisseur associ :
{(p,f) | n (PRODUIT (n, p, , ) ACHAT (, , n, , f))}
(Q4) Donner, pour chaque produit en stock en quantit suprieure 100 et de couleur
rouge, les triplets nom de fournisseurs ayant vendu ce type de produit et nom de
client ayant achet ce type de produit et nom du produit :
{(f, c, p) | n q (PRODUIT (n, p, q, Rouge) ACHAT (, , n, , f)
VENTE (, c, n, , ) (q > 100))}
(Q5) Donner les noms des clients ayant achet au moins un produit de couleur verte :
{(c) | n (VENTE (, c, n, , ) PRODUIT (n, , , Verte))}
(Q6) Donner les noms des clients ayant achet tous les produits stocks :
{(c) | p (PRODUIT (p, , , ) VENTE (, c, p, , ))}
(Q7) Donner les noms des produits fournis par tous les fournisseurs et achets par au
moins un client :
{(p) | f (ACHAT(,, , , f) ACHAT (, , p, , f))
c VENTE (, c, p, , )}

4.3. LE LANGAGE QBE

Le langage Query-By-Exemple (QBE) [Zloof77] est conu pour tre utilis partir
dun terminal. Il a t dvelopp par M. ZLOFF IBM Yorkton Heights. Il est com-

Logique et bases de donnes 159

mercialis par IBM au-dessus de DB2 depuis 1983 et plus rcemment par de nombreux autres constructeurs avec des prsentation varies, par exemple par Microsoft
dans ACCESS. Ce langage peut tre considr comme une mise en uvre visuelle
(base sur des tableaux affichs) du calcul relationnel de domaine.
Lide de base du langage est de faire formuler une question lutilisateur partir
dun exemple dune rponse possible la question. Pour cela, lutilisateur provoque
tout dabord laffichage du schma des tables ncessaires la question quil dsire
poser (sous forme de squelettes de tables) par frappe du nom des tables correspondantes. Ainsi, des tables vides (avec seulement les en-ttes de colonnes et le nom de la
relation associe) apparaissent sur lcran. Elles correspondent bien sr aux dfinitions des prdicats extensionnels de la base logique. Par exemple, il est possible
dafficher le schma des tables PRODUIT, VENTE et ACHAT comme reprsent
figure V.4.

PRODUIT

NPRO

NOMP

QTES

COULEUR

VENTE

NVEN

NOMC

NPRV

QTEV

DATE

ACHAT

NACH

DATE

NPRA

QTEA

NOMF

Figure V.4 : Schmas de tables affichs par QBE

Comme indiqu ci-dessus, QBE peut tre vu comme une implantation deux dimensions du calcul relationnel de domaines. Pour cela, les rgles suivantes sont utilises :
1. Les rsultats (attributs projeter en relationnel) sont dfinis en frappant P.
(PRINT) dans la colonne associe. Il est possible dimprimer tous les attributs
dune table en frappant P. dans la colonne contenant le nom de la table.

160 BASES DE DONNES : OBJET ET RELATIONNEL

2. Les constantes sont tapes directement dans la colonne de lattribut associ, prcdes de loprateur de comparaison les reliant lattribut si ce nest pas = (cest-dire <, , >, , ). Dans le cas o un critre complexe est ncessaire avec des
conjonctions (and) et disjonctions (or), il est possible douvrir une bote condition et
de taper le critre dans cette bote (par exemple A < 10 AND A > 5).
3. Les variables domaines sont dsignes par des valeurs exemples soulignes tapes
dans la colonne les spcifiant ; la valeur exemple souligne est en fait le nom de la
variable domaine ; par suite, QBE associe deux valeurs soulignes identiques
comme dfinissant une mme variable.
4. Le quantificateur quel-que-soit est appliqu une variable en tapant ALL.
devant son nom (lexemple soulign) alors que toute variable non imprime non
prcde de P. est implicitement quantifie par il-existe .
5. Le connecteur ou (or) est exprim en utilisant deux lignes (deux exemples) comme
si lon avait en fait deux questions, lune avec la partie gauche et lautre avec la partie droite de la qualification (aprs mise en forme normale disjonctive).
laide de ces rgles simples, il est possible dexprimer toute question du calcul relationnel de domaines. Nous avons formul (voir figure V.5) les questions introduites
ci-dessus (Q1 Q7) sur la base des produits. Remarquez laspect naturel de ce langage par lexemple qui peut tre simplement paraphras.

(a) Noms et couleurs des produits

PRODUIT

NPRO

NOMP

QTES

P.

COULEUR
P.

(b) Noms et quantits en stock des produits rouges

PRODUIT

NPRO

NOMP

QTES

COULEUR

P.

P.

Rouge

Logique et bases de donnes 161

(c) Noms des produits et des fournisseurs associs

PRODUIT

ACHAT

NPRO

NOMP

100

P.

NACH

DATE

QTES

NPRA

COULEUR

QTEA

NOMF

100

P.

(d) Noms des fournisseurs vendant tous les produits

PRODUIT

NPRO

NOMP

QTES

COULEUR

ALL.100

ACHAT

NACH

DATE

NPRA

QTEA

NOMF

100

P.

(e) Descriptifs des produits rouge ou vert en stock

en plus de 1 000 units
PRODUIT

NPRO

P.

NOMP

QTES

COULEUR

> 1000

boite condition
COULEUR = "Rouge" OR COULEUR = "Verte"

Figure V.5 : Exemples de questions QBE

162 BASES DE DONNES : OBJET ET RELATIONNEL

QBE offre quelques possibilits supplmentaires par rapport au calcul de domaines.

En particulier, il est possible denlever llimination automatique des doubles lors des
projections finales en spcifiant le mot cl ALL devant une variable rsultat imprimer. Par exemple, ldition de tous les noms des clients qui lon a vendu des produits (sans limination des doubles) sera effectue en rponse la question reprsente figure V.6.

Noms des clients sans double

VENTE

NVEN

NOMC

NPRV

QTEV

DATE

P.ALL.Cx

Figure V.6 : Non-limination des doubles en QBE

Il est galement possible dobtenir des rsultats tris par ordre croissant (mot cl AO.)
ou dcroissant (mot cl DO.). Par exemple, ldition des noms de produits en stock en
quantit suprieure 100 par ordre alphabtique descendant sera obtenue par excution de la question reprsente figure V.7.
Noms des produits en stock en quatit suprieure 100
tris par ordre dcroissant.
PRODUIT

NPRO

NOMP

QTES

COULEUR

P.DO.Px > 100

Figure V.7 : Exemple de question avec rsultats tris

De plus, QBE offre des facilits pour accomplir les oprations de type fermeture transitive de graphe. Le calcul de la fermeture transitive est impossible avec les langages
bass sur le calcul de prdicats. Soit par exemple la relation reprsente figure V.8.
Tout composant peut aussi tre un compos. Si lon veut rechercher les composants de
voiture au deuxime niveau, il est possible avec QBE dutiliser la question reprsente figure V.9.

Logique et bases de donnes 163

NOMENCLATURE

COMPOSE

COMPOSANT

Voiture

Porte

Voiture

Chassis

Voiture

Moteur

Moteur

Piston

Moteur

Bielle

Moteur

Chemise

Piston

Axe

Piston

Segment

Figure V.8 : Table compos-composant

NOMENCLATURE

COMPOSE

COMPOSANT

Voiture

Cx

Cx

P. Cy

Figure V.9 : Recherche des composants de second niveau

Pour rechercher les composants de niveau n partir dun composant (ou les composs
de niveau n partir dun compos), il faut une question n lignes. Ceci peut tre fastidieux. Afin de simplifier, QBE autorise le mot cl L entre parenthses prcd dun
nombre de niveaux (par exemple (2L)). Ainsi, la question prcdente pourra aussi tre
formule comme sur la figure V.10.

NOMENCLATURE

COMPOSE

COMPOSANT

Voiture

P. Cy (2 L)

Figure V.10 : Autre manire de rechercher les composants de second niveau

La fermeture transitive du compos VOITURE consiste rechercher les composants

de tout niveau. Ceci est effectu en fixant un niveau variable, comme reprsent

164 BASES DE DONNES : OBJET ET RELATIONNEL

figure V.11. Une telle question nest pas exprimable laide du calcul relationnel de
domaines, mais ncessite la rcursion que nous tudierons dans le cadre des BD
dductives. Il est aussi possible dobtenir les composants de dernier niveau laide du
mot cl LAST.

NOMENCLATURE

COMPOSE

COMPOSANT

Voiture

P. Cy (2 L)

Figure V.11 : Fermeture transitive du compos VOITURE

Finalement, QBE dispose galement des fonctions dagrgats qui dpassent la logique
du premier ordre. Les fonctions CNT (dcompte), SUM (somme), AVG (moyenne),
MAX (maximum) et MIN (minimum) permettent de faire des calculs sur plusieurs
valeurs de variables, celles-ci tant slectionnes par des critres exprims par une
question. Ces fonctions peuvent tre appliques toute variable rsultat condition
quelle soit prcde de ALL. Si lon dsire liminer les doubles avant application de
la fonction, il faut appliquer avant loprateur unique (mot cl UNQ). Par exemple, si
lon veut connatre la quantit en stock des produits de nom Vins on crira la
question reprsente figure V.12.

Somme des quantits de vins en stock

PRODUIT NPRO NOMP

QTES

COULEUR

"Vins" P.SUM.ALL.Q

Figure V.12 : Utilisation de la fonction SUM

QBE permet aussi la mise jour des prdicats extensionnels, cest--dire des tables. Il
est possible :
dinsrer des n-uplets dans une relation (oprateur I. en premire colonne) ; la
figure V.13 illustre linsertion du produit de cl 200 ;

Logique et bases de donnes 165

de modifier des attributs de n-uplet (oprateur U. en premire colonne) ; la

figure V.14 illustre la mise jour des quantits en stock pour les produits de couleur
rouge ;
de supprimer les n-uplets dans une relation obissant un critre de slection donn
(oprateur D. en premire colonne) ; la figure V.15 illustre la suppression des
produits rouges de la relation produit.

Insertion du tuple 200 dans la relation Produit

PRODUIT
I.

NPRO

NOMP

QTES

COULEUR

200

"Balais"

100

"Bleu"

Figure V.13 : Insertion du tuple de cl 200

Incrment de 100 des quantits en stock

de produits rouges
PRODUIT
U.

NPRO

NOMP

200
200

QTES

COULEUR

10
10 + 100

"Rouge"

Figure V.14 : Mise jour des quantits en stock des produits rouges

Suppression des produits rouges

PRODUIT
S.

NPRO

NOMP

QTES

COULEUR
"Rouge"

Figure V.15 : Suppression des produits rouges

166 BASES DE DONNES : OBJET ET RELATIONNEL

QBE permet enfin une dfinition trs dynamique de la base de donnes. Il est
possible de crer et dtruire des prdicats extensionnels (tables). De plus, il est
permis dtendre un prdicat en ajoutant des attributs. QBE est donc un langage
trs souple et complet, issu de la logique du premier ordre applique aux tables relationnelles.

5. LE CALCUL DE TUPLES
Le calcul relationnel de tuples [Codd72] se dduit de la logique du premier ordre.
Comme le calcul de domaine, le calcul de tuples permet dexprimer une question
comme une formule. Cette fois, les constantes sont interprtes comme les n-uplets de
la base. Les variables parcourent donc les lignes des tables. Afin de distinguer les
deux calculs, nous noterons les variables tuples par des majuscules X, Y, Z Il est
dailleurs possibles de mixer calcul de domaines et calcul de tuples en utilisant la
fois des variables tuples et des variables domaines [Reiter84].

5.1. PRINCIPES DU CALCUL DE TUPLE

Les seuls termes considrs sont les constantes associes aux n-uplets composant les
faits et les fonctions gnratrices des attributs notes par le nom de lattribut appliqu
une variable par la notation pointe (par exemple X.COULEUR). Les prdicats utiliss sont ceux correspondant aux relations extensionnelles ainsi que les prdicats de
comparaison {=, <, , , >, }. Les prdicats extensionnels permettent la dfinition de
la porte dune variable sur une table R par une formule atomique du type R (X), X
tant donc une variable tuple et R une table.
Llment essentiel diffrenciant le calcul de tuples par rapport aux calculs
de domaines est bien sr lassociation aux variables de tuples des extensions de
prdicats et non plus de valeurs de domaines, comme avec le calcul de domaine.
Cela change lgrement la syntaxe du calcul. Nous dfinissons plus prcisment le calcul de tuples ci-dessous. La syntaxe du calcul est dfinie en BNF
figure V.16.
Notion V.9 : Calcul relationnel de tuples (Tuple relational calculus)
Langage dinterrogation de donnes formel permettant dexprimer des questions partir de formules bien formes dont les variables sont interprtes comme variant sur les tuples dune table.

Logique et bases de donnes 167

<question> : := { (<rsultat>) | <formule> }

<rsultat> : := <variable>.<attribut> | <rsultat>, <rsultat>
<formule> : := <quantification> <formule libre> | <formule libre>
<quantification> ::= <variable> | <variable>
| <quantification> <quantification>
<formule libre> : := <formule atomique>
| <formule libre> <formule atomique>
| <formule libre> <formule atomique>
| <formule libre> <formule libre>
| <formule libre>
| (<formule libre>)
<formule atomique> : := <predicat extensionnel> (<variable>)
| <terme> <comparateur> <terme>
<terme> : := <variable>.<attribut> | <constante>
<comparateur> : := = | < | | > | |

Figure V.16 : BNF du calcul relationnel de tuples

5.2. QUELQUES EXEMPLES DE CALCUL DE TUPLE

Nous exprimons maintenant en calcul relationnel de tuples les questions exprimes cidessus en calcul de domaines sur la base des produits.
(Q1) Donner la liste des noms et des couleurs de tous les produits :
{(P.NOMP, P.COULEUR) | PRODUIT(P)}
(Q2) Donner les noms et les quantits en stock des produits de couleur rouge :
{(P.NOMP, P.QTES) | PRODUIT(P) P.COULEUR = ROUGE}
(Q3) Donner pour chaque produit en stock, le nom du fournisseur associ :
{(P.NOMP, A.NOMF) | PRODUIT(P) ACHAT(A) P.NPRO=A.NPRA}
(Q4) Donner, pour chaque produit en stock en quantit suprieure 100 et de couleur
rouge, les couples nom de fournisseurs ayant vendu ce type de produit et nom
de client ayant achet ce type de produit, avec le nom du produit :
{(P.NOMP, A.NOMF, V.NOMC) | PRODUIT(P) ACHAT(A) VENTE(V)
P.QTES > 100 P.COULEUR = Rouge P.NPRO = V.NPRV
P.NPRO = A.NPRA}
(Q5) Donner les noms des clients ayant achet au moins un produit de couleur verte :
{(V.NOMC) | VENTE (V) P (PRODUIT (P) V.NPRV = P.NPRO
P.COULEUR = Verte)}
(Q6) Donner les noms des clients ayant achet tous les produits stocks :
{(V1.NOMC) | VENTE (V1) P (PRODUIT (P) (V2 (VENTE(V2)
V2.NPRV = P.NPRO V2.NOMC = V1.NOMC)))}

168 BASES DE DONNES : OBJET ET RELATIONNEL

(Q7) Donner les noms des produits fournis par tous les fournisseurs et achets par au
moins un client :
{(P.NOMP) | PRODUIT(P) (A1 (ACHAT(A1) (A2 (ACHAT(A2)
A2.NOMF = A1.NOMF A2.NPRA = P.NPRO)))
(V (VENTE(V) V.NPRV = P.NPRO))}
Les questions (Q6) et (Q7) dmontrent la difficult dutilisation des quantificateurs
quel-que-soit et il existe . En gnral, toute variable apparaissant dans la
rponse doit tre libre dans la condition. Les il existe ne sont utiles qu lintrieur
des quantifications universelles.

6. LES TECHNIQUES DINFRENCE

La logique permet la dduction. La dduction, principe de lintelligence, permet de
prouver des thormes partir daxiomes. Les systmes de bases de donnes dductifs sont fonds sur linfrence. Dans cette section, nous rappelons les principes fondamentaux des techniques de dduction. Ces rsultats sont supposs connus lors de
ltude des bases de donnes dductives, dans la quatrime partie de cet ouvrage.

6.1. PRINCIPE DUN ALGORITHME DE DDUCTION

Un algorithme de dduction est une procdure pour prouver une formule T partir
dun ensemble de formules {A1, A2An} connues comme vraies. T est le thorme
dmontrer. A1, A2An sont les axiomes. Lexistence dune preuve de T partir de
A1, A2An est formellement note {A1,A2An} |== T.
Notion V.10 : Dduction (Deduction)
Procdure permettant de prouver un thorme partir dun ensemble daxiomes connus comme
vrais sur tout domaine de discours considr.

Par exemple, partir des axiomes :

DIRIGE(pierre, marie)
DIRIGE(marie, julie)
x y z (DIRIGE(x,y) DIRIGE(y,z) DIRIGE(x,z))
on aimerait dduire le thorme:
DIRIGE(pierre, julie).
Pour prouver un thorme, un algorithme de dduction drive partir des axiomes
une squence de formules dont le thorme est la dernire en utilisant des rgles

Logique et bases de donnes 169

dinfrence. Une rgle dinfrence est une rgle permettant de gnrer une formule
partir de deux ou plus. Une rgle dinfrence correcte permet de gnrer une formule
valide (vraie sur les univers de discours considrs) partir de formules valides.
Deux rgles dinfrences bien connues sont :
Le modus ponens. Il permet de gnrer P partir des deux formules F et F P.
Intuitivement, cela signifie que si F et F implique P sont prouves, alors P est prouve. On crit formellement :
F
FP
P
La spcialisation. Elle permet de gnrer F(a) partir de la formule xF(x).
Intuitivement, cela signifie que si F(x) est prouve pour toute valeur de x, alors F(a)
est prouve. On crit formellement :
x F(x)
F(a)
Il existe une rgle dinfrence gnrale pour les formules du premier ordre en forme
clausale. Cette rgle gnre par application rcursive toutes les formules qui peuvent
tre dduites partir de deux axiomes sous forme de clauses. Il sagit de la rgle
dinfrence de Robinson [Robinson65]. Elle sappuie sur lalgorithme dunification qui permet de comparer deux formules atomiques.

6.2. ALGORITHME DUNIFICATION

La capacit dcider si deux formules atomiques peuvent tre identifies par substitution de paramtres est centrale la plupart des mthodes de dduction. Une unification de deux formules atomiques consiste les rendre identiques par remplacement de
variables dans une formule par des termes de lautre.
Notion V.11 : Unification (Unification)
Remplacement de variables dans une formule atomique par des termes (constantes, autres
variables, fonctions appliques des constantes ou des variables) de manire la rendre identique
une autre formule atomique.

Deux formules atomiques L1(t1,t2tn) et L2(s1,s2sn) ne sont pas toujours unifiables. Un algorithme dunification dcide si les deux formules peuvent tre identifies par une substitution de variable valide (renommage ou assignation de valeur).
Un tel algorithme (voir figure V.17) retourne :
SUCCES et une substitution de variable minimale si les deux formules peuvent tre
identifies en appliquant la substitution ;

170 BASES DE DONNES : OBJET ET RELATIONNEL

ECHEC sil est impossible de les rendre identiques par une substitution de terme
unique chaque variable.
Lalgorithme est rcursif : il exploite les termes partir du dbut en unifiant tte et
queue successivement. Il existe beaucoup dalgorithmes dunification, celui-l nest
quindicatif.
Quelques exemples simples permettent dillustrer lalgorithme. On note {x/t1; y/t2; }
la substitution qui remplace x par t1, y par t2, etc. Les formules DIRIGE(pierre,marie) et
DIRIGE(x,y) sont simplement unifiables par la substitution {x/pierre; y/marie}. Les formules DIRIGE(chef(x),pierre) et DIRIGE(chef(chef(pierre)),y) sont unifiables par la
substitution {x/chef(pierre); y/pierre}. Les formules DIRIGE(chef(x),x) et
DIRIGE(chef(chef(x)),x) ne sont pas unifiables: il faudrait que x devienne la fois
chef(x) et x, ce qui est syntaxiquement impossible.
Bool Function Unifier(L1, L2, S) {; // Unification de L1 et L2
S := ; // S est la substitution rsultat en cas de succs
Si (L1 est un atome) alors {// unification datome
Si L1 = L2 alors Retour(Succs)
Si L1 est une variable alors
Si L1 L2 alors Retour(Echec)
Sinon {S : = S [L1/L2]
Retour(Succs) } ;
Si (L2 est un atome) alors { idem avec L2} ;
M1 = Elment suivant (L1) ; // prendre lments suivants
M2 = Elment suivant (L2) ;
Suite1 = unifier(M1, M2, S1) ; // tenter unification
Si (Suite1 = Echec) alors Retour(Echec) ;
N1 = [Reste(L1)/S1)] ; // substituer si succs
N2 = [Reste(L1)/S1)] ;
Suite2 = unifier(N1, N2, S2) ; // unifier le reste
Si (Suite2 = Echec) alors Retour(Echec) ;
S = S1 S2 ; // composer les substitutions
Retour(Succs) ;}

Figure V.17 : Un algorithme dunification

6.3. MTHODE DE RSOLUTION

La mthode de rsolution est trs simplement base sur la rgle dinfrence de
Robinson. Cette rgle snonce comme suit. Soient C1 et C2 deux clauses de la
forme :
C1 = F1 L1
C2 = L2 F2.

Logique et bases de donnes 171

De plus, moyennant une substitution s, L1 et L2 sont unifiables (on note

L1[s] = L2[s]). La rgle de Robinson permet dinfrer la clause F1[s] F2[s] ; cette
nouvelle clause obtenue par disjonction de F1 et F2 et application de la substitution s
est appele rsolvant de C1 et C2. Formellement, la rgle de Robinson scrit :
F1 F(x) L2 F2 L1[s] = L2[s]
F1[s] F2 [s]

En remarquant que L2 F2 peut aussi scrire L2 F2, puis en remplaant le

ou par + et la ngation par , on obtient :
F1 + L1 F2 L2 L1[s] = L2[s]
F1[s] + F2 [s]
On voit alors que la rgle de Robinson permet finalement de raliser laddition de
clauses avec suppression des parties sannulant moyennant une substitution s. Il sagit
de la rgle de base du calcul symbolique. Elle a une proprit remarquable de compltude : toute formule pouvant tre dmontre partir dun ensemble daxiomes se
dduit par applications successives de la rgle de Robinson aux axiomes et aux rsolvants obtenus.
partir de cette rgle dinfrence est construite la mthode de rsolution. Cette
mthode permet de prouver un thorme partir daxiomes non contradictoires. Cest
une mthode par labsurde qui consiste partir des axiomes et de la ngation du thorme et prouver quil y a contradiction. Donc, sous lhypothse de non-contradiction
des axiomes, cest que le thorme est valide (car son contraire contredit les axiomes).
En rsum, la mthode procde comme suit :
1. Mettre les axiomes et la ngation du thorme (T) sous forme de clauses.
2. Ajouter rcursivement les rsolvants que lon peut obtenir en appliquant la rgle
dinfrence de Robinson lensemble des clauses jusqu obtention de la clause
vide.
La clause vide (tout sest annul) ne peut jamais tre satisfaite (son modle est vide) ;
par suite, cest que les axiomes contredisent la ngation du thorme. Donc celui-ci
est dmontr. Il a t dmontr que si une preuve du thorme existe, la mthode de
rsolution se termine et la trouve. Si aucune preuve nexiste, la mthode peut se
perdre dans des univers infinis et boucler (de plus en plus de clauses sont gnres).
La logique du premier ordre est semi-dcidable. Pour un approfondissement de cette
mthode, consultez [Manna85].
Nous nous contenterons dillustrer la mthode par un arbre de preuve (figure V.18).
Soit prouver le thorme DIRIGE(pierre, julie) partir des axiomes non contradictoires :
(A1) DIRIGE(pierre, marie),
(A2) DIRIGE(marie, julie),

172 BASES DE DONNES : OBJET ET RELATIONNEL

(3) x y z (DIRIGE(x,y) DIRIGE(y,z) DIRIGE(x,z)).

La ngation du thorme est DIRIGE(pierre,julie). Les deux premiers sont des
clauses. Le troisime se met simplement sous la forme de la clause :
(A3) DIRIGE(x,y) DIRIGE(y,z) DIRIGE(x,z)
qui scrit encore :
(A3) DIRIGE(x,y) DIRIGE(y,z) DIRIGE(x,z).
Larbre de preuve (encore appel arbre de rfutation) reprsent figure V.18 montre
des unifications et additions successives de clauses qui conduisent la clause vide. Il
permet donc par applications successives de la rgle dinfrence de Robinson (chaque
nud R non initial drive de deux nuds prcdents N1 et N2) de tirer le rsolvant
vide et ainsi de dmontrer que Pierre dirige Julie.
DIRIGE(x,y)

DIRIGE(y,z) DIRIGE(x,z).

DIRIGE(marie,z)

DIRIGE(pierre,z)

DIRIGE(pierre,julie)

DIRIGE(pierre, marie)

DIRIGE(marie, julie)

DIRIGE(pierre,julie)

Figure V.18 : Exemple darbre de preuve

7. CONCLUSION
Nous avons dans ce chapitre rappel les concepts de base de la logique du premier
ordre. Une base de donnes peut tre vue comme linterprtation dun langage
logique. Cette vision est limite et nous irons beaucoup plus loin avec les bases de
donnes dductives, traites dans la 4e partie de cet ouvrage.

Logique et bases de donnes 173

Quoi quil en soit, la logique constitue une bonne base pour comprendre les bases de
donnes, en particulier les BD relationnelles. Une BD relationnelle est un ensemble de
tables donnant les extensions valides des prdicats. Le calcul de tuples et le calcul de
domaines sont des formalisations logiques des langages dinterrogation des bases de
donnes relationnelles. Nous allons tudier le modle relationnel indpendamment de
la logique dans la partie qui suit, mais il ne faut pas perdre de vue que la logique est
son fondement.

8. BIBLIOGRAPHIE
[Ceri91] Ceri S., Gottlob G., Tanca L., Logic Programming and Databases, Surveys
in Computer Sciences, Springer Verlag, 1990.
Un livre fondamental sur le modle logique. Le livre introduit Prolog comme un
langage dinterrogation de donnes, les bases de donnes relationnelles vues
dun point de vue logique, et enfin les couplages de Prolog et des bases de donnes. Dans une deuxime partie, Datalog et ses fondements sont prsents. La
troisime partie est consacre aux techniques doptimisation de Datalog et un
survol des prototypes implmentant ces techniques.
[Clark78] Clark C. Negation as failure in Logic and databases, dit par Gallaire
et Minker, Plenum Press, New York, 1978.
Un article de base sur la ngation en programmation logique. Il est propos
daffirmer quun fait est faux sil ne peut tre dmontr vrai (ngation par
chec). Cela conduit interprter les rgles comme des quivalences : si
peut tre lu comme si et seulement si condition de collecter toutes les
rgles menant un mme but en une seule.
[Clocksin81] Clocksin W.F., Mellish C.S., Programming in Prolog, Springer Verlag,
Berlin-Heidelberg-New York, 1981.
Un livre de base sur le langage Prolog. Prolog utilise des bases de faits en
mmoire qui sont similaires aux bases logiques dcrites dans ce chapitre. En
plus, Prolog gre la dduction.
[Codd72] Codd E.F., Relational Completness of Data Base Sublanguages , In Data
Base Systems, Courant Computer Science Symposia Series, n 6, Prentice-Hall,
1972.
Cet article introduit la notion de compltude pour un langage dinterrogation
de bases de donnes relationnelles. Il donne la dfinition du calcul relationnel
de tuple et de lalgbre relationnelle. Il dmontre que lalgbre est aussi puissante que le calcul en donnant un algorithme de traduction de calcul en

174 BASES DE DONNES : OBJET ET RELATIONNEL

algbre. Codd argumente aussi sur les avantages du calcul comme base dun
langage utilisateur.
[Gallaire78] Gallaire H., Minker J., Logic and Databases, Plenum Press, 1978.
Le premier livre de base sur la logique et les bases de donnes. Ce livre est une
collection darticles prsents Toulouse lors dun workshop tenu en 1977
sur le sujet.
[Gallaire81] Gallaire H., Minker J., Nicolas J.M., Advances in database theory, vol. 1,
Plenum Press, 1981.
Le second livre de base sur la logique et les bases de donnes. Ce livre est une
collection darticles prsents Toulouse lors dun workshop tenu en 1979
sur le sujet.
[Gallaire84] Gallaire H., Minker J., Nicolas J.M., Logic and databases: a deductive
approach , ACM Computing Surveys, vol. 16, n 2, juin 1984.
Un article de synthse sur les bases de donnes et la logique. Diffrents types
de clauses (fait positif ou ngatif, contrainte dintgrit, loi dductive) sont isols. Linterprtation des bases de donnes comme un modle ou comme une
thorie de la logique est discute. Les diffrentes variantes de lhypothse du
monde ferm sont rsumes.
[Lloyd87] Lloyd J., Foundations of logic programming, 2e dition, Springer Verlag
Ed., 1987.
Le livre de base sur les fondements de la programmation logique. Les diffrentes smantiques dun programme logique sont introduites. Les techniques de
preuve de type rsolution avec ngation par chec sont dveloppes.
[Manna85] Manna Z., Waldinger R., The Logical Basis for Computer Programming,
vol. 1, 618 pages, Addison-Wesley, 1985.
Le livre de base sur la logique. La syntaxe, la smantique et les mthodes de
preuves pour la logique du premier ordre sont dveloppes. La logique du
deuxime ordre, o des variables peuvent reprsenter des prdicats, est aussi
tudie.
[Merrett84] Merrett T.H., Relational Information Systems, Prentice Hall, 1984, chapitre 5.
Un bon livre trs synthtique sur les bases de donnes, avec de nombreux
exemples pratiques. La relation composant-compos (et plus gnralement
lapplication Facture de Matriel Bill of Material ) est introduite.
[Nilsson80] Nilsson N., Principles of Artificial Intelligence, Tioga Publication, 1980.
Un des livres de base de lintelligence artificielle. Les systmes de rgles de
production pertinents aux bases de donnes dductives sont particulirement
dvelopps.

Logique et bases de donnes 175

[Reiter78] Reiter R., On closed world data bases , in Logic and databases, dit
par Gallaire et Minker, Plenum Press, New York, 1978.
Larticle de base sur lhypothse du monde ferm.
[Reiter84] Reiter R., Towards a Logical Reconstruction of Relational Database
Theory , in On Conceptual Modelling, p. 191-234, Springer-Verlag Ed., 1984.
Une redfinition des bases de donnes relationnelles en logique. Les diffrents
axiomes ncessaires linterprtation dune base de donnes comme une thorie en logique sont prsents: fermeture des domaines, unicit des noms,
axiomes dgalit, etc. Les calculs relationnels sont unifis et gnraliss.
[Robinson65] Robinson J.A., A Machine oriented Logic based on the Resolution
Principle , Journal of the ACM, 12, 1965.
Larticle introduisant la mthode de rsolution.
[Ullman88] Ullman J.D., Principles of Database and Knowledge-base Systems, vol. I
et II, Computer Science Press, 1988.
Deux volumes trs complets sur les bases de donnes, avec une approche plutt
fondamentale. Jeffrey Ullman dtaille tous les aspects des bases de donnes,
depuis les mthodes daccs jusquaux modles objets en passant par le modle
logique. Les livres sont trs centrs sur une approche par la logique des bases
de donnes. Les calculs de tuples et domaines, les principaux algorithmes
daccs, doptimisation de requtes, de concurrence, de normalisation, etc. sont
dtaills.
[Zloof77] Zloof M., Query-by-Example: A Data Base Language , IBM Systems
Journal, vol. 16, n 4, 1977, p. 324-343.
Cet article prsente QBE, le langage par grille driv du calcul de domaines
propos par Zloof, alors chercheur IBM. Ce langage bi-dimensionnel est
aujourdhui oprationnel en sur-couche de DB2 et aussi comme interface
externe du systme Paradox de Borland. Zloof discute aussi des extensions
bureautiques possibles, par exemple pour grer le courrier (OBE).

Partie 2

LE RELATIONNEL

VI Le modle relationnel (The relational model)

VII Le langage SQL2 (The SQL2 language)
VIII Intgrit et BD actives (Integrity and Triggers)
IX La gestion des vues (View management)
X Loptimisation de questions (Query optimization)

Chapitre VI

LE MODLE RELATIONNEL
1. INTRODUCTION :
LES OBJECTIFS DU MODLE
Le modle relationnel a t introduit par E. F. Codd [Codd70], qui travaillait au
fameux centre de recherche dIBM San-Jos et sopposait au dveloppement du
modle DIAM, un modle utilisant des entits lies par de multiples pointeurs. La
premire volont du modle relationnel fut dtre un modle ensembliste simple, supportant des ensembles denregistrements aussi bien au niveau de la description que de
la manipulation. Les premires ides dun modle ensembliste avaient t proposes
un peu avant, notamment dans [Childs68]. Le modle relationnel est aujourdhui la
base de nombreux systmes, et les architectures permettant daccder depuis une station de travail des serveurs de donnes sappuient en gnral sur lui. Le relationnel a
donc atteint ses objectifs au-del de toute esprance.
Les premiers objectifs du modle ont t formuls par E. F. Codd [Codd70] comme suit :
1. Permettre un haut degr dindpendance des programmes dapplications et des activits interactives la reprsentation interne des donnes, en particulier aux choix
des ordres dimplantation des donnes dans les fichiers, des index et plus gnralement des chemins daccs.
2. Fournir une base solide pour traiter les problmes de cohrence et de redondance
des donnes.

180 BASES DE DONNES : OBJET ET RELATIONNEL

Ces deux objectifs, qui ntaient pas atteints par les modles rseau et hirarchique,
ont t pleinement satisfaits par le modle relationnel, dune part grce la simplicit
des vues relationnelles qui permettent de percevoir les donnes sous forme de tables
deux dimensions, et dautre part grce aux rgles dintgrit supportes par le modle
et ses fondements logiques.
En addition aux objectifs fixs par E. F. Codd, le modle relationnel a atteint un troisime objectif :
3. Permettre le dveloppement de langages de manipulation de donnes non procduraux bass sur des thories solides.
Ce troisime objectif est atteint dune part laide de lalgbre relationnelle qui permet de manipuler des donnes de manire trs simple et formelle comme les oprateurs arithmtiques permettent de manipuler des entiers , et dautre part laide des
langages assertionnels bass sur la logique qui permettent de spcifier les donnes que
lon souhaite obtenir sans dire comment les obtenir.
Finalement, le modle relationnel a atteint deux autres objectifs non prvus initialement :
4. tre un modle extensible permettant de modliser et de manipuler simplement des
donnes tabulaires, mais pouvant tre tendu pour modliser et manipuler des donnes complexes.
5. Devenir un standard pour la description et la manipulation des bases de donnes.
Lobjectif 4 est trs important, car il a permis dintgrer de nouveaux concepts au
modle relationnel, notamment la plupart des concepts de lorient objets que nous
tudierons dans la troisime partie de cet ouvrage. Les premiers travaux de recherche
dans ce sens ont t effectus par Codd lui-mme [Codd79], puis poursuivis Bell
Laboratories [Zaniolo83], Berkeley [Stonebraker87] et, en France, lINRIA
[Gardarin89].
Lobjectif 5 a t ralis en particulier grce IBM : le modle relationnel et son langage SQL ont t normaliss au niveau international en 1986 [ISO89]. Nous ferons un
point sur le langage SQL et sa standardisation dans le chapitre suivant.
Dans ce chapitre, nous allons tout dabord prsenter les concepts structuraux de base
du modle relationnel qui permettent de modliser les donnes sous forme de tables
deux dimensions. Nous exposerons ensuite les rgles de cohrence des relations qui
sont considrs comme partie intgrante du modle. Puis nous introduirons lalgbre
relationnelle, qui est loutil formel indispensable pour manipuler des relations. Les
nombreuses extensions de cette algbre seront galement prsentes. En conclusion,
nous dmontrerons les vastes possibilits denrichissement offertes par le modle relationnel, possibilits qui seront tudies plus en dtail au niveau des modles objets et
logiques, sujets dautres parties de ce livre.

Le modle relationnel 181

2. LES STRUCTURES DE DONNES DE BASE

2.1. DOMAINE, ATTRIBUT ET RELATION
Le modle relationnel est fond sur la thorie mathmatique bien connue des relations. Cette thorie se construit partir de la thorie des ensembles. Trois notions sont
importantes pour introduire les bases de donnes relationnelles. La premire permet
de dfinir les ensembles de dpart. Ces ensembles sont les domaines de valeurs.
Notion VI.1 : Domaine (Domain)
Ensemble de valeurs caractris par un nom.

Les domaines sont donc les ensembles dans lesquels les donnes prennent valeur.
Comme un ensemble, un domaine peut tre dfini en extension, en donnant la liste des
valeurs composantes, ou en intention, en dfinissant une proprit caractristique des
valeurs du domaine. Au dpart, les domaines ENTIER, REEL, BOOLEEN,
CARACTERES (une chane de caractres de longueur fixe ou variable) sont dfinis en
intention. partir de ces domaines, il est possible de dfinir en intention des
domaines plus spcifiques tels que MONNAIE (rel avec 2 chiffres derrire la virgule),
DATE (entier de 6 chiffres jour, mois et an), TEMPS (heure en secondes), etc. Un
domaine peut toujours tre dfini en extension, par exemple le domaine des couleurs
de vins : COULEUR-VINS = {Ros, Blanc, Rouge}.
Rappelons que le produit cartsien dun ensemble de domaines D1, D2..., Dn est
lensemble des vecteurs <v1, v2..., vn> o, pour i variant de 1 n, vi est une
valeur de Di. Par exemple, le produit cartsien des domaines COULEURVINS = {ROSE, BLANC, ROUGE} et CRUS = {VOLNAY, SANCERRE,
CHABLIS} est compos des neuf vecteurs reprsents figure VI.1.
COULEUR-VINS = {ROSE, BLANC, ROUGE}
CRUS = {VOLNAY, SANCERRE, CHABLIS}

ROSE
ROSE
ROSE
BLANC
BLANC
BLANC
ROUGE
ROUGE
ROUGE

VOLNAY
SANCERRE
CHABLIS
VOLNAY
SANCERRE
CHABLIS
VOLNAY
SANCERRE
CHABLIS

Figure VI.1 : Exemple de produit cartsien

182 BASES DE DONNES : OBJET ET RELATIONNEL

Nous pouvons maintenant introduire la notion de relation, la base du modle.

Notion VI.2 : Relation (Relation)
Sous-ensemble du produit cartsien dune liste de domaines caractris par un nom.

Sous-ensemble dun produit cartsien, une relation est compose de vecteurs. Une
reprsentation commode dune relation sous forme de table deux dimensions a t
retenue par Codd. Elle est gnralement utilise. Chaque ligne correspond un vecteur alors que chaque colonne correspond un domaine du produit cartsien
considr ; un mme domaine peut bien sr apparatre plusieurs fois. Par exemple,
partir des domaines COULEURS_VINS et CRUS, il est possible de composer la relation COULEURS_CRUS reprsente sous forme tabulaire figure VI.2.
COULEURS_CRUS

Couleur

Cru

ROSE
ROSE
BLANC
ROUGE
ROUGE
ROUGE

SANCERRE
CHABLIS
SANCERRE
VOLNAY
SANCERRE
CHABLIS

Figure VI.2 : Un premier exemple de relation

Pour pouvoir distinguer les colonnes dune relation sans utiliser un index, et ainsi
rendre leur ordre indiffrent tout en permettant plusieurs colonnes de mme domaine,
il est ncessaire dassocier un nom chaque colonne. Une colonne se distingue dun
domaine en ce quelle prend valeur dans un domaine et peut un instant donn comporter seulement certaines valeurs du domaine. Par exemple, si le domaine est
lensemble des entiers, seules quelques valeurs seront prises un instant donn, par
exemple {10, 20, 30}. Lensemble des valeurs dune colonne de relation est en gnral fini. Afin de bien distinguer domaine et colonne, on introduit la notion dattribut
comme suit :
Notion VI.3 : Attribut (attribute)
Colonne dune relation caractrise par un nom.

Le nom associ un attribut est souvent porteur de sens. Il est donc en gnral diffrent de celui du domaine qui supporte lattribut. Ainsi, la premire colonne de la relation COULEUR-CRUS pourra tre appele simplement COULEUR et la deuxime
CRU. COULEUR et CRU seront donc deux attributs de la relation COULEUR-CRUS.

Le modle relationnel 183

Les lignes dune relation correspondent des n-uplets de valeurs. Une ligne est aussi
appele tuple (du mot anglais tuple) : un tuple correspond en fait un enregistrement
dans une relation (encore appele table).
Notion VI.4 : Tuple (tuple)
Ligne dune relation correspondant un enregistrement.

La notion de relation est bien connue en mathmatiques : une relation n-aire est un
ensemble de n-uplets. Un cas particulier souvent employ est la relation binaire, qui
est un ensemble de paires ordonnes. Une relation n-aire est souvent reprsente par
un graphe entre les ensembles composants. Ainsi, la relation LOCALISATION, donnant la rgion de chaque cru et certains prix moyens des vins associs, est reprsente
par un graphe figure VI.3.
CRUS

RGION

PRIX

Sancerre

Loire

45
42

Chablis
Bourgogne
Volnay

38

Figure VI.3 : Graphe de la relation LOCALISATION

Une relation peut aussi tre reprsente sur un diagramme n dimensions dont les
coordonnes correspondent aux domaines participants. Ainsi, la relation STATISTIQUE, dattributs AGE et SALAIRE, donnant la moyenne des salaires par ge, est
reprsente figure VI.4.
Salaire
100
80
60
40
20
10
0

ge

Figure VI.4 : Diagramme reprsentant une relation binaire

184 BASES DE DONNES : OBJET ET RELATIONNEL

Une autre perception mathmatique dune relation consiste voir chaque tuple t
comme une fonction t : Ai > Di pour i = 1, 2... n qui applique donc les
attributs sur les domaines. Ainsi, une relation peut tre vue comme un ensemble fini
de fonctions. Bien sr, cet ensemble varie en fonction du temps. Tout ceci montre la
diversit des outils mathmatiques qui peuvent tre appliqus aux relations. En consquence, le modle relationnel peut apparatre comme un modle mathmatique simple
des donnes. De plus, grce la reprsentation tabulaire, il est simple apprhender
pour les non mathmaticiens.

2.2. EXTENSIONS ET INTENTIONS

Comme tous les modles de donnes, le modle relationnel permet de dcrire des donnes dont les valeurs varient en fonction du temps. Les relations varient en fonction
du temps en ce sens que des tuples sont ajouts, supprims et modifis dans une relation au cours de sa vie. Cependant, la structure dune relation caractrise par les trois
concepts de domaine, relation et attribut est un invariant pour la relation (elle ne
change pas en fonction du temps). Cette structure est capture dans le schma de la
relation.
Notion VI.5 : Schma de relation (Relation Schema)
Nom de la relation suivi de la liste des attributs et de la dfinition de leurs domaines.

Un schma de relation est not sous la forme :

R (A1 : D1, A2 : D2..., Ai : Di... An : Dn)

R est le nom de la relation, Ai les attributs et Di les domaines associs. titre

dexemple, la figure VI.5 propose deux schmas de relations : celui de la relation
LOCALISATION introduite ci-dessus et celui de la relation VINS qui reprsente des
vins caractriss par un numro, un cru, un millsime et un degr. Les domaines utiliss
sont ceux des entiers, des rels et des chanes de caractres de longueur variable (CHARVAR). La plupart du temps, lorsquon dfinit le schma dune relation, les domaines sont
implicites et dcoulent du nom de lattribut ; aussi omet-on de les prciser.

LOCALISATION (CRU : CHARVAR, REGION : CHARVAR, PRIX : FLOAT)

VINS (NV :INTEGER, CRU : CHARVAR, MILL :INTEGER, DEGRE : FLOAT)

Figure VI.5 : Schmas des relations LOCALISATION et VINS

Soulignons que le schma dune relation reprsente son intention, cest--dire les
proprits (au moins certaines) communes et invariantes des tuples quelle va contenir

Le modle relationnel 185

au cours du temps. Au contraire, une table reprsente une extension dune relation
(voir figure VI.2 par exemple), cest--dire une vue des tuples quelle contient un
instant donn. Une extension dune relation R est aussi appele instance de R.
Lintention est le rsultat de la description des donnes, alors quune extension (ou
instance) fait suite des manipulations et reprsente un tat de la base.

3. LES RGLES DINTGRIT

STRUCTURELLE
Les rgles dintgrit sont les assertions qui doivent tre vrifies par les donnes
contenues dans une base. Il est possible de distinguer les rgles structurelles qui sont
inhrentes au modle de donnes, cest--dire ncessaires sa mise en uvre, et les
rgles de comportement propres au schma particulier dune application. Le modle
relationnel impose a priori une rgle minimale qui est lunicit des cls, comme nous
allons le voir ci-dessous. Il est commode et courant [Date81] dajouter trois types de
rgles dintgrit supplmentaires afin dobtenir les rgles dintgrit structurelle supportes par le modle relationnel : les contraintes de rfrences, les contraintes
dentit et les contraintes de domaine.

3.1. UNICIT DE CL
Par dfinition, une relation est un ensemble de tuples. Un ensemble nayant pas dlment en double, il ne peut exister deux fois le mme tuple dans une relation. Afin
didentifier les tuples dune relation sans donner toutes les valeurs et dassurer simplement lunicit des tuples, la notion de cl est utilise.
Notion VI.6 : Cl (Key)
Ensemble minimal dattributs dont la connaissance des valeurs permet didentifier un tuple unique
de la relation considre.

De manire plus formelle, une cl dune relation R est un ensemble dattributs K tel
que, quels que soient les tuples t1 et t2 dune instance de R, t1(K) t2(K),
cest--dire que t1 et t2 ont des valeurs de K diffrentes. Un ensemble dattributs
contenant une cl est appele super-cl [Ullman88].
Toute relation possde au moins une cl car la connaissance de tous les attributs permet didentifier un tuple unique. Sil existe plusieurs cls, on en choisit en gnral une

186 BASES DE DONNES : OBJET ET RELATIONNEL

arbitrairement qui est appele cl primaire. Par exemple, NV peut constituer une cl
primaire pour la relation VINS. Le couple <CRU,MILLESIME> est une cl alternative.
Soulignons que la notion de cl caractrise lintention dune relation : dans toute
extension possible dune relation, il ne peut exister deux tuples ayant mme valeur
pour les attributs cls. La dtermination dune cl pour une relation ncessite donc
une rflexion sur la smantique de la relation, cest--dire sur toutes les extensions
possibles et non pas sur une extension particulire.

3.2. CONTRAINTES DE RFRENCES

Le modle relationnel est souvent utilis pour reprsenter des entits du monde rel qui
sont les objets ayant une existence propre, et des associations entre ces objets [Chen76].
Une entit correspond alors un tuple dans une relation qui comporte la fois la cl de
lentit et ses caractristiques sous forme dattributs. Une entit est identifie par la
valeur de sa cl. Un type dassociation est modlis par une relation comportant les cls
des entits participantes ainsi que les caractristiques propres lassociation.
titre dexemple, nous considrons les entits BUVEURS et VINS du monde rel : la
cl de lentit BUVEURS est le numro de buveur NB et celles de lentit VINS le
numro de vin NV. Ces entits peuvent tre associes par une consommation dun vin
par un buveur : une consommation sera par exemple modlise par une association
ABUS entre le buveur et le vin. Cette base typique et simple, qui servira souvent
dexemple, est appele DEGUSTATION. Le diagramme entit-association de cette
base est reprsent figure VI.6.

ABUS

BUVEURS

VINS

NB
NV
Degr

Nom

Cru

Type

Prnom

Adresse

Quantit

Date

Millsime

Qualit

Figure VI.6 : Diagramme entit-association de la base DEGUSTATION

Le modle relationnel 187

En relationnel, chaque entit est reprsente par une table. Une association est aussi
reprsente par une table, dont les attributs seront les cls des entits participantes,
cest--dire NB et NV, ainsi que les attributs caractrisant lassociation, par exemple
la date et la quantit bue. On aboutit ainsi au schma relationnel reprsent
figure VI.7.
BUVEURS (NB, NOM, PRENOM, ADRESSE, TYPE)
VINS (NV, CRU, MILL QUALITE, DEGRE)
ABUS (NB, NV, DATE, QUANTITE)

Figure VI.7 : Schma relationnel de la base DEGUSTATION

Lutilisation du modle relationnel pour reprsenter des entits et des associations ne

permet pas jusque-l de reprsenter le fait que lassociation entre une consommation
et un vin est obligatoire, cest--dire que tout abus doit correspondre un vin existant
dans la base. De mme, le fait que le lien entre une consommation et un buveur soit
obligatoire est perdu. Le maintient de liens obligatoires a justifi lintroduction de la
notion de contrainte rfrentielle [Date81].
Notion VI.7 : Contrainte rfrentielle (Referential constraint)
Contrainte dintgrit portant sur une relation R1, consistant imposer que la valeur dun groupe
dattributs apparaisse comme valeur de cl dans une autre relation R2.

Une telle contrainte dintgrit sapplique en gnral aux associations obligatoires :

une telle association ne peut exister que si les entits participant lassociation existent dj. Notez que dans la dfinition, R1 et R2 ne sont pas forcment distinctes :
lassociation peut en effet porter sur deux entits de mme type, par exemple entre
une personne et ses parents.
La reprsentation de contraintes de rfrence peut seffectuer par la dfinition de cls
trangres dans une relation : une cl trangre est un groupe dattributs qui doit
apparatre comme cl dans une (autre) relation. Par exemple, la relation ABUS (NB,
NV, DATE, QUANTITE) a pour cl <NB, NV, DATE> et a deux cls trangres,
NB dans BUVEURS et NV dans VINS.
Les contraintes rfrentielles dfinissent des liens obligatoires entre relations. Ce sont
des contraintes trs fortes qui conditionnent le succs des oprations de mises jour.
Lors de linsertion dun tuple dans une relation rfrenante, il faut vrifier que les
valeurs de cls trangres existent dans les relations rfrences. Par exemple, lors de
linsertion dun abus, il faut que le vins et le buveurs associs existent, sinon linsertion est refuse pour cause de violation dintgrit. Lors de la suppression dun tuple
dans une relation rfrence, il faut vrifier quaucun tuple nexiste dans chaque relation rfrenante ; sil en existe, le systme peut soit refuser la suppression, soit la

188 BASES DE DONNES : OBJET ET RELATIONNEL

rpercuter en cascade (cest--dire, supprimer les tuples rfrenants). Par exemple, la

suppression dun vin entranera la vrification quaucun abus ne rfrence ce vin. Les
contraintes dintgrit rfrentielles sont donc des liens forts qui rendent les relations
dpendantes ; en quelque sorte, elles introduisent des liens hirarchiques depuis les
relation rfrences vers les relations rfrenantes.

3.3. VALEURS NULLES ET CLS

Lors de linsertion de tuples dans une relation, il arrive frquemment quun attribut
soit inconnu ou non applicable ; par exemple, la quantit de vin bu par un buveur
une certaine date peut tre inconnue ; si un vin ne possde pas de millsime, lattribut
millsime est inapplicable ce vin. On est alors amen introduire dans la relation
une valeur conventionnelle, appele valeur nulle.
Notion VI.8 : Valeur nulle (Null value)
Valeur conventionnelle introduite dans une relation pour reprsenter une information inconnue ou
inapplicable.

La signification prcise dune valeur nulle est souvent ambigu ; le groupe

ANSI/X3/SPARC a recens quatorze significations possibles, parmi lesquelles valeur
inconnue et valeur inapplicable sont les plus caractristiques.
Tout attribut dans une relation ne peut prendre une valeur nulle ; en effet, lexistence
dune cl unique impose la connaissance de la cl afin de pouvoir vrifier que cette
valeur de cl nexiste pas dj. Ainsi, une contrainte structurelle du modle relationnel
est la contrainte dentit dfinie ci-dessous [Date81].
Notion VI.9 : Contrainte dentit (Entity constraint)
Contrainte dintgrit imposant que toute relation possde une cl primaire et que tout attribut participant cette cl primaire soit non nul.

moins quil nen soit spcifi autrement par une contrainte smantique, le modle
relationnel nimpose pas que les cls trangres qui nappartiennent pas une cl primaire soient non nulles. Cela peut permettre une certaine souplesse, par exemple
denregistrer des employs qui ne sont attachs aucun service.

3.4. CONTRAINTES DE DOMAINES

En thorie, une relation est construite partir dun ensemble de domaines. En pratique, les domaines grs par les systmes sont souvent limits aux types de base

Le modle relationnel 189

entier, rel, chane de caractres, parfois monnaie et date. Afin de spcialiser un type
de donnes pour composer un domaine plus fin (par exemple, le domaine des salaires
mensuels qui sont des rels compris entre 6 000 et 1 000 000 de francs), la notion de
contrainte de domaine est souvent ajoute aux rgles dintgrit structurelle du relationnel. Cette notion peut tre introduite comme suit :
Notion VI.10 : Contrainte de domaine (Domain constraint)
Contrainte dintgrit imposant quune colonne dune relation doit comporter des valeurs vrifiant
une assertion logique.

Lassertion logique est lappartenance une plage de valeurs ou une liste de valeurs.
Par exemple, SALAIRE 5 000 et 1 000 000, COULEUR {BLEU,
BLANC, ROUGE}, etc. Les contraintes permettent de contrler la validit des valeurs
introduites lors des insertions ou mises jour. La non-nullit dune colonne peut aussi
tre considre comme une contrainte de domaine, par exemple DEGRE IS NULL.

4. LALGBRE RELATIONNELLE :
OPRATIONS DE BASE
Lalgbre relationnelle a t invente par E. Codd comme une collection doprations
formelles qui agissent sur des relations et produisent les relations en rsultats
[Codd70]. On peut considrer que lalgbre relationnelle est aux relations ce quest
larithmtique aux entiers. Cette algbre, qui constitue un ensemble doprations lmentaires associes au modle relationnel, est sans doute une des forces essentielles
du modle. Codd a initialement introduit huit oprations, dont certaines peuvent tre
composes partir dautres. Dans cette section, nous allons introduire six oprations
qui permettent de dduire les autres et qui sont appeles ici oprations de base. Nous
introduirons ensuite quelques oprations additionnelles qui sont parfois utilises. Des
auteurs ont propos dautres oprations qui peuvent toujours se dduire des oprations
de base [Delobel83, Maier83].
Les oprations de base peuvent tre classes en deux types : les oprations ensemblistes traditionnelles (une relation tant un ensemble de tuples, elle peut tre traite
comme telle) et les oprations spcifiques. Les oprations ensemblistes sont des oprations binaires, cest--dire qu partir de deux relations elles en construisent une
troisime. Ce sont lunion, la diffrence et le produit cartsien. Les oprations spcifiques sont les oprations unaires de projection et restriction qui, partir dune relation, en construisent une autre, et lopration binaire de jointure. Nous allons dfinir
toutes ces oprations plus prcisment.

190 BASES DE DONNES : OBJET ET RELATIONNEL

4.1. LES OPRATIONS ENSEMBLISTES

4.1.1. Union
Lunion est lopration classique de la thorie des ensembles adapte aux relations de
mme schma.
Notion VI.11 : Union (Union)
Opration portant sur deux relations de mme schma RELATION1 et RELATION2 consistant
construire une relation de mme schma RELATION3 ayant pour tuples ceux appartenant RELATION1 ou RELATION2 ou aux deux relations.

Plusieurs notations ont t introduites pour cette opration, selon les auteurs :
RELATION1 RELATION2
UNION (RELATION1, RELATION2)
APPEND (RELATION1, RELATION2)
La notation graphique reprsente figure VI.8 est aussi utilise. titre dexemple,
lunion des relations VINS1 et VINS2 est reprsente figure VI.9.
RSULTAT

RELATION1

RELATION2

Figure VI.8 : Reprsentation graphique de lunion

Vins1

Cru

Mill

CHENAS 1983

Vins2

Rgion

Couleur

BEAUJOLAIS

ROUGE

TOKAY

1980

ALSACE

BLANC

TAVEL

1986

RHONE

ROSE

Cru

Mill

Rgion

Couleur

TOKAY

1980

ALSACE

CHABLIS 1985 BOURGOGNE

Vins

Cru

Mill

CHENAS 1983

BLANC
ROUGE

Rgion

Couleur

BEAUJOLAIS

ROUGE

TOKAY

1980

ALSACE

BLANC

TAVEL

1986

RHONE

CHABLIS 1985 BOURGOGNE

Figure VI.9 : Exemple dunion

ROSE
ROUGE

Le modle relationnel 191

4.1.2. Diffrence
La diffrence est galement lopration classique de la thorie des ensembles adapte
aux relations de mme schma.
Notion VI.12 : Diffrence (Difference)
Opration portant sur deux relations de mme schma RELATION1 et RELATION2, consistant
construire une relation de mme schma RELATION3 ayant pour tuples ceux appartenant RELATION1 et nappartenant pas RELATION2.

La diffrence est un oprateur non commutatif : lordre des relations oprandes est donc
important. Plusieurs notations ont t introduites pour cette opration, selon les auteurs :
RELATION1 RELATION2
DIFFERENCE (RELATION1, RELATION2)
REMOVE (RELATION1, RELATION2
MINUS (RELATION1, RELATION2)
La notation graphique reprsente figure VI.10 est aussi utilise. titre dexemple, la
diffrence des relations VINS1 VINS2 est reprsente figure VI.11.
RSULTAT

RELATION1

RELATION2

Figure VI.10 : Reprsentation graphique de la diffrence

Vins1

Cru

Mill

CHENAS 1983

Vins2

Rgion

Couleur

BEAUJOLAIS

ROUGE

TOKAY

1980

ALSACE

BLANC

TAVEL

1986

RHONE

ROSE

Cru

Mill

Rgion

Couleur

TOKAY

1980

ALSACE

BLANC

CHABLIS 1985 BOURGOGNE ROUGE

Vins

Cru

Mill

CHENAS 1983
TAVEL

1986

Rgion

Couleur

BEAUJOLAIS

ROUGE

RHONE

ROSE

Figure VI.11 : Exemple de diffrence

192 BASES DE DONNES : OBJET ET RELATIONNEL

4.1.3. Produit cartsien

Le produit cartsien est lopration ensembliste que nous avons rappele ci-dessus
pour dfinir le concept de relations. Elle est adapte aux relations. Cette fois, les deux
relations nont pas ncessit davoir mme schma.
Notion VI.13 : Produit cartsien (Cartesian product)
Opration portant sur deux relation RELATION1 et RELATION2, consistant construire une relation RELATION3 ayant pour schma la concatnation de ceux des relations oprandes et pour
tuples toutes les combinaisons des tuples des relations oprandes.

Des notations possibles pour cette opration sont :

RELATION1 X RELATION2
PRODUCT (RELATION1, RELATION2)
TIMES (RELATION1, RELATION2)
La notation graphique reprsente figure VI.12 est aussi utilise. titre dexemple, la
relation VINS reprsente figure VI.13 est le produit cartsien des deux relations
CRUS et ANNEES de la mme figure.
RSULTAT

X
RELATION1

RELATION2

Figure VI.12 : Reprsentation graphique du produit cartsien

Vins1

Cru

Rgion

Couleur

CHENAS

BEAUJOLAIS

ROUGE

TOKAY

ALSACE

BLANC

TAVEL

RHONE

ROSE

Annes

Mill
1980
1985

Vins

Cru

Rgion

Couleur

Mill

CHENAS

BEAUJOLAIS

ROUGE

1980

TOKAY

ALSACE

BLANC

1980

TAVEL

RHONE

ROSE

1980

CHENAS

BEAUJOLAIS

ROUGE

1985

TOKAY

ALSACE

BLANC

1985

TAVEL

RHONE

ROSE

1985

Figure VI.13 : Exemple de produit cartsien

Le modle relationnel 193

4.2. LES OPRATIONS SPCIFIQUES

4.2.1. Projection
La projection est une opration spcifique aux relations qui permet de supprimer des
attributs dune relation. Son nom provient du fait quelle permet de passer dune relation n-aire une relation p-aire avec p<n, donc dun espace n dimensions un
espace moins de dimensions.
Notion VI.14 : Projection (Projection)
Opration sur une relation RELATION1 consistant composer une relation RELATION2 en
enlevant la relation initiale tous les attributs non mentionns en oprandes (aussi bien au
niveau du schma que des tuples) et en liminant les tuples en double qui sont conservs une seule
fois.

Les notations suivantes sont utilises pour cette opration, en dsignant par
Attributi, Attributj... Attributm les attributs de projection :
Attributi, Attributj... Attributm (RELATION1)
RELATION1 [Attributi, Attributj... Attributm]
PROJECT (RELATION1, Attributi, Attributj... Attributm)
La notation graphique reprsente figure VI.14 est aussi utilise. Le trapze horizontal
signifie que lon rduit le nombre de colonnes de la relation : partant du nombre
reprsent par la base, on passe au nombre reprsent par lanti-base. La figure VI.15
donne un exemple de projection dune relation VINS comportant aussi lattribut
QUALITE sur les attributs MILLESIME et QUALITE.
RSULTAT

A1, A2 An

RELATION

Figure VI.14 : Reprsentation graphique de la projection

194 BASES DE DONNES : OBJET ET RELATIONNEL

VINS

cru, Rgion
(VINS)

Cru

Mill

Rgion

Qualit

VOLNAY

1983

BOURGOGNE

VOLNAY

1979

BOURGOGNE

CHENAS

1983

BEAUJOLAIS

JULIENAS

1986

BEAUJOLAIS

Cru

Rgion

VOLNAY

BOURGOGNE

CHENAS

BEAUJOLAIS

JULIENAS

BEAUJOLAIS

Figure VI.15 : Exemple de projection

4.2.2. Restriction
La restriction est aussi une opration spcifique unaire, qui produit une nouvelle relation en enlevant des tuples la relation oprande selon un critre.
Notion VI.15 : Restriction (Restriction)
Opration sur une relation RELATION1 produisant une relation RELATION2 de mme schma,
mais comportant les seuls tuples qui vrifient la condition prcise en argument.

Les conditions possibles sont du type :

<Attribut> <Oprateur> <Valeur>

o loprateur est un oprateur de comparaison choisi parmi {=,<, , , >, }.

Lattribut doit appartenir la relation sur laquelle sapplique le critre. Par exemple,
pour la relation VINS, CRU = Chablis est une condition de restriction possible. DEGRE > 12 est une autre condition possible. Il est aussi possible dutiliser
des compositions logiques de critres simples, cest--dire des et et ou de
conditions lmentaires. On pourra par exemple utilis le critre CRU = Chablis et
DEGRE > 12, ou encore le critre CRU = Chablis ou DEGRE = 12. Toute
composition de critres valides par conjonction et disjonction (des parenthses peuvent tre utilises pour prciser les priorits) est valide. Notons que les compositions
logiques peuvent aussi tre obtenues par union et intersection de relations restreintes
(voir ci-dessous).
Les notations suivantes sont utilises pour la restriction :
condition (RELATION1)
RELATION1 [Condition]
RESTRICT (RELATION1, Condition)

Le modle relationnel 195

ainsi que la notation graphique reprsente figure VI.16. Le trapze vertical signifie
que lon rduit le nombre de tuples de la relation : partant du nombre reprsent par le
ct gauche, on passe au nombre reprsent par le ct droit. La figure VI.17 reprsente la restriction dune relation VINS enrichie dun attribut QUALITE par la condition QUALITE = BONNE.
RSULTAT

Ai Valeur

RELATION

Figure VI.16 : Reprsentation graphique de la restriction

VINS

Cru

cru > 1983

Mill

Rgion

Qualit

VOLNAY

1983 BOURGOGNE

VOLNAY

1979 BOURGOGNE

CHENAS

1983

BEAUJOLAIS

JULIENAS

1986

BEAUJOLAIS

Cru

Mill

Rgion

Qualit

JULIENAS

1986

BEAUJOLAIS

VINS

Figure VI.17 : Exemple de restriction

4.2.3. Jointure
La jointure est une des oprations essentielles de lalgbre relationnelle, sans doute la
plus difficile raliser dans les systmes. La jointure permet de composer deux relations laide dun critre de jointure. Elle peut tre vue comme une extension du produit cartsien avec une condition permettant de comparer des attributs. Nous la dfinirons comme suit :
Notion VI.16 : Jointure (Join)
Opration consistant rapprocher selon une condition les tuples de deux relations RELATION1 et
RELATION2 afin de former une troisime relation RELATION3 qui contient lensemble de tous les
tuples obtenus en concatnant un tuple de RELATION1 et un tuple de RELATION2 vrifiant la
condition de rapprochement.

196 BASES DE DONNES : OBJET ET RELATIONNEL

La jointure de deux relations produit donc une troisime relation qui contient toutes
les combinaisons de tuples des deux relations initiales satisfaisant la condition spcifie. La condition doit bien sr permettre le rapprochement des deux relations, et donc
tre du type :
<Attribut1> <oprateur> <Attribut2>

o Attribut1 appartient RELATION1 et Attribut2 RELATION2. Selon le type

doprateur, on distingue :
lqui-jointure dans le cas o loprateur est =, qui est une vritable composition
de relations au sens mathmatique du terme ;
linqui-jointure dans les autres cas, cest--dire avec un des oprateurs <, ,
>, , .
Dans le cas dqui-jointure, les deux attributs gaux apparaissent chacun dans le
rsultat : il y a donc duplication dune mme valeur dans chaque tuple. Afin dliminer cette redondance, on dfinit la jointure naturelle comme suit :
Notion VI.17 : Jointure naturelle (Natural join)
Opration consistant rapprocher les tuples de deux relations RELATION1 et RELATION2 afin de
former une troisime relation RELATION3 dont les attributs sont lunion des attributs de RELATION1
et RELATION2, et dont les tuples sont obtenus en composant un tuple de RELATION1 et un tuple de
RELATION2 ayant mmes valeurs pour les attributs de mme nom.

Lopration de jointure est reprsente par lune des notations suivantes, la condition
tant simplement omise dans le cas de jointure naturelle (cest alors lgalit des attributs de mme nom) :
RELATION1
RELATION2
Condition
JOIN (RELATION1, RELATION2, Condition)
La figure VI.18 donne la reprsentation graphique de lopration de jointure ; la
figure VI.19 illustre cette opration en effectuant la jointure naturelle des deux relations VINS et LOCALISATION. Linqui-jointure de ces deux relations selon la
condition QUALITE > QUALITE MOYENNE est reprsente figure VI.20. On suppose que les qualits sont codes par ordre dcroissant A, B, C, D, E.
RSULTAT
Ai

RELATION1

Bj

RELATION2

Figure VI.18 : Reprsentation graphique de la jointure

Le modle relationnel 197

VINS

Cru

Mill

Qualit

VOLNAY

1983

VOLNAY

1979

CHABLIS

1983

JULIENAS

1986

LOCALISATION

Cru

Rgion

QualMoy

VOLNAY

BOURGOGNE

CHABLIS

BOURGOGNE

CHABLIS

CALIFORNIE

VINSREG

Cru

Mill Qualit

Rgion

QualMoy

BOURGOGNE

1979

BOURGOGNE

1983

BOURGOGNE

1983

CALIFORNIE

VOLNAY

1983

VOLNAY
CHABLIS
CHABLIS

Figure VI.19 : Jointure naturelle des relations VINS et LOCALISATION

VINS

Cru

Mill

Qualit

VOLNAY

1983

VOLNAY

1979

CHABLIS

1983

JULIENAS
Qualit QualMoy
LOCALISATION
Cru

1986

VINSNLOC

Rgion

QualMoy

VOLNAY

BOURGOGNE

CHABLIS

BOURGOGNE

CHABLIS

CALIFORNIE

Cru
VOLNAY

Rgion
CALIFORNIE

VOLNAY

Mill Qualit
Cru
1983
CHABLIS
A
1979
VOLNAY
B

BOURGOGNE

VOLNAY

1979

CHABLIS

BOURGOGNE

CHABLIS

1983

CHABLIS

CALIFORNIE

JULIENAS

1986

VOLNAY

BOURGOGNE

JULIENAS

1986

CHABLIS

BOURGOGNE

JULIENAS

1986

CHABLIS

CALIFORNIE

Figure VI.20 : Inqui-jointure des relations VINS et LOCALISATION

QualMoy
B

198 BASES DE DONNES : OBJET ET RELATIONNEL

La jointure nest pas toujours considre comme une opration de base de lalgbre
relationnelle. En effet, si lon tend la dfinition de la restriction de manire considrer des conditions multi-attributs du type <Attribut1> <Oprateur>
<Attribut2>, alors la jointure peut tre obtenue par un produit cartsien suivi
dune restriction du rsultat comme suit :
JOIN (RELATION1, RELATION2, Condition) =
RESTRICT ((RELATION1 X RELATION2), Condition)

Compte tenu de son jointure, nous avons prfr ici dfinir la jointure comme une
opration de base.

5. LALGBRE RELATIONNELLE :
OPRATIONS DRIVES
Les oprations prsentes ci-dessous sont parfois utilises pour manipuler des relations. Elles peuvent en gnral tre obtenues par combinaison des oprations prcdentes. Dans certains cas (complment, jointure externe), leur expression partir des
oprations de base ncessite la manipulation de relations constantes tuples prdfinis, telles que la relation obtenue par le produit cartsien des domaines, ou encore
celle compose dun seul tuple valeurs toutes nulles.

5.1. INTERSECTION
Lintersection est lopration classique de la thorie des ensembles adapte aux relations de mme schma.
Notion VI.18 : Intersection (Intersection)
Opration portant sur deux relations de mme schma RELATION1 et RELATION2 consistant
construire une relation de mme schma RELATION3 ayant pour tuples ceux appartenant la fois
RELATION1 et RELATION2.

Plusieurs notations ont t introduites pour cette opration selon les auteurs :
RELATION1 RELATION2
INTERSECT (RELATION1, RELATION2)
AND (RELATION1, RELATION2)
La notation graphique reprsente figure VI.21 est aussi utilise.

Le modle relationnel 199

RSULTAT

RELATION1

RELATION2

Figure VI.21 : Reprsentation graphique de lintersection

Lintersection est une opration redondante avec les oprations de base, puisquil est
possible de lobtenir partir de la diffrence laide dune des formules suivantes :
RELATION1 RELATION2 = RELATION1 (RELATION1 RELATION2)
RELATION1 RELATION2 = RELATION2 (RELATION2 RELATION1)

5.2. DIVISION
La division permet de rechercher dans une relation les sous-tuples qui sont complts
par tous ceux dune autre relation. Elle permet ainsi dlaborer la rponse des questions de la forme quel que soit x, trouver y de manire simple.
Notion VI.19 : Division (Division)
Opration consistant construire le quotient de la relation D (A1, A2... Ap, Ap+1... An)
par la relation d(Ap+1... An) comme la relation Q(A1, A2... Ap) dont les tuples sont ceux
qui concatns tout tuple de d donnent un tuple de D.

De manire plus formelle, dsignons par ai une valeur quelconque de lattribut Ai. Un
tuple est alors une suite de valeurs <a1, a2, a3...>. Utilisant ces notations, le quotient
de D par D est dfini par :
Q = {<a1, a2... ap> tel-que quel-que-soit <ap+1... an> de d,
<a1, a2... ap, ap+1..., an> appartient D}

Les notations possibles pour la division sont :

D d
DIVISION (D, d)
ainsi que la reprsentation graphique de la figure VI.22. Un exemple de division est
reprsent figure VI.23.

200 BASES DE DONNES : OBJET ET RELATIONNEL

RSULTAT

RELATION1

RELATION2

Figure VI.22 : Reprsentation graphique de la division

VINS

QUALITE

CRU

Cru

Mill

Qualit

VOLNAY

1983

VOLNAY

1979

CHABLIS

1983

CHABLIS

1979

JULIENAS

1986

Mill

Qualit

1983

1979

Cru
CHABLIS

Figure VI.23 : Exemple de division

La division peut tre obtenue partir de la diffrence, du produit cartsien et de la

projection comme suit :
D d = R1 R2 avec
R1 = A1, A2... Ap(D)
R2 = A1, A2... Ap ((R1 X d) D)

5.3. COMPLMENT
Le complment permet de trouver les tuples qui nappartiennent pas une relation. Il
suppose a priori que les domaines sont finis (sinon on obtient des relations infinies).

Le modle relationnel 201

Notion VI.20 : Complment (Complement)

Ensemble des tuples du produit cartsien des domaines des attributs dune relation nappartenant
pas cette relation.

Le complment dune relation RELATION1 est not au choix :

RELATION1
NOT(RELATION1)
COMP(RELATION1)
La figure VI.24 illustre cette opration dans un cas simple. Cest une opration peu utilise du fait quelle permet de gnrer des tuples qui ne sont pas dans la base, en gnral
trs nombreux. Si lon note par X Di le produit cartsien des domaines, le complment
dune relation RELATION1 est obtenu partir de la diffrence comme suit :
NOT (RELATION1) = X Di RELATION1
Domaines :
CRU = { Chablis, Volnay, Mdoc}
COULEUR = {Rouge, Ros, Blanc}
COUL_CRU

Cru
CHABLIS

Couleur
ROUGE

CHABLIS

ROS

VOLNAY

ROUGE

MDOC

ROS

MDOC

BLANC

NOT(COUL_CRU)

Cru
CHABLIS

Couleur
BLANC

VOLNAY

ROS

VOLNAY

BLANC

MDOC

ROUGE

Figure VI.24 : Exemple de complment

5.4. CLATEMENT
Lclatement [Fagin80] est une opration qui nappartient pas vraiment lalgbre
rationnelle puisquelle donne deux relations en rsultats, partir dune. Elle est cepen-

202 BASES DE DONNES : OBJET ET RELATIONNEL

dant utile pour partitionner une relation horizontalement en deux sous-relations. ce

titre, elle est considre comme une extension de lalgbre.
Notion VI.21 : clatement (Split)
Opration consistant crer deux relations partir dune relation RELATION1 et dune condition,
la premire contenant les tuples de RELATION1 et la deuxime ceux ne la vrifiant pas.

Cet oprateur appliqu la relation RELATION1 gnre donc deux relations R1 et R2

qui seraient obtenues par restriction comme suit :
R1 = RESTRICT (RELATION1, Condition)
R2 = RESTRICT (RELATION1, Condition)

5.5. JOINTURE EXTERNE

Les jointures dfinies ci-dessus perdent des tuples dau moins une relation quand les
relations jointes nont pas de projections identiques sur lattribut de jointure. Pour prserver toutes les informations dans tous les cas, il est ncessaire de dfinir des jointures qui conservent les tuples sans correspondant avec des valeurs nulles associes
quand ncessaire. Cest dans ce but que Codd [Codd79] a introduit les jointures
externes.
Notion VI.22 : Jointure externe (External Join)
Opration gnrant une relation RELATION3 partir de deux relations RELATION1 et RELATION2, par jointure de ces deux relations et ajout des tuples de RELATION1 et RELATION2 ne
participant pas la jointure, avec des valeurs nulles pour les attributs de lautre relation.

Cette opration est trs utile, en particulier pour composer des vues sans perte dinformations. Elle se note en gnral comme suit :
RELATION1
RELATION2
EXT-JOIN (RELATION1, RELATION2)
La jointure externe permet par exemple de joindre des tables CLIENTS et COMMANDES sur un numro de client commun, en gardant les clients sans commande et
les commandes sans client associ. Elle est donc trs utile en pratique. On peut aussi
distinguer la jointure externe droite qui garde seulement les tuples sans correspondant
de la relation de droite. On notera celle-ci
ou REXT-JOIN. De mme, on peut
distinguer la jointure externe gauche (
ou LEXT-JOIN). Un exemple de jointure
externe complte apparat figure VI.25.

Le modle relationnel 203

VINS

LOCALISATION

VINSREG

Cru

Mill

Qualit

VOLNAY

1983

VOLNAY

1979

JULIENAS

1986

Cru

Rgion

QualMoy

VOLNAY

BOURGOGNE

CHABLIS

BOURGOGNE

CHABLIS

CALIFORNIE

Cru

Mill Qualit

Rgion

QualMoy

VOLNAY

1983

BOURGOGNE

VOLNAY

1979

BOURGOGNE

CHABLIS

BOURGOGNE

CHABLIS

CALIFORNIE

JULIENAS

1986

Figure VI.25 : Exemple de jointure externe

5.6. SEMI-JOINTURE
Dans certains cas, lors de lexcution dune jointure, il nest pas ncessaire de conserver tous les attributs des deux relations en rsultat : seuls les attributs dune des deux
relations sont conservs. Une opration spcifique de semi-jointure, trs utile pour
optimiser lvaluation des questions, a t dfinie [Berstein81].
Notion VI.23 : Semi-jointure (Semi-join)
Opration portant sur deux relations RELATION1 et RELATION2, donnant en rsultat les tuples de
RELATION1 qui participent la jointure des deux relations.

La semi-jointure de la relation RELATION1 par la relation RELATION2 est note :

RELATION1
RELATION2
SEMI-JOIN (RELATION1, RELATION2)
Elle est quivalente la jointure des relations RELATION1 et RELATION2 suivie par
une projection du rsultat sur les attributs de la relation RELATION1. Notez que
lopration nest pas symtrique puisque seuls des tuples de la premire relation sont
conservs. Elle peut tre vue comme une restriction de la relation RELATION1 par
les valeurs des attributs de jointure figurant dans la relation RELATION2. La
figure VI.26 illustre cette opration de semi-jointure.

204 BASES DE DONNES : OBJET ET RELATIONNEL

VINS

LOCALISATION

VINSLOG

Cru

Mill

Qualit

VOLNAY

1983

VOLNAY

1979

CHABLIS

1983

JULIENAS

1986

Cru

Rgion

QualMoy

VOLNAY

BOURGOGNE

CHABLIS

BOURGOGNE

CHABLIS

CALIFORNIE

Cru

Mill

Qualit

VOLNAY

1983

VOLNAY

1979

CHABLIS

1983

Figure VI.26 : Exemple de semi-jointure

5.7. FERMETURE TRANSITIVE

La fermeture transitive est une opration trs particulire qui permet dajouter des
tuples une relation. Elle nappartient pas lalgbre rationnelle, mais peut tre vue
comme une de ses extensions. Il nest pas possible de constituer cette opration avec
un nombre fixe doprations de lalgbre rationnelle : elle peut tre effectue par une
srie de jointure/projection/union, mais le nombre doprations effectuer dpend du
contenu de la relation. Certains auteurs considrent que cest une faiblesse de
lalgbre relationnelle que de ne pas pouvoir exprimer une fermeture transitive par
une expression constante doprations lmentaires.
Notion VI.24 : Fermeture transitive (Transitive closure)
Opration sur une relation R deux attributs (A1, A2) de mme domaine consistant ajouter R
tous les tuples qui se dduisent successivement par transitivit, cest--dire que si lon a des tuples
<a, b> et <b, c>, on ajoute <a, c>.

Cette opration se note suivant les auteurs :

(R)
R+
CLOSE(R)

Le modle relationnel 205

Pour effectuer une fermeture transitive, il est ncessaire deffectuer une boucle doprations jusqu obtention de la fermeture complte. On doit donc utiliser un langage
de programmation avec une boucle while, comme suit :
(R) = while (R) change do (R)
= (R) A1,A4 (R
(R)).

Cette opration permet par exemple de calculer partir dune relation PARENTS
(Parent, Enfant) la relation ANCETRES (Ascendant, Descendant),
qui donne toute la filiation connue dune personne. La figure VI.27 illustre cette opration. La fermeture transitive de PARENTS est calcule par
jointures/projections/unions successives de la relation PARENTS avec elle-mme
jusqu saturation, cest--dire jusqu obtention dune relation stable laquelle une
nouvelle jointure/projection/union napporte plus de tuples. On voit que la relation
ANCETRES reprsente le graphe correspondant la fermeture transitive du graphe de
la relation PARENTS.
PARENTS

Jeanne

Pierre

Parent
Pierre
Jeanne
Paul
Yves

Enfant
Paul
Paul
Yves
Jean

Paul
Yves
Jean
Graphe
de la relation PARENTS

ANCTRES

Ascendant Descendant
Pierre
Paul
Jeanne
Paul
Paul
Yves
Yves
Jean
Pierre
Yves
Jeanne
Yves
Pierre
Jean
Jeanne
Jean
Paul
Jean

Figure VI.27 : Exemple de fermeture transitive

206 BASES DE DONNES : OBJET ET RELATIONNEL

6. LES EXPRESSIONS DE LALGBRE

RELATIONNELLE
partir des oprations de lalgbre relationnelle, il est possible de composer un langage dinterrogation de bases de donnes. Une question peut alors tre reprsente par
un arbre doprateurs relationnels. Le paraphrasage en anglais de telles expressions
est la base du langage SQL que nous tudierons dans le chapitre suivant.

6.1. LANGAGE ALGBRIQUE

En utilisant des expressions doprations de lalgbre relationnelle, il est possible
dlaborer les rponses la plupart des questions que lon peut poser une base de
donnes relationnelle. Plus prcisment, les oprations de base de lalgbre relationnelle constituent un langage complet, cest--dire ayant la puissance de la logique du
premier ordre.
Notion VI.25 : Langage complet (Complete language)
Langage quivalent la logique du premier ordre.

Nous avons tudi plus prcisment la logique du premier ordre et les langages
dinterrogation qui en dcoulent au chapitre V. Disons simplement que lalgbre relationnelle permet dexprimer toute question exprimable avec la logique du premier
ordre sans fonction, par exemple avec le calcul de tuple ou de domaine. Lalgbre
relationnelle peut dailleurs tre tendue avec des fonctions [Zaniolo85].
Voici quelques questions sur la base DEGUSTATION dont le schma a t reprsent
figure VI.7. Elles peuvent tre exprimes comme des expressions doprations, ou
comme des oprations successives appliques sur des relations intermdiaires ou de
base, gnrant des relations intermdiaires. Pour des raisons de clart, nous avons
choisi cette deuxime reprsentation. Lexpression peut tre obtenue simplement en
supprimant les relations intermdiaires notes Ri.
(Q1) Donner les degrs des vins de crus Morgon et de millsime1978 :
R1 = RESTRICT (VINS, CRUS = MORGON)
R2 = RESTRICT (VINS, MILLESIME = 1978)
R3 = INTERSECT (R1, R2)
RESULTAT = PROJECT (R3, DEGRE)

(Q2) Donner les noms et prnoms des buveurs de Morgon ou Chenas :

R1 = RESTRICT (VINS, CRU = MORGON)
R2 = RESTRICT(VINS, CRUS = CHENAS)
R3 = UNION (R1, R2)

Le modle relationnel 207

R4 = JOIN (R3, ABUS)

R5 = JOIN (R4, BUVEURS)
RESULTAT = PROJECT (R5, NOM, PRENOM)

(Q3) Donner les noms et adresses des buveurs ayant bu plus de 10 bouteilles de
Chablis 1976 avec le degr de ce vin :
R1 = RESTRICT (ABUS, QUANTITE > 10)
R2 = RESTRICT (VINS, CRU = CHABLIS)
R3 = RESTRICT (VINS, MILLESIME = 1976)
R4 = INTERSECT (R2, R3)
R5 = JOIN (R1, R4)
R6 = PROJECT (R5, NB, DEGRE)
R7 = JOIN (R6, BUVEURS)
RESULTAT = PROJECT (R7, NOM, ADRESSE, DEGRE)

(Q4) Donner les noms des buveurs nayant bu que du Morgon :

R1 = JOIN(BUVEURS,ABUS,VINS)
R2 = RESTRICT(R1, CRU = Morgon)
R3 = PROJECT(R2, NOM)
R4 = RESTRICT(R1, CRU Morgon)
R5 = PROJECT(R1, NOM)
RESULTAT = MINUS(R3 R5)

Si lon accepte les relations constantes, lalgbre relationnelle permet aussi dexcuter
les mises jour. Par exemple, lintersection du vin [100, TOKAY, 1978, 13] seffectuera comme suit :
R1 = CONSTANTE (VINS, [100, TOKAY, 1978, 13])
VINS = UNION (VINS, R1)

o CONSTANTE permet de dfinir une relation de mme schma que la relation VINS
contenant le seul tuple indiqu en argument.

6.2. ARBRE ALGBRIQUE

Une question exprime sous forme dun programme doprations de lalgbre relationnelle peut tre reprsente par un arbre relationnel. Les nuds correspondent
aux reprsentations graphiques des oprations indiques ci-dessus et les arcs aux flots
de donnes entre oprations.
Notion VI.26 : Arbre relationnel (Relational tree)
Arbre dont les nuds correspondent des oprations de lalgbre relationnelle et les arcs des
relations de base ou temporaires reprsentant des flots de donnes entre oprations.

Ainsi, la question Noms et Prnoms des buveurs habitant Paris ayant bu du Chablis
depuis le 1 er janvier 1992 peut tre exprime laide de larbre reprsent

208 BASES DE DONNES : OBJET ET RELATIONNEL

figure VI.28. Plusieurs arbres quivalents peuvent tre dduits dun arbre donn
laide de rgles de transformation simples, telles que la permutation des jointures et
restrictions, la permutation des projections et des jointures, le regroupement des intersections sur une mme relation, etc. Ces transformations sont la base des techniques
doptimisation de questions qui dpassent le sujet de ce chapitre. La figure VI.29 propose un arbre quivalent celui de la figure VI.28, obtenu par descente de projections
et regroupement dintersections.
RSULTAT
B.NOM, B. PRNOM

A. DATE

01.01.92

V. CRU

CHABLIS

A.NV

V.NV

B.NB

VINS V

A.NB
ABUS A

B.ADRESSE

LIKE

PARIS

BUVEURS B

Figure VI.28 : Exemple darbre reprsentant une question

La composition doprations de lalgbre relationnelle ne ncessite pas toujours

dattendre le rsultat de lopration prcdente pour excuter lopration suivante.
Restriction, projection et jointure peuvent ainsi tre excutes par des algorithmes flots
de donnes. Des oprateurs se succdant sur un arbre peuvent donc tre excuts en
parallle par des algorithmes pipe-line . Des oprateurs figurant sur des branches distinctes dun arbre peuvent aussi tre excuts en parallle de manire indpendante. La
reprsentation par arbre algbrique met ainsi en vidence les possibilits de paralllisme
et les enchanements ncessaires. Ces proprits des arbres relationnels sont importantes
pour optimiser les questions dans des contextes parallles.

Le modle relationnel 209

RSULTAT
B.NOM, B. PRNOM
A.NV

V.NV

B.NOM
B. PRNOM
A.NV

B.NB

V.NV

=
=

V. CRU
B.NB
B.NOM
B. PRNOM

B.ADRESSE

LIKE

PARIS

BUVEURS B

CHABLIS

A.NB
A.NV
VINS V
A. DATE

01.01.92

ABUS A

Figure VI.29 : Arbre quivalent larbre prcdent

7. FONCTIONS ET AGRGATS
Lalgbre relationnelle est insuffisante pour traiter de vritables applications des bases de
donnes, telles la suivie de production, la gestion de budget, etc. Il est en effet ncessaire
deffectuer des calculs sur la base pour supporter de telles applications. Cest lobjet de
lintroduction des fonctions de calcul au sein de lalgbre et du support des agrgats.

7.1. FONCTIONS DE CALCUL

La possibilit deffectuer des calculs sur les attributs est simplement introduite en gnralisant projection, restriction et jointure par introduction de fonctions. Ainsi, tout attribut
apparaissant en argument dune opration est remplac par une expression dattributs.

210 BASES DE DONNES : OBJET ET RELATIONNEL

Notion VI.27 : Expression dattributs (Attribut expression)

Expression arithmtique construite partir dattributs dune relation et de constantes, par application de fonctions arithmtiques successives.

Voici des exemples dexpressions dattributs :

10 + 50 23 ;
QUANTITE * 50 ;
QUANTITE * DEGRE / 100 ;
QUANTITE QUANTITE * DEGRE / 100.

De telles expressions peuvent donc tre utilises comme arguments de projections, de

restrictions voire de jointures. Le programme dalgbre relationnelle suivant illustre
ces possibilits :
R1 = JOIN (VINS, ABUS, DEGRE*QUANTITE/100 > QUANTITE/10)
R2 = RESTRICT(R1, DEGRE*QUANTITE/100 > 10)
RESULTAT = PROJECT(R2, CRU, QUANTITE QUANTITE*DEGRE/100)

La notion dexpression dattributs peut tre gnralise avec des fonctions autres que les
fonctions arithmtiques, par exemple des fonctions crites dans un langage externe. On
aboutit ainsi une gnralisation de lalgbre relationnelle aux fonctions [Zaniolo85].

7.2. SUPPORT DES AGRGATS

Les expressions dattributs permettent deffectuer des oprations de calcul en ligne,
sur des attributs de relations. En pratique, il est ncessaire deffectuer des oprations
de calcul en colonnes, sur des tuples de relations, cela par exemple afin de sommer
des dpenses, etc. Le concept dagrgat permet de telles oprations.
Notion VI.28 : Agrgat (Aggregat)
Partitionnement horizontal dune relation en fonction des valeurs dun groupe dattributs, suivi dun
regroupement par application dune fonction de calcul sur ensemble.

Les fonctions de calcul sur ensemble les plus souvent proposes sont :
SOMME (SUM) permettant de calculer la somme des lments dun ensemble ;
MOYENNE (AVG) permettant de calculer la moyenne des lments dun ensemble ;
MINIMUM (MIN) permettant de slectionner llment minimum dun ensemble ;
MAXIMUM (MAX) permettant de slectionner llment maximum dun ensemble ;
COMPTE (COUNT) permettant de compter les lments dun ensemble.
La figure VI.30 illustre le concept dagrgat. La table VINS est enrichie dun attribut
QUANTITE. Lagrgat reprsent calcule la somme des quantits par CRU. Lopration gnrique scrit :
R = AGREGAT(<RELATION> ; <ATTRIBUT1> ; <FONCTION>{<ATTRIBUT2>})

Le modle relationnel 211

<Attribut1> reprsente un ou plusieurs attributs utiliss pour le partitionnement.

Fonction est la fonction densemble applique lattribut <Attribut2>. Par
exemple, on crit :
RESULTAT = AGREGAT(VINS ; CRU ; SUM{QUANTITE})

pour lagrgat illustr figure VI.30. Notez quun agrgat peut seffectuer sans partitionnement ; on peut par exemple calculer simplement la moyenne de tous les degrs
comme indiqu figure VI.30 par la commande :
RESULTAT = AGREGAT(VINS ; ; AVG{DEGRE}).
VINS

Cru

Mill

Degr

Quantit

VOLNAY

1983

11,7

100

VOLNAY

1979

11,3

200

CHABLIS

1983

11,4

250

CHABLIS

1992

11,8

300

JULIENAS

1986

12,0

400

AGREGAT(VINS;; AVG{DEGRE})

MOY

Degr

AGREGAT(VINS; CRU; SUM{QUANTITE})

11,64
SUM

Cru

Quantit

VOLNAY

300

CHABLIS

550

JULIENAS

400

Figure VI.30 : Exemples de calcul dagrgats

8. CONCLUSION
Dans ce chapitre, nous avons introduits les concepts essentiels aujourdhui supports
par le modle relationnel dans les grands systmes industriels tels que ORACLE,
INGRES, DB2, SYBASE, etc. Ces concepts constituent la base du langage SQL, le
langage des systmes relationnels. Nous allons tudier ce langage et ses extensions
dans les chapitres qui suivent.
Le modle relationnel fait aujourdhui autorit dans lindustrie. Issu de la thorie des relations, il est lorigine une remarquable construction de la recherche. Il a su progressive-

212 BASES DE DONNES : OBJET ET RELATIONNEL

ment intgrer des concepts de plus en plus riches, tels que lintgrit rfrentielle, les
rgles actives, etc. Le modle a aujourdhui intgr les concepts de lobjet pour fonder
lobjet-relationnel, comme nous le verrons dans la troisime partie de cet ouvrage. Il a
encore un bel avenir devant lui, bien quil soit parfois contest par les tenants de lobjet.

9. BIBLIOGRAPHIE
[Berstein81] Bernstein P., Goodman N., The Power of Natural Semijoins , Siam
Journal of Computing, vol. 10, n 4, dcembre 1981, p. 751-771.
Une discussion de la puissance de loprateur de semi-jointure. Aprs une dfinition de la semi-jointure, Phil Bernstein et Nathan Goodman montrent que cet
oprateur permet dexprimer un grand nombre de questions avec jointures,
plus spcifiquement toutes celles dont le graphe des jointures est un arbre.
[Chen76] Chen P.P., The Entity-Relationship Model Towards a Unified View of
Data , ACM Transactions on Database Systems, vol. 1, n 1, mars 1976.
Larticle de base sur le modle entit-association. Il introduit ce modle pour
dcrire la vue des donnes dune entreprise. En particulier, les diagrammes de
Chen sont prsents. Il est montr que le modle permet dunifier les diffrents
points de vue et de passer simplement une implmentation relationnelle. Ce
dernier point explique le fait que beaucoup doutils daide la conception de
bases de donnes relationnelles utilisent une variante du modle de Chen.
[Childs68] Childs D.L., Feasibility of a Set-Theoretic Data Structure A General
Structure Based on a Reconstituted Definition of a Relation , Congrs IFIP,
Genve, 1968, p. 162-172.
Un des premiers articles proposant un modle bas sur le concept de relation et
des oprateurs ensemblistes. La proposition de Codd sest inspire des travaux
de Childs.
[Codd70] Codd E.F., A Relational Model for Large Shared Data Banks ,
Communications de lACM, vol. 13, n 6, juin 1970, p. 377-387.
Larticle de base proposant le modle relationnel. Il introduit les concepts
essentiels de relation, domaine, attribut et cl. Lalgbre relationnelle est propose comme langage de manipulation des relations.
[Codd79] Codd E.F., Extending the Relational Model to Capture More Meaning ,
ACM TODS, vol. 4, n 4, dcembre 1979, p. 397-433.
Une proposition dextension du modle relationnel pour mieux dcrire la
smantique des applications. Lide de base est de distinguer diffrents types de

Le modle relationnel 213

relations (entit, association, gnralisation, etc.) et dtendre les oprateurs

relationnels en consquence. Un traitement des valeurs nulles avec une logique
trivalue est aussi propos. Lensemble du modle tendu, appel RM/T, est
dcrit par un mtamodle relationnel.
[Date81] Date C.J., Referential Integrity , 7e Very Large Data Bases, Cannes,
France, 1981, IEEE Ed.
Larticle proposant le support de lintgrit rfrentiel au sein du modle relationnel. Chris Date introduit les contraintes rfrentielles et les contraintes
dentit comme contraintes de base intgrer au modle relationnel pour un
meilleur support de la smantique des donnes. Un langage de dclaration de
contraintes est aussi esquiss.
[Delobel83] Delobel C., Adiba M., Bases de Donnes et Systmes Relationnels, livre,
Dunod Informatique, 1983.
Un des premiers livres franais sur les bases de donnes relationnelles. Alors
que le livre Bases de Donnes Les Systmes et Leurs Langages de Georges
Gardarin paru la mme poque propose une vue simplifie des diffrents
concepts, ce livre offre une vision plus formelle, souvent fonde sur les travaux
de luniversit de Grenoble. Des oprateurs relationnels spcifiques et une
approche originale la normalisation des relations sont notamment dvelopps.
[Fagin80] Fagin R., A Normal Form for Relational Databases that is Based on
Domains and Keys , ACM TODS, vol. 6, n 3, septembre 1981, p. 387-415.
Un des articles prosant une forme ultime de normalisation des relations. Une
relation est en 5e forme normale si elle ne peut plus tre dcompose par projection sur diffrents sous-schmas, de sorte obtenir la relation de dpart par
jointures naturelles des sous-relations. Fagin introduit une mthode de normalisation fonde sur les domaines et les cls. Il montre quil sagit l de la forme
ultime de normalisation par projection et jointure. Il introduit aussi un oprateur dclatement qui permet denvisager dautres formes de normalisation
horizontale.
[Gardarin89] Gardarin G., Cheiney J.P., Kiernan J., Pastre D., Managing Complex
Objects in an Extensible DBMS , 15th Very Large Data Bases International
Conference, Morgan Kaufman Pub., Amsterdam, Pays-Bas, aot 1989.
Une prsentation dtaille du support dobjets complexes dans le SGBD extensible Sabrina. Ce systme est driv du SGBD relationnel SABRE et supporte
des types abstraits comme domaines dattributs. Il a aujourdhui volu vers un
SGBD gographique (GoSabrina) et est commercialis par INFOSYS.
[ISO89] International Organization for Standardization, Information Processing
Systems Database Language SQL with Integrity Enhancement ,
International Standard ISO/IEC JTC1 9075 : 1989(E), 2e dition, avril 1989.

214 BASES DE DONNES : OBJET ET RELATIONNEL

La norme SQL aujourdhui en vigueur. Ce document de 120 pages prsente la

norme SQL1 : concepts de base, lments communs, langage de dfinition de
schmas, dfinition de modules de requtes, langage de manipulation. Toutes la
grammaire de SQL1 est dcrite en BNF. Ce document rsulte de la fusion du
standard de 1986 et des extensions pour lintgrit de 1989.
[Maier83] Maier D., The Theory of Relational Databases, livre, Computer Science
Press, 1983.
Le livre synthtisant tous les dveloppements thoriques sur les bases de donnes relationnelles. En 600 pages assez formelles, Maier fait le tour de la thorie des oprateurs relationnels, des dpendances fonctionnelles, multivalues et
algbriques, et de la thorie de la normalisation.
[Stonebraker87] Stonebraker M., The Design of the POSTGRES Storage System ,
13th Very Large Databases International Conference, Morgan & Kauffman Ed.,
Brighton, Angleterre, 1987.
Une description assez complte du systme POSTGRES, successeur dINGRES
dvelopp Berkeley. M. Stonebraker prsente la conception du noyau de stockage du systme POSTGRES. Outre un contrle de concurrence original permettant le support de dclencheurs (ou rflexes), ce sytme intgre les types
abstraits au modle relationnel. Un type abstrait permet de dfinir un type
dattribut ou de tuple. Le systme POSTGRES a ainsi permis de prototyper les
fonctionnalits orientes objets intgres la version 7 dINGRES.
[Ullman88] Ullman J.D., Principles of Database and Knowledge-base Systems, livres,
volumes I et II, Computer Science Press, 1988.
Deux volumes trs complets sur les bases de donnes, avec une approche plutt
fondamentale. Jeffrey Ullman dtaille tous les aspects des bases de donnes,
des mthodes daccs aux modles objets en passant par le modle logique. Les
livres sont finalement centrs sur une approche par la logique aux bases de
donnes. Les principaux algorithmes daccs, doptimisation de requtes, de
concurrence, de normalisation, etc. sont dtaills.
[Zaniolo83] Zaniolo C., The Database Language GEM , ACM SIGMOD
Confrence, San Jos, Ca., ACM Ed., 1983.
Une extension du modle relationnel vers le modle entit-association et du langage QUEL pour supporter un tel modle. Carlo Zaniolo propose dutiliser les
entit pour spcifier les domaines lors de la dfinition des associations. Il propose
alors une extension de QUEL avec une notation pointe pour naviguer depuis les
associations vers les attributs des entits. Lensemble constitue le langage GEM,
qui a t implment Bell Labs au-dessus de la machine bases de donnes IDM.
[Zaniolo85] Zaniolo C., The Representation and Deductive Retrieval of Complex
Objects , 11th Very Large Data Bases International Conference, Morgan
Kaufman Pub., Stockholm, Sude, aot 1985.

Le modle relationnel 215

Une extension de lalgbre relationnelle au support de fonctions. Cet article

prsente une extension de lalgbre relationnelle permettant de rfrencer des
fonctions symboliques dans les critres de projection et de slection, afin de
manipuler des objets complexes. Des oprateurs dductifs de type fermeture
transitive tendue sont aussi intgrs.

Chapitre VII

LE LANGAGE SQL2
1. INTRODUCTION
Les serveurs de donnes relationnels prsentent aujourdhui une interface externe sous
forme dun langage de recherche et mise jour, permettant de spcifier les ensembles
de donnes slectionner ou mettre jour partir de proprits des valeurs, sans
dire comment retrouver les donnes. Ainsi, les oprations directement utilisables par
les usagers sont en gnral celles des langages dits assertionnels. Plusieurs langages
assertionnels permettant de manipuler des bases de donnes relationnelles ont t proposs, en particulier QUEL [Zook77], QBE [Zloof77] et SQL [IBM82, IBM87].
Aujourdhui, le langage SQL est normalis [ISO89, ISO92] et constitue le standard
daccs aux bases de donnes relationnelles. Les autres interfaces par menus, fentres,
grilles, etc., ou de programmation type langage de 3e ou 4e gnration, sont le plus
souvent offertes au-dessus du langage SQL. Celui-ci constitue donc le point dentre
obligatoire des SGBD relationnels. QUEL tait le langage propos par luniversit de
Berkeley pour son systme INGRES : il est aujourdhui peu utilis dans lindustrie.
QBE est un langage par grille driv de la logique qui est souvent offert au-dessus de
SQL.
De manire gnrale, SQL comme les autres langages qui ont t proposs (e.g.,
QUEL) utilisent tous des critres de recherche (encore appels qualifications)
construits partir de la logique des prdicats du premier ordre. Ils comportent quatre
oprations de base :

218 BASES DE DONNES : OBJET ET RELATIONNEL

la recherche (mot cl SELECT en SQL, RETRIEVE en QUEL) permet de retrouver des tuples ou parties de tuples vrifiant la qualification cite en arguments ;
linsertion (mot cl INSERT en SQL, APPEND en QUEL) permet dajouter des
tuples dans une relation ; les tuples peuvent tre fournis par lutilisateur ou
construits partir de donnes existant dj dans la base ;
la suppression (mot cl DELETE en SQL, SUPPRESS en QUEL) permet de supprimer dune relation les tuples vrifiant la qualification cite en argument ;
la modification (mot cl UPDATE en SQL, REPLACE en QUEL) permet de
mettre jour les tuples vrifiant la qualification cite en argument laide de nouvelles valeurs dattributs ou de rsultats doprations arithmtiques appliques aux
anciennes valeurs.
Le langage assertionnel SQL fut introduit commercialement tout dabord par IBM
[IBM82]. Il rsultait alors dune volution du langage SEQUEL 2 [Chamberlin76] initialement dvelopp au centre de recherches de San-Jos comme un langage exprimental appel SQUARE [Boyce75] pour paraphraser en anglais les expressions de
lalgbre relationnelle. Aujourdhui, lISO a normalis le langage SQL pour manipuler les bases de donnes relationnelles et ceci plusieurs niveaux. Le niveau SQL1
[ISO89] correspond la norme de base accepte en 1989, telle quelle est aujourdhui
applique par la plupart des constructeurs. SQL1 permet lexpression des requtes
composes doprations de lalgbre relationnelle et dagrgats. En plus des fonctionnalits de dfinition, de recherche et de mise jour, SQL1 comporte aussi des fonctions de contrle qui nappartiennent pas proprement parler au modle relationnel,
mais qui sont ncessaires pour programmer des applications transactionnelles.
Le niveau SQL2 [ISO92] est sous-divis en trois niveaux, respectivement entre,
intermdiaire et complet. Le niveau entre peut tre peru comme une amlioration de
SQL1, alors que les niveaux intermdiaire et complet permettent de supporter totalement le modle relationnel avec des domaines varis, tels date et temps. SQL3 est
constitu dun ensemble de propositions nouvelles traitant plus particulirement des
fonctionnalits objets et dductives.
Ce chapitre est organis comme suit. Les quatre sections qui suivent sont consacres
ltude du standard SQL1. Nous tudions successivement la dfinition de schma, la
recherche de donnes, lexpression des mises jour et lintgration aux langages de
programmation pour crire des transactions. La section qui suit prsente les fonctionnalits du nouveau standard SQL2. En conclusion, nous introduisons brivement les
propositions mises dans le cadre SQL3 (voir chapitre XIII) et nous soulignons
limportance de SQL.
Nous utilisons des notations syntaxiques en BNF (Backus-Naur Form), avec les
extensions suivantes :
les crochets ([]) indiquent des lments optionnels ;
les pointills suivent un lment qui peut tre rpt plusieurs fois ;

Le langage SQL2 219

les accolades groupent comme un seul lment une squence dlments ;

un exposant plus (+) indique que llment qui prcde peut tre rpt n fois (n>0),
chaque occurrence tant spare de la prcdente par une virgule ;
un exposant multipli (*) indique que llment qui prcde peut tre rpt n fois
(n0), chaque occurrence tant spare de la prcdente par une virgule.

2. SQL1 : LA DFINITION DE SCHMAS

SQL1 permet de dfinir des schmas de bases de donnes composs de tables et de
vues. Un schma est simplement identifi par un identifiant autorisant laccs la
base. Au niveau dun schma sont associs des autorisations daccs aux tables. Au
niveau de la table, des contraintes dintgrit peuvent tre dfinies.

2.1. CRATION DE TABLES

SQL1 permet de crer des relations sous forme de tables et de dfinir lors de la cration des contraintes dintgrit varis sur les attributs. Ainsi, une commande de cration permet de spcifier le nom de la table et de dfinir les lments de table correspondant aux colonnes ou aux contraintes, selon la syntaxe suivante :
CREATE TABLE <nom de table> (<lment de table>+)

Un nom de table peut tre un nom simple (par exemple VINS) ou un nom compos
dun nom de schma (identifiant dautorisation daccs la base, par exemple
DEGUSTATION) suivi par le nom simple de table en notation pointe (par exemple,
DEGUSTATION.VINS).
Un lment de table est soit une dfinition de colonne, soit une dfinition de
contrainte, comme suit :
<LMENT DE TABLE> ::=

<DFINITION DE COLONNE> |
<CONTRAINTE DE TABLE>

Une colonne est dfinie par un nom et un type de donnes. Une valeur par dfaut peut
tre prcise. Une contrainte de colonne peut aussi tre dfinie ce niveau. On obtient
donc la syntaxe suivante :
<DFINITION DE COLONNE> : := <NOM DE COLONNE> <TYPE DE DONNES>
[<CLAUSE DFAUT>] [<CONTRAINTE DE COLONNE>]

Les types de donnes supports sont les chanes de caractres de longueurs fixes
CHAR(<longueur>) , la valeur par dfaut de la longueur tant 1, les numriques

220 BASES DE DONNES : OBJET ET RELATIONNEL

exactes NUMERIC et DECIMAL avec prcision et chelle optionnelles, INTEGER

et SMALLINT , les numriques approchs FLOAT avec prcision optionnelle,
REAL et DOUBLE PRECISION.
La clause dfaut permet simplement de spcifier une valeur par dfaut selon la syntaxe DEFAULT <valeur>, la valeur NULL tant permise. Nous examinerons les
contraintes dintgrit de table et de colonne dans la section qui suit.
Afin dillustrer les possibilit introduites, la figure VII.1 prsente les commandes permettant de crer la base dgustation, pour linstant sans contrainte dintgrit. Le
schma de la base obtenu est compos des trois relations suivantes :
VINS (NV, CRU, MILLESIME, DEGRE, QUALITE)
BUVEURS (NB, NOM, ADRESSE, TYPE)
ABUS (NB, NV, DATE, QUANTITE).
CREATE SCHEMA AUTHORIZATION DEGUSTATION
CREATE TABLE VINS (NV INT, CRU CHAR(12), MILLESIME INT, DEGRE DEC(3,1),
QUALITE CHAR)
CREATE TABLE BUVEURS (NB INT, NOM CHAR(20), ADRESSE CHAR(30), TYPE
CHAR(4))
CREATE TABLE ABUS(NB INT, NV INT, DATE DEC(6), QUANTITE SMALLINT)

Figure VII.1 : Cration de la base Dgustation

2.2. EXPRESSION DES CONTRAINTES DINTGRIT

Les contraintes de colonnes permettent de spcifier diffrentes contraintes dintgrit
portant sur un seul attribut, y compris les contraintes rfrentielles. Les diffrentes
variantes possibles sont :
valeur nulle impossible (syntaxe NOT NULL),
unicit de lattribut (syntaxe UNIQUE ou PRIMARY KEY),
contrainte rfrentielle syntaxe REFERENCES <table rfrence> [(<colonne
rfrence>)] , le nom de la colonne rfrence tant optionnel sil est identique
celui de la colonne rfrenante,
contrainte gnrale (syntaxe CHECK <condition>) ; la condition est une condition
pouvant spcifier des plages ou des listes de valeurs possibles (voir condition de
recherche ci-dessous).
Les contraintes de relations peuvent porter sur plusieurs attributs. Ce peut tre des
contraintes dunicit, rfrentielles ou gnrales. Elles sont exprimes laide des
phrases suivantes :
contrainte dunicit UNIQUE <attribut>+,

Le langage SQL2 221

contrainte rfrentielle, permettant de spcifier quelles colonnes rfrencent celles

dune autre table, [FOREIGN KEY (<colonne rfrenante>+)] REFERENCES
<table rfrence> [(<colonne rfrence>+)],
contrainte gnrale CHECK <condition>.
Par exemple, la cration de la relation ABUS avec contraintes dintgrit pourra tre
effectue par la commande de la figure VII.2. Cette commande prcise que les attributs NB et NV ne doivent pas tre nuls et doivent exister dans les relations BUVEURS
et VINS respectivement, que la date est comprise entre le premier janvier 80 et le
31 dcembre 99, que la quantit doit tre comprise entre 1 et 100 avec une valeur par
dfaut de 1.
CREATE TABLE ABUS (
NB INT NOT NULL,
NV INT NOT NULL REFERENCES VINS(NV),
DATE DEC(6) CHECK (DATE BETWEEN 010180 AND 311299),
QUANTITE SMALLINT DEFAULT 1,
PRIMARY KEY(NB, NV, DATE),
FOREIGN KEY NB REFERENCES BUVEURS,
CHECK (QUANTITE BETWEEN 1 AND 100))

Figure VII.2 : Cration de la table ABUS avec contraintes dintgrit

2.3. DFINITION DES VUES

SQL1 permet de dfinir des vues au niveau du schma. Rappelons quune vue est une
table virtuelle calcule partir des tables de base par une question. La syntaxe de la
commande de cration de vues est la suivante :
CREATE VIEW <NOM DE TABLE> [(<NOM DE COLONNE>+)]
AS <SPCIFICATION DE QUESTION>
[WITH CHECK OPTION]

Une vue est modifiable sil est possible dinsrer et de supprimer des tuples dans la
base au-travers de la vue. Dans ce cas, les tuples sont insrs ou supprims dans la
premire table rfrence par la question. La vue doit alors contenir toutes les
colonnes de cette table. Loption WITH CHECK OPTION permet de sassurer que les
tuples insrs vrifient les conditions exprimes dans la question, cest--dire quils
appartiennent bien la vue. Cela permet dimposer des contraintes dintgrit lors des
mises jour au travers de la vue (par exemple, le fait quun tuple de la vue doit rfrenc un tuple dune autre table).
titre dillustration, voici une vue GROS-BUVEURS dfinie simplement comme la
table virtuelle contenant le nom et le prnom des buveurs de type GROS . Cette

222 BASES DE DONNES : OBJET ET RELATIONNEL

vue nest pas modifiable. Cette dfinition montre dj un premier exemple de question SQL trs simple, de type slection.
CREATE VIEW GROS-BUVEURS (NOM, PRENOM)
AS
SELECT NOM, PRENOM
FROM BUVEURS
WHERE TYPE = GROS

Figure VII.3 : Exemple de dfinition de vue

2.4. SUPPRESSION DES TABLES

La suppression des tables nest pas permise en SQL1. La plupart des systmes permettent cependant de dtruire une relation par la commande :
DROP TABLE <NOM DE TABLE>.

Par exemple, la destruction de la relation VINS seffectuera par la commande :

DROP TABLE VINS.

2.5. DROITS DACCS

La gestion des droits daccs aux tables est dcentralise : il nexiste pas dadministrateur global attribuant des droits. Chaque crateur de table obtient tous les droits daccs
cette table, en particulier les droits deffectuer les actions de slection (SELECT),
dinsertion (INSERT), de suppression (DELETE), de mise jour (UPDATE) et aussi de
rfrencer la table dans une contrainte (REFERENCES). Il peut ensuite passer ses droits
slectivement dautres utilisateurs ou tous le monde (PUBLIC). Un droit peut tre
pass avec le droit de le transmettre (WITH GRANT OPTION) ou non.
SQL1 propose ainsi une commande de passation de droits dont la syntaxe est la suivante :
GRANT <PRIVILGES> ON <NOM DE TABLE> TO <RCEPTEUR>+
[WITH GRANT OPTION]

avec :
<PRIVILGES> ::= ALL PRIVILEGES | <ACTION>+
<ACTION>

::=

<RCEPTEUR> ::=

SELECT | INSERT | UPDATE [(<NOM DE COLONNE>+)]

| REFERENCE [(<NOM DE COLONNE>+)]
PUBLIC | <IDENTIFIANT DAUTORISATION>

Le langage SQL2 223

Lensemble des privilges (ALL PRIVILEGES) inclut les droits dadministration

(changement de schma et destruction de la relation). Le rcepteur peut tre un utilisateur ou un groupe dutilisateurs, selon lidentifiant dautorisation donn.
Par exemple, la passation des droits de consultation et mise jour de la table VINS
lutilisateur Poivrot seffectuera comme indiqu ci-dessous. La prsence de loption
de passation (GRANT OPTION) permet Poivrot de passer ce droit.
GRANT SELECT, UPDATE ON VINS TO POIVROT
WITH GRANT OPTION

Bien que non prvue dans la norme de 1989, la commande REVOKE permet de retirer
un droit un utilisateur. Sa syntaxe est la suivante :
REVOKE <privilges> ON <nom de table> FROM <rcepteur>.

Par exemple, la commande qui suit permet de retirer le droit donn ci-dessus ainsi que
tous les droits qui en dpendent (cest--dire ceux de slection ou mise jour de la
table VINS passs par Poivrot).
REVOKE SELECT, UPDATE ON VINS FROM POIVROT.

3. SQL1 : LA RECHERCHE DE DONNES

Dans cette section, nous tudions la requte de recherche qui est la base de SQL, le
fameux SELECT. Nous commenons par des exemples partir de cas simples drivs
de lalgbre relationnelle pour aboutir au cas gnral.

3.1. EXPRESSION DES PROJECTIONS

Rappelons quune projection effectue lextraction de colonnes (attributs) spcifies
dune relation, puis limine les tuples en double. SQL nlimine pas les doubles,
moins que cela soit explicitement demand par le mot cl DISTINCT, loption par
dfaut tant ALL. SQL gnralise la projection en ce sens quil est possible dappliquer des fonctions de calculs sur les colonnes extraites. Les fonctions de calculs permises sont en particulier les fonctions arithmtiques daddition, soustraction, multiplication et division. Une projection sexprime laide du langage SQL par la clause :
SELECT [ALL|DISTINCT] <EXPRESSION DE VALEURS>+
FROM <NOM DE TABLE> [<NOM DE VARIABLE>]

Une expression de valeurs est une expression arithmtique (compose avec les oprateurs binaires +, , * et /), ventuellement parenthse, de spcifications de constantes

224 BASES DE DONNES : OBJET ET RELATIONNEL

ou de colonnes. Une spcification de constante est soit une constante, une variable de
programme ou le nom de lusager (mot cl USER). Une spcification de colonne
dsigne le nom dune colonne prcd dun dsignateur de relation ventuel (nom de
table ou variable), comme suit :
<SPCIFICATION DE COLONNE> ::= [<DSIGNATEUR>.] <NOM DE COLONNE>
<DSIGNATEUR> ::= <NOM DE TABLE> | <NOM DE VARIABLE>

Lusage dun nom de variable ncessite de dfinir dans la clause FROM une variable
dite de corrlation, permettant de dsigner la table par cette variable. De telles
variables vitent de rpter le nom de la table dans le cas de questions portant sur plusieurs tables, comme nous le verrons ci-dessous. Notez aussi quil est possible dutiliser une toile (*) la place de la liste dexpression de valeurs, cela signifiant simplement que lon dsire lister tous les attributs de la table rfrence dans la clause FROM.
Nous illustrons la projection en utilisant la table VINS dont le schma a t dfini cidessus. La premire question (Q1) indique figure VII.4 permet dobtenir pour tous
les vins les crus, millsimes et quantit dalcool pur contenue dans 1 000 litres, avec
doubles ventuels. La deuxime question (Q2) effectue la recherche de tous les tuples
de la table VINS sans double.
(Q1) SELECT CRU, MILLESIME, (DEGRE/100)*1000
FROM VINS
(Q2) SELECT DISTINCT *
FROM VINS

Figure VII.4 : Exemples de projections

3.2. EXPRESSION DES SLECTIONS

Une slection est une combinaison dune restriction suivie dune projection. Une
slection sexprime comme une projection avec en plus une condition de recherche
selon la syntaxe suivante :
SELECT [ALL|DISTINCT] {<expression de valeurs>+ | *}
FROM <nom de table> [<nom de variable>]
WHERE <condition de recherche>

Une condition de recherche dfinit un critre, qui appliqu un tuple, est vrai, faux ou
inconnu, selon le rsultat de lapplication doprateurs boolens (ET, OU, NOT)
des conditions lmentaires. Lexpression boolenne de conditions lmentaires peut
tre parenthse. La figure VII.5 donne les tables de vrit permettant de calculer la
valeur de vrit dune condition de recherche. En principe, les seuls tuples satisfaisant
la condition de recherche sont slectionns par la requte.

Le langage SQL2 225

AND

VRAI

FAUX

INCONNU

VRAI

VRAI

FAUX

INCONNU

FAUX

FAUX

FAUX

FAUX

INCONNU

INCONNU

FAUX

INCONNU

OR

VRAI

FAUX

INCONNU

VRAI

VRAI

VRAI

VRAI

FAUX

VRAI

FAUX

INCONNU

INCONNU

VRAI

INCONNU

INCONNU

VRAI

FAUX

INCONNU

FAUX

VRAI

INCONNU

NOT

Figure VII.5 : Calcul de la valeur dune condition de recherche

Une condition de recherche lmentaire est appele prdicat en SQL. Un prdicat de

restriction permet de comparer deux expressions de valeurs ; la premire contenant
des spcifications de colonnes est appele terme ; la seconde contenant seulement des
spcifications de constantes est appele constante. Il existe une grande diversit de
prdicats en SQL1. On trouve en effet :
1. un prdicat de comparaison permettant de comparer un terme une constante
laide des oprateurs {=, , <, >, <=, >=} ;
2. un prdicat dintervalle BETWEEN permettant de tester si la valeur dun terme est
comprise entre la valeur de deux constantes ;
3. un prdicat de comparaison de texte LIKE permettant de tester si un terme de type
chane de caractres contient une ou plusieurs sous-chanes ;
4. un prdicat de test de nullit qui permet de tester si un terme a une valeur convenue
NULL, signifiant que sa valeur est inconnue ;
5. un prdicat dappartenance IN qui permet de tester si la valeur dun terme appartient une liste de constantes.
La figure VII.6 donne quelques exemples de slections illustrant ces diffrents types
de prdicats. La question (Q3) effectue la restriction de la relation VINS par la qualifi-

226 BASES DE DONNES : OBJET ET RELATIONNEL

cation Millsime = 1977 et Degr > 13. La question (Q4) dlivre les crus et degrs des
vins de millsime 1977 et de degr compris entre 11 et 13. La question (Q5) retrouve
les crus, annes de production (millsime diminu de 1900) et qualit des Beaujolais.
Elle illustre le prdicat de recherche textuel (LIKE) ; le caractre % signifie dans le
cas du LIKE une quelconque sous-chane de caractres ; par exemple, BEAUJOLAIS
NOUVEAUX et NOUVEAUX BEAUJOLAIS rendent le prdicat CRU LIKE
%BEAUJOLAIS% vrai. La question (Q6) recherche tous les vins de degr nul. La
question (Q7) dlivre les crus des vins de qualit A, B ou C.
(Q3) SELECT
FROM
WHERE
AND

*
VINS
MILLESIME = 1977
DEGRE > 13

(Q4) SELECT
FROM
WHERE
AND

CRU, DEGRE
VINS
MILLESIME = 1977
DEGRE BETWEEN 11 AND 13

(Q5) SELECT
FROM
WHERE

DISTINCT CRU, MILLESIME 1900, QUALITE

VINS
CRU LIKE

(Q6) SELECT
FROM
WHERE

*
VINS
CRU IS NULL

(Q7) SELECT
FROM
WHERE

CRU
VINS
QUALITE IN (A,B,C)

Figure VII.6 : Exemples de slections

3.3. EXPRESSION DES JOINTURES

Un cas particulier simple de jointure sans qualification est le produit cartsien. Celuici sexprime trs simplement en incluant plusieurs relations dans la clause FROM. Par
exemple, le produit cartsien des relations VINS et ABUS se calcule laide de la
question (Q8) reprsente figure VII.7.
(Q8) SELECT
FROM

*
VINS, ABUS

Figure VII.7 : Exemple de produit cartsien

Le langage SQL2 227

La jointure avec qualification peut sexprimer de plusieurs manires. Une premire

expression naturelle est la restriction du produit cartsien par un prdicat permettant
de comparer deux termes. Les prdicats de comparaison (=, , , , <, >), dintervalle
(BETWEEN), dappartenance (IN) et de comparaison textuelle (LIKE) sont utilisables.
La combinaison des oprations de jointures, restrictions et projections peut tre effectue lintrieur dun mme bloc SELECT.
La figure VII.8 illustre diffrents cas de jointures. La question (Q9) effectue la jointure de VINS et ABUS sur lattribut numro de vins (NV) et permet de lister en prfixe de chaque tuple de ABUS le vin correspondant. La question (Q10) recherche les
buveurs ayant un nom similaire celui dun cru. La question (Q11) retourne le nom
des buveurs ayant bu du Chablis, sans double. Notez lusage des variables B, V et A
comme alias des relations BUVEURS, VINS et ABUS, afin dviter de rpter le nom
complet des relations dans le critre.
(Q9) SELECT
FROM
WHERE

*
VINS, ABUS
VINS.NV = ABUS.NV

(Q10) SELECT
FROM
WHERE

NB, NOM
BUVEURS, VINS
NOM LIKE CRU

(Q11) SELECT
FROM
WHERE
AND
AND

DISTINCT NOM
BUVEURS B, VINS V, ABUS A
B.NB = A. NB
A.NV = V.NV
V.CRU = Chablis

Figure VII.8 : Exemples de jointures

3.4. SOUS-QUESTIONS
SQL permet limbrication de sous-questions au niveau de la clause WHERE, si bien
que lon pet crire des questions du type SELECT FROM WHERE SELECT
. En effet, le rsultat dune question peut tre considr comme une valeur simple ou
comme un ensemble de valeurs avec doubles ventuels (multi-ensemble) ; dans ce dernier cas, chaque valeur de lensemble correspond un tuple du rsultat. Ainsi, il est
possible de considrer une sous-question comme argument particulier des prdicats de
comparaison (=, , <, >, , ) et dappartenance une liste (IN). Toute sous-question
peut elle-mme invoquer des sous-questions, si bien quil est possible dimbriquer des
blocs SELECT plusieurs niveaux. Limbrication de blocs SELECT par le prdicat IN
permet dexprimer en particulier des jointures dune manire plus procdurale.

228 BASES DE DONNES : OBJET ET RELATIONNEL

Par exemple, la question (Q12) de la figure VII.9 effectue la jointure des tables VINS
et ABUS sur numro de vin et slectionne les crus des vins rsultants sans double.
Elle est quivalente la question (Q13). Il est aussi possible dutiliser des variables
dfinies dans un bloc interne au niveau dun bloc externe. On parle alors de variable
de corrlation. La question (Q14) illustre lusage dune variable de corrlation pour
retrouver cette fois le cru du vins mais aussi la quantit bue partir de la jointure de
VINS et ABUS. Finalement, la question (Q15) recherche les noms des buveurs de
Chablis. Elle est quivalente la question (Q11), mais est crite de manire plus procdurale avec trois blocs imbriqus.
(Q12) SELECT
FROM
WHERE

DISTINCT CRU
VINS
NV IN
SELECT NV
FROM ABUS

(Q13) SELECT
FROM
WHERE

DISTINCT CRU
VINS V, ABUS A
V.NV = A.NV

(Q14) SELECT
FROM
WHERE

DISTINCT CRU, A.QUANTITE

VINS
NV IN
SELECT NV
FROM ABUS A

(Q15) SELECT
FROM
WHERE

DISTINCT NOM
BUVEURS
NB IN
SELECT NB
FROM
ABUS
WHERE
NV IN
SELECT
FROM
WHERE

NV
VINS
CRU = CHABLIS

Figure VII.9 : Exemples de blocs imbriqus

3.5. QUESTIONS QUANTIFIES

Il est aussi possible de vouloir comparer une expression de valeurs tous les rsultats
dune sous-question ou seulement lune quelconque des valeurs gnres. SQL propose pour cela lusage de sous-questions quantifies par quel que soit (ALL) ou
il existe (ANY ou SOME). Ces quantificateurs permettent de tester si la valeur dun
terme satisfait un oprateur de comparaison avec tous (ALL) ou au moins un (ANY ou

Le langage SQL2 229

SOME) des rsultats dune sous-question. Un prdicat quantifi par ALL est vrai sil
est vrifi pour tous les lments de lensemble. Un prdicat quantifi par ANY ou
SOME est vrai sil est vrifi par au moins un lment de lensemble.
Ainsi, la question (Q16) recherche les noms des buveurs nayant commis que des abus
en quantit suprieure ou gale toutes les quantits bues, alors que la question (Q17)
recherche ceux ayant commis au moins un abus en quantit suprieure ou gale
toutes les quantits bues. La premire naura probablement pas de rponse alors que la
deuxime ditera le nom de la personne ayant effectu le plus gros abus.
SQL offre une autre possibilit de quantification pour tester si le rsultat dune sous
question est vide ou non. Il sagit du prdicat dexistence EXISTS. EXISTS <sousquestion> est vrai si et seulement si le rsultat de la sous-question est non vide. Ainsi,
la question (Q18) recherche les buveurs ayant bu du Volnay alors que la question
(Q19) recherche ceux nayant bu que du Volnay.
(Q16) SELECT
FROM
WHERE
AND

NOM
BUVEURS B, ABUS A
B.NB = A.NB
A.QUANTITE ALL
SELECT
QUANTITE
FROM
ABUS

(Q17) SELECT
FROM
WHERE
AND

B.NOM
BUVEURS B, ABUS A
B.NB = A.NB
A.QUANTITE ANY
SELECT
QUANTITE
FROM
ABUS

(Q18) SELECT
FROM
WHERE

B.NOM
BUVEURS B
EXISTS
SELECT
FROM
WHERE
AND
AND

*
ABUS A, VINS V
A.NV = V.NV
A.NB = B.NB
CRU = VOLNAY

B.NOM
BUVEURS B
NOT EXISTS
SELECT
FROM
WHERE
AND
AND

*
ABUS A, VINS V
A.NV = V.NV
A.NB = B.NB
CRU = VOLNAY

(Q19) SELECT
FROM
WHERE

Figure VII.10 : Exemples de questions quantifies

230 BASES DE DONNES : OBJET ET RELATIONNEL

3.6. EXPRESSION DES UNIONS

SQL1 permet galement dexprimer lopration dunion. Par exemple, lobtention des
crus de degr suprieur 13 ou de millsime 1977 peut seffectuer par la question
(Q20) reprsente figure VII.11.
(Q20) SELECT
FROM
WHERE
UNION
SELECT
FROM
WHERE

CRU
VINS
DEGRE > 13
CRU
VINS
MILLESIME = 1977

Figure VII.11 : Exemple dunion

3.7. FONCTIONS DE CALCULS ET AGRGATS

Au-del de lalgbre relationnelle, des possibilits de calcul de fonctions existent. Les
fonctions implantes sont :
COUNT qui permet de compter le nombre de valeurs dun ensemble ;
SUM qui permet de sommer les valeurs dun ensemble ;
AVG qui permet de calculer la valeur moyenne dun ensemble ;
MAX qui permet de calculer la valeur moyenne dun ensemble ;
MIN qui permet de calculer la valeur moyenne dun ensemble.
Les fonctions peuvent tre utilises dans la clause SELECT, par exemple pour calculer le degr moyen des Chablis comme dans la question (Q21) figure VII.12. Les
fonctions sont aussi utilisables pour effectuer des calculs dagrgats.
Rappelons quun agrgat est un partitionnement horizontal dune table en sous-tables
en fonction des valeurs dun ou de plusieurs attributs de partitionnement, suivi de
lapplication dune fonction de calculs chaque attribut des sous-tables obtenues.
Cette fonction est choisie parmi celles indiques ci-dessus. En SQL, le partitionnement sexprime par la clause :
GROUP BY <SPCIFICATION DE COLONNE>+

Cette dernire permet de prciser les attributs de partitionnement, alors que les fonctions de calculs appliques aux ensembles gnrs sont directement indiques dans les
expressions de valeurs suivant le SELECT.
Une restriction peut tre applique avant calcul de lagrgat au niveau de la clause
WHERE, mais aussi aprs calcul de lagrgat sur les rsultats de ce dernier. Pour cela,
une clause spciale est ajoute la requte SELECT :

Le langage SQL2 231

HAVING <EXPRESSION DE VALEURS>+

La figure VII.12 propose quelques exemples de calculs dagrgats. La question (Q21)

calcule simplement la moyenne des degrs des Chablis. La question (Q22) mixte jointure et agrgat : elle affiche pour chaque cru la somme des quantits bues ainsi que la
moyenne des degrs des vins du cru. Les questions (Q23) et (Q24) combinent agrgats et restrictions : (Q23) calcule la moyenne des degrs pour tous les crus dont le
degr minimal est suprieur 12 ; (Q24) recherche tous les numros de vins bus en
quantit suprieure 10 par plus de 100 buveurs. La question (Q25) dmontre une
combinaison de blocs imbriqus et dagrgats avec restriction portant sur des calculs ;
elle retrouve les noms des buveurs ayant bu depuis 1983 une quantit dalcool suprieur 100.
(Q21) SELECT
FROM
WHERE

AVG(DEGRE)
VINS
CRU = Chablis

(Q22) SELECT CRU, SUM(QUANTITE), AVG(DEGRE)

FROM
VINS V, ABUS A
WHERE
V.NV = A.NV
GROUP BY CRU
(Q23) SELECT CRU, AVG(DEGRE)
FROM
VINS
GROUP BY CRU
HAVING MIN(DEGRE)>12
(Q24) SELECT NV
FROM
ABUS
WHERE
QUANTITE>10
GROUP BY NV
HAVING COUNT(NB)>100
(Q25) SELECT
FROM
WHERE

NOM
BUVEURS
NB IN
SELECT NB
FROM
ABUS A, VINS V
WHERE
A.NV = V.NV
AND
DATE > 01-01-83
GROUP BY NB
HAVING SUM(QUANTITE*DEGRE/100)>100

Figure VII.12 : Exemple de calculs dagrgats

232 BASES DE DONNES : OBJET ET RELATIONNEL

4. SQL1 : LES MISES JOUR

SQL1 offre trois commandes de mise jour : INSERT (insrer), DELETE (supprimer)
et UPDATE (modifier). Toute mise jour seffectue par recherche des tuples modifier et application des modifications. La recherche peut seffectuer directement par une
question intgre dans la commande de mise jour ou pralablement par utilisation
dun curseur depuis un programme traditionnel. Nous dtaillons tout dabord les commandes de mise jour partir de questions. La syntaxe des mises jour est cependant
prcise pour lutilisation de curseurs, que nous verrons dans la section suivante.

4.1. INSERTION DE TUPLES

Linsertion de tuples dans une relation permet de crer de nouvelles lignes. Elle peut
seffectuer soit par fourniture directe au terminal dun tuple insrer (ou dune partie de
tuple, les valeurs inconnues tant positionnes NULL), soit par construction partir
dune question des tuples insrer. La premire variante est linsertion directe, la
deuxime linsertion via question. La syntaxe de la commande dinsertion de SQL1 est :
INSERT INTO <NOM DE TABLE> [(<NOM DE COLONNE> +)]
{VALUES (<CONSTANTE>+) | <COMMANDE DE RECHERCHE>}

Dans le cas o la liste de colonnes nest pas spcifie, tous les attributs de la relation
doivent tre fournis dans lordre de dclaration. Si seulement certaines colonnes sont
spcifies, les autres sont insres avec la valeur nulle.
Une insertion partir dune commande de recherche permet de composer une relation
partir des tuples dune relation existante, par recherche dans la base.
En guise dillustration, la commande dinsertion dun Julinas 1983 de degr inconnu
sous le numro de vins 112 est reprsente figure VII.13 (requte (I1)). Nous donnons
aussi la commande (I2) insrant dans une table BONSBUVEURS tous les buveurs
ayant bu des vins de qualit A. La table BONSBUVEURS de schma (NB, NOM,
PRENOM) a du tre cre auparavant.
(I1) INSERT INTO VINS (NV, CRU, MILLESIME)
VALUE (112, JULIENAS, 1983)
(I2) INSERT
SELECT
FROM
WHERE
AND
AND

INTO BONSBUVEURS
NB, NOM, PRENOM
BUVEURS B, ABUS A, VINS V
B.NB = A.NB
A.NV = V.NV
V.QUALITE = A

Figure VII.13 : Exemples de commandes dinsertion

Le langage SQL2 233

4.2. MISE JOUR DE TUPLES

La mise jour permet de changer des valeurs dattributs de tuples existants. La mise
jour dune relation peut seffectuer soit par fourniture directe des valeurs modifier,
soit par llaboration de ces valeurs partir dune expression. Les seuls tuples mis
jour sont ceux vrifiant une condition de recherche optionnelle fournie en argument
dune clause WHERE. Il est aussi possible de faire une mise jour dun seul tuple
point par un curseur pralablement ouvert.
La syntaxe de la commande de mise jour SQL1 est :
UPDATE <NOM DE TABLE>
SET {<NOM DE COLONNE> = {<EXPRESSION DE VALEUR> | NULL}}+
WHERE {<CONDITION DE RECHERCHE> | CURRENT OF <NOM DE CURSEUR>}

Par exemple, la mise jour du degr du Julinas 1983 par la valeur 13 seffectuera par
la requte (U1). Laccroissement des quantits bues de Volnay 1983 de 10% seffectuera par la commande (U2).
(U1) UPDATE
SET
WHERE

VINS
DEGRE = 13
CRU = JULIENAS AND MILLESIME = 1983

(U2) UPDATE
SET
WHERE

ABUS
QUANTITE = QUANTITE * 1.1
NV IN
SELECT NV
FROM
VINS
WHERE
CRUS = JULIENAS
AND
MILLESIME = 1983

Figure VII.14 : Exemples de commandes de mise jour

4.3. SUPPRESSION DE TUPLES

Lopration de suppression permet denlever dune relation des tuples existants. Les
tuples sont spcifis laide dune condition de recherche, moins que lon dsire
supprimer tous les tuples dune relation. La syntaxe de la commande de suppression
est :
DELETE FROM <NOM DE TABLE>
[WHERE {<CONDITION DE RECHERCHE> | CURRENT OF <NOM DE CURSEUR>}]

Par exemple, la suppression de tous les abus de vins de degr inconnu seffectuera par
la commande (D1), et la suppression de tous les vins bus par MARTIN par la commande (D2).

234 BASES DE DONNES : OBJET ET RELATIONNEL

(D1) DELETE
FROM
WHERE

(D2) DELETE
FROM
WHERE

ABUS
NV IN
SELECT
FROM
WHERE

NV
VINS
DEGRE IS NULL

VINS
NV IN
SELECT NV
FROM BUVEURS, ABUS
WHERE ABUS.NB = BUVEURS.NB
AND BUVEURS.NOM = MARTIN

Figure VII.15 : Exemples de commandes de suppression

5. SQL1 : LA PROGRAMMATION
DE TRANSACTIONS
Une transaction est une squence doprations, incluant des oprations bases de donnes, qui est atomique vis--vis des problmes de concurrence et reprise aprs panne.
Une transaction est gnralement programme dans un langage hte. Dans cette section, nous prsentons les commandes de gestion de transactions incluses dans SQL1 et
lintgration de SQL dans un langage de programmation.

5.1. COMMANDES DE GESTION DE TRANSACTION

Une transaction est initie par un appel de procdure base de donnes, si une transaction nest pas dj active. Elle est termine soit avec succs par un ordre de validation
des mises jour COMMIT WORK, soit en chec suite un problme par un ordre
ROLLBACK WORK. Tout se passe comme si les mises jour taient prpares seulement en mmoire lors des commandes UPDATE, INSERT et DELETE, puis intgres de manire atomique la base de donnes par lordre COMMIT WORK, ou annules par lordre ROLLBACK WORK (voir figure VII.16).

Le langage SQL2 235

Update

Insert

Delete

MMOIRE

Commit Work

Rollback Work

BD

NANT

Figure VII.16 : Terminaison avec succs ou chec dune transaction

5.2. CURSEURS ET PROCDURES

La programmation de transaction dans un langage hte ncessite le travail tuple
tuple. Pour cela, SQL propose la notion de curseur. Un curseur permet de reprer un
tuple dans la base de donnes laide dune commande SELECT et dun balayage
squentiel des tuples rsultats. Il sagit du moyen offert par SQL1 la fois pour
balayer squentiellement les tuples rsultats dune question, et pour reprer un tuple
dans la base. Un curseur est dclar par la commande suivante :
DECLARE <NOM DE CURSEUR> CURSOR
FOR <COMMANDE DE RECHERCHE>
[ORDER BY {<SPCIFICATION DE COLONNE> [{ASC | DESC}]}+]

Lutilisation dun curseur ncessite son ouverture par la commande :

OPEN <NOM DE CURSEUR>.

Cette commande provoque lexcution logique de la question et le positionnement du

curseur sur le premier tuple rsultat. Il est ensuite possible de lire successivement
chaque tuple rsultat et de faire avancer le curseur par la commande :
FETCH <NOM DE CURSEUR> INTO <NOM DE VARIABLE>+

La fin dutilisation dun curseur se signale au systme par la commande :

CLOSE <NOM DE CURSEUR>.

236 BASES DE DONNES : OBJET ET RELATIONNEL

SQL1 permet de composer des modules, eux-mmes composs de procdures constitues dune commande SQL, pouvant inclure des curseurs. Une procdure peut possder des paramtres dappel ou de retour. Elle peut tre excute depuis un langage
hte ou plus gnralement par une commande dappel du type :
EXEC <NOM DE PROCDURE> [(<PARAMTRES>+)].

En guise dillustration, nous avons reprsent figure VII.17 un module dfinissant

trois procdures pour ouvrir, lire et fermer les bons vins (de qualit A). Nous touchons
l lintgration de SQL dans un langage de programmation tel PASCAL, C ou FORTRAN, que nous dtaillerons dans le paragraphe suivant. Les curseurs ont un rle
essentiel pour raliser une telle intgration ; il permettent deffectuer des commandes
de mises jour tuple tuple.
MODULE EXEMPLE
DECLARE BONVIN CURSOR
FOR SELECT NV
FROM VINS
WHERE QUALITE = A ;
PROCEDURE OPENVIN ;
OPEN BONVIN ;
PROCEDURE NEXTVIN(NV) NV INTEGER ;
FETCH BONVIN INTO NV ;
PROCEDURE CLOSEVIN ;
CLOSE BONVIN ;

Figure VII.17 : Exemple de module

5.3. INTGRATION DE SQL ET DES LANGAGES

DE PROGRAMMATION
Lintgration de SQL un langage procdural tel que C, COBOL, FORTRAN, PASCAL ou PL1 pose diffrents problmes :
1. Lexploitation tuple tuple des rsultats des requtes ncessite lusage de curseurs.
La commande FETCH est alors utilise dans une boucle pour lire un un les tuples
rsultats. Des commandes de mises jour avec loption de recherche WHERE
CURRENT OF <nom de curseur> peuvent tre employes pour les mises jour.
2. Les variables du langage de programmation doivent tre passes au SGBD par
lintermdiaire des requtes SQL. Toute constante peut ainsi tre remplace par une
variable de programmation qui doit tre dclare dans une section de dclaration de
variables SQL. Un rsultat peut tre assign une variable de programme dclare
SQL en liste rsultat de lordre FETCH.

Le langage SQL2 237

La figure VII.18 donne un exemple de programme PASCAL utilisant SQL. Ce programme ajoute un abus la base pour les buveurs de Lyon ayant particip une
rception le 10-08-96. Ceux-ci sont dtermins par interrogation de lutilisateur qui
doit rpondre O (oui) suite laffichage du nom du buveur si celui-ci a particip la
rception. Il doit alors prciser la quantit bue ce jour par le buveur. Le vin bu est
dtermin par la constante numvin.
PROGRAM EXEMPLE
REPONSE STRING ;
RECORD TYPE BUVEUR
NB INTEGER ;
NOM STRING ;
PRENOM STRING ;
END RECORD ;
EXEC SQL DECLARE SECTION END EXEC ;
CONS NUMVIN = 100 ;
VAR B BUVEUR ;
VAR QUANTIT INTEGER ;
VAR CODE SQLCODE ;
EXEC SQL END DECLARE SECTION END EXEC ;
EXEC SQL DECLARE CURSOR PARTICIPANT FOR
SELECT NB, NOM, PRENOM
FROM BUVEURS
WHERE ADRESSE LIKE %LYON%
END EXEC ;
BEGIN
EXEC SQL OPEN PARTICIPANT END EXEC ;
WHILE CODE 100 DO
BEGIN
EXEC SQL FETCH PARTICIPANT INTO B END EXEC ;
PRINT NOM :, B.NOM, PRENOM, B.PRENOM ;
PRINT CE BUVEUR A-T-IL PARTICIP ?
READ REPONSE ;
IF REPONSE = O THEN
BEGIN
PRINT QUANTIT ? ;
READ QUANTIT ;
EXEC SQL INSERT INTO ABUS
(B.NB, NUMVIN, 10-08-96, QUANTIT) END EXEC ;
END ;
END ;
EXEC SQL CLOSE PARTICIPANT END EXEC ;
END.

Figure VII.18 : Exemple de programme intgrant des commandes SQL

En conclusion, on notera la lourdeur des programmes intgrant SQL un langage de

programmation. Ceci rsulte tout dabord de la diffrence de point de vue entre le

238 BASES DE DONNES : OBJET ET RELATIONNEL

modle relationnel qui supporte des requtes ensemblistes et les langages classiques
qui sont avant tout squentiels. Ces derniers permettent seulement dcrire des programmes traitant un tuple (record) la fois. Do la ncessit de boucles complexes.
La complexit rsulte aussi de lexistence de deux systmes de dfinition de types diffrents, dans notre exemple celui de PASCAL (RECORD TYPE) et celui de SQL
(CREATE TABLE). Do la ncessit de doubles dclarations. Tout ces problmes
sont souvent mieux rsolus au niveau des langages de 4e gnration, qui malheureusement ne sont pas standardiss.

6. SQL2 : LE STANDARD DE 1992

SQL2 [ISO92] est une extension de SQL1 devenu le standard daccs aux bases de
donnes relationnelles depuis 1992. Compte tenu de la complexit de SQL2 qui se
veut trs complet, trois niveaux sont distingus :
1. SQL2 entre est avant tout une correction de la norme SQL1 de 1989 et un complment avec les commandes manquantes indispensables.
2. SQL2 intermdiaire apporte les complments relationnels indispensables au support complet du modle et de lalgbre ainsi que des types de donnes plus varis.
3. SQL2 complet apporte des types de donnes encore plus varis et quelques complments non indispensables.
Dans la suite, nous dtaillons successivement ces trois niveaux supplmentaires de
SQL. Ils sont en principe des extensions compatibles de SQL1.

6.1. LE NIVEAU ENTRE

SQL2 entre propose une standardisation des codes rponses en ajoutant une variable
retour des commandes appeles SQLSTATE. En effet, avec SQL1 un seul code
rponse est retourn dans une variable de type SQLCODE. Trois valeurs sont spcifies : 0 pour excution correcte, +100 pour absence de donnes et une valeur ngative n pour toute erreur, la valeur tant spcifie par le concepteur du SGBD. Cela
rend les programmes non portables. Afin daugmenter la portabilit, un code retour
SQLSTATE est ajout (SQLCODE est gard afin dassurer la compatibilit avec
SQL1). Le code SQLSTATE est compos de deux caractres spcifiant la classe
derreur (par exemple 22 pour exception erreurs sur les donnes) et de trois caractres
prcisant la sous-classe (par exemple, 021 pour caractre invalide). Les codes classes
et sous-classes sont partiellement standardiss.

Le langage SQL2 239

Avec SQL2, il est possible de renommer des colonnes rsultats. Cette fonctionnalit est
trs utile, par exemple lors du calcul dun agrgat. Avec SQL1, la colonne de la table
rsultat prend souvent un nom dpendant du systme. La clause AS de SQL2 permet de
rsoudre ce problme. Par exemple, une question calculant la moyenne des degrs par
crus pourra maintenant spcifier un nom de colonne rsultat MOYENNE comme suit :
SELECT CRU, AVG(DEGRE) AS MOYENNE
FROM
VINS
GROUP BY CRU

Un autre ajout propos SQL1 au niveau de SQL2 entre est la possibilit dutiliser
les mots cls de SQL comme des noms de table, dattributs, etc. Pour ce faire, il suffit
dinclure ces mots cls entre double cotes. Par exemple, on pourra crer une table de
nom SELECT par la commande :
CREATE TABLE SELECT (QUESTION CHAR(100)).

En rsum, les extensions de SQL1 proposes au niveau de SQL2 entre sont donc
des corrections et clarifications ncessaires au langage. SQL2 entre est donc le nouveau standard minimal que devrait terme fournir les constructeurs de SGBD. Il permettra une meilleure portabilit des programmes. Linterface avec C est dailleurs
aussi prcise au niveau de SQL2 entre.

6.2. LE NIVEAU INTERMDIAIRE

6.2.1. Les extensions des types de donnes
SQL2 intermdiaire offre un meilleur support du temps. Trois nouveaux types de donnes DATE, TIME et TIMESTAMP sont introduits. Le type DATE est spcifi pour un
attribut contenant une anne, un mois et un jour (par exemple 1992/08/21). Le type
TIME correspond un groupe heures, minutes et secondes (par exemple, 09 :17 :23).
Le type TIMESTAMP correspond une concatnation dune date et dune heure
(DATE concatn TIME). SQL2 offre galement un type de donnes permettant de
spcifier un intervalle de temps (INTERVAL) avec une prcision en mois-anne ou en
seconde-minute-heure-jour.
Les oprations arithmtiques daddition et soustraction sur les dates-heures et intervalles sont supportes avec SQL2. Il est aussi possible de multiplier ou diviser des
intervalles par des valeurs numriques. Par exemple, en supposant lattribut DATE de
la table ABUS dfini comme une date, il est possible de retrouver tous les abus commis dans un intervalle de temps de N mois (N est de type intervalle) par rapport la
date du 21-08-96 par la question suivante :
SELECT
FROM
WHERE

*
ABUS
DATE 21/08/1996 < N

240 BASES DE DONNES : OBJET ET RELATIONNEL

SQL2 admet galement la cration de domaines par lutilisateur. Cela permet en particulier lintroduction de types de donnes par lutilisateur au sein du modle avec un
meilleur contrle de lintgrit de domaine ; ces types restent en SQL2 purement des
sous-ensembles des types prdfinis ; aucune opration spcifique ne peut leur tre
associe. Par exemple, la cration dun domaine MONNAIE seffectuera par la commande :
CREATE DOMAINE MONNAIE IS DECIMAL(5,2)
DEFAULT (1)
CHECK (VALUE = 1 OR VALUE > 0)
NOT NULL

Ce domaine pourra tre utilis lors dune cration de table. Il sagit essentiellement
dune macro-dfinition permettant dinclure les contrles dintgrit, par exemple
dans une table FACTURE :
CREATE TABLE FACTURE (NOM CHAR(5), MONTANT MONNAIE)

Dautres extensions sont proposes pour un meilleur support de types de donnes

varis. On citera en particulier :
le support de multiples alphabets et ensembles de caractres (CHARACTER SET) ;
le support de diffrents ordres des lettres (COLLATE) ;
la possibilit de concatner des chanes de caractres (||) et d extraire des souschanes (SUBSTRING) ;
les facilits de conversion de types de donnes (CAST) ;
les chanes de caractres de longueur variables (CHAR VARYING) et la possibilit
dextraire la longueur dune chane (fonction LENGTH).

6.2.2. Un meilleur support de lintgrit

Lintgrit rfrentielle est supporte en SQL1, mais toute tentative de violation
entrane le rejet de la mise jour. Au contraire, SQL2 intermdiaire permet de spcifier certaines actions correctives en cas de violation dintgrit lors dune suppression
dun tuple rfrenc, selon les options :
cascader les suppressions (ON DELETE CASCADE),
rendre nul lattribut rfrenant (ON DELETE SET NULL).
Loption doit tre prcise lors de la dfinition de la contrainte rfrentielle dans la
table rfrenante.
Plus gnralement, les contraintes dintgrit peuvent tre nommes lors de leurs dfinitions. La validation des contraintes dintgrit peut tre immdiate la fin de
chaque opration ou diffre en fin de transaction. Ceci est indiqu par une clause :
SET CONSTRAINTS <NOM DE CONTRAINTE>+ {DEFERRED | IMMEDIATE}

Le langage SQL2 241

Le nom de contrainte ALL indique que toutes les contraintes sont concernes.
Diffrents niveaux de contrle de transactions sont aussi possibles. Une clause
SET TRANSACTION <MODE>

est introduite, permettant de prciser le niveau disolation dsir (0 = aucune pour lecture non protge, 1 = criture protge, lecture non protge, 2 = criture et lecture
protges, 3 = criture et lecture exclusives), le mode daccs (lecture seule READ
ONLY, ou lecture-criture READ-WRITE), et le nombre de diagnostics possibles.

6.2.3. Une intgration tendue de lalgbre relationnelle

Lalgbre relationnelle offre les oprations ensemblistes dunion, intersection et diffrence de relations. SQL1 ne supporte que lunion. SQL2 gnralise les expressions de
SELECT en introduisant intersection (INTERSECT) et diffrence (EXCEPT). Des
expressions parenthses de SELECT sont mme possibles. De plus, lunion est gnralise lunion externe, avec complment des schmas des relations au mme
schma par ajout de valeurs nulles aux tuples, cela pralablement lunion proprement dite.
Afin dillustrer ces possibilits, imaginons une table NONBUVEURS (NB, NOM,
PRENOM, ADRESSE), complmentaire de la table BUVEURS(NB, NOM, PRENOM, ADRESSE, TYPE). La requte suivante construit une table contenant
buveurs et non buveurs avec un type nul, lexception des gros buveurs :
SELECT
*
FROM
NONBUVEURS
OUTER UNION
(SELECT
*
FROM
BUVEURS
EXCEPT
SELECT
*
FROM
BUVEURS
WHERE
TYPE = GROS)

Les jointures externes sont utiles pour retenir lors dune jointure les tuples dune table
nayant pas de correspondant dans lautre table, avec des valeurs nulles associes. On
distingue ainsi des jointures externes droite, gauche et complte selon que lon retient
les tuples sans correspondant des deux tables ou seulement dune. Rappelons aussi
quune jointure est dite naturelle si elle porte sur des attributs de mme nom. SQL2
offre la possibilit de spcifier de telles jointures au niveau de la clause FROM, selon
la syntaxe suivante :
FROM <NOM DE TABLE> [NATURAL] [{LEFT | RIGHT}]
JOIN <NOM DE TABLE>
[ON (<SPCIFICATION DE COLONNE>+=<SPCIFICATION DE COLONNE>+)]

242 BASES DE DONNES : OBJET ET RELATIONNEL

On peut par exemple retrouver la somme des quantits bues par chaque buveur, y
compris les buveurs nayant pas bu par la requte suivante :
SELECT
FROM
GROUP BY

NB, NOM, SUM(QUANTITE)

BUVEURS NATURAL LEFT JOIN ABUS
NB

6.2.4. La possibilit de modifier les schmas

SQL2 permet de modifier un schma de table laide de la commande :
ALTER TABLE <nom de table> <altration>

Diffrents types daltrations sont possibles :

ajout dune colonne (ADD COLUMN)
modification de la dfinition dune colonne (ALTER COLUMN)
suppression dune colonne (DROP COLUMN)
ajout dune contrainte (ADD CONSTRAINT)
suppression dune contrainte (DROP CONSTRAINT).
Par exemple, lajout de lattribut REGION la table VINS pourra seffectuer par la
commande :
ALTER TABLE VINS ADD COLUMN REGION CHAR VARYING.

6.2.5. Lexcution immdiate des commandes SQL

Avec SQL1, toute commande SQL est compile puis excute depuis un programme
dapplication. Les processus de compilation et dexcution sont spars et non contrls. Au contraire, SQL2 supporte une option dynamique incluant les possibilits
dexcution diffre ou immdiate, cette dernire tant utile par exemple en interactif.
Des commandes PREPARE <commande SQL> et EXECUTE [IMMEDIATE] <commande SQL> sont introduites afin de permettre lexcution immdiate (EXECUTE
IMMEDIATE) ou la compilation puis lexcution de multiples fois partir du rsultat
de la compilation (PREPARE suivi de plusieurs EXECUTE). Tous ces aspects de mode
de fonctionnement sont ainsi intgrs au langage.

6.3. LE NIVEAU COMPLET

SQL2 offre un niveau complet (FULL SQL2) qui comporte en plus les fonctionnalits
suivantes :
type de donnes chanes de bits (BIT) pour supporter des objets complexes tels des
images ;

Le langage SQL2 243

extension du support des dates et temps, notamment avec la possibilit de dfinir

des zones dheures, des intervalles de temps dchelles varies, etc. ;
expressions de requtes SELECT tendues avec correspondances de colonnes possibles ; par exemple, lors dune union deux colonnes de nom diffrents peuvent tre
transformes en une seule colonne ;
support de tables temporaires prives dtruites en fin de transaction ;
possibilit de SELECT en argument dun FROM afin de construire une table temporaire lintrieur dune requte SQL ;
maintenance de vues concrtes facilitant linterrogation de vues peu modifies,
notamment de vues avec agrgats ;
support de contraintes dintgrit multitables laide de sous-questions intgrables
dans la clause CHECK de dclaration de contraintes.
Ces multiples extensions et quelques autres, par exemple pour gnraliser la maintenance automatique des contraintes rfrentielles lors des mises jour, font de SQL2
complet un langage plutt complexe pour manipuler des bases de donnes relationnelles. La spcification de SQL2 comporte 522 pages de syntaxe.

7. CONCLUSION
Le standard SQL2 est adopt depuis 1992 par les organismes de standardisation internationaux (ISO). Une large extension appele SQL3 est en cours de finition et devrait
tre adopte en 1999. SQL3 intgre les fonctionnalits nouvelles non purement relationnelles. En particulier, sont traites au niveau de SQL3 les fonctionnalits orientes
objet, le support de questions rcursives et le support de rgles dclenches par des
vnements bases de donnes (en anglais, triggers). Les fonctionnalits orientes
objet sont offertes sous forme de constructeurs de types abstraits de donnes permettant la dfinition dobjets complexes par lutilisateur. Les questions rcursives permettent dintgrer loprateur de fermeture transitive SQL. Une syntaxe est propose
pour dfinir des triggers. Ces fonctionnalits seront tudies dans les chapitres qui
suivent. Plus spcifiquement, SQL3 se veut le langage des SGBD objet-relationnel ;
ce titre, nous ltudierons donc dans la troisime partie de cet ouvrage.
En rsum, SQL est un langage standardis de programmation de bases de donnes.
Bien qu lorigine issu du modle relationnel, SQL est aujourdhui un langage qui
couvre un spectre plus large. Les standards SQL1, SQL2 et SQL3 traitent de
lensemble des aspects des bases de donnes, dont la plupart seront tudis dans la
suite. SQL sert aussi de langage dchange de donnes entre SGBD. Cela explique
donc son trs grand succs, qui se traduit par le fait que tous les SGBD offrent une

244 BASES DE DONNES : OBJET ET RELATIONNEL

variante de SQL. La normalisation du langage assure une bonne portabilit des programmes bases de donnes. Elle a t possible grce au soutient des grands constructeurs, tels IBM, DEC, ORACLE et SYBASE.
Certains critiquent le manque de rigueur et de cohrence de SQL [Date84]. Il est vrai
que lensemble peut paratre parfois htroclite. La syntaxe est souvent lourde. Quoi
quil en soit, SQL est et reste la rfrence. Il est le langage de nombreux systmes
commercialiss tels Oracle, DB2, Sybase, Informix et SQL Server.

8. BIBLIOGRAPHIE
[Boyce75] Boyce R., Chamberlin D.D., King W.F., Hammer M., Specifying Queries
as Relational Expressions , Comm. de lACM, vol. 18, n 11, novembre 1975.
Une prsentation du language SQUARE qui permet dexprimer en anglais simplifi des expressions de lalgbre relationnelle. SQUARE est lorigine du
langage SQL.
[Chamberlin76] Chamberlin D.D., Astrahan M.M., Eswaran K.P., Griffiths P., Lorie
R.A, et al., SEQUEL 2 : A Unified Approach to Data Definition,
Manipulation and Control , IBM Journal of Research and Development,
vol. 20, n 6, novembre 1976.
Cet article dcrit la deuxime version du langage SEQUEL, le langage du
fameux systme R, le premier SGBD relationnel prototyp IBM San-Jos de
1974 1980. Pendant cette priode, luniversit de Berkeley ralisait INGRES.
SEQUEL 2 tend SEQUEL 1 avec des constructions drives de QUEL le
langage de INGRES et permet de paraphraser en anglais les expressions de
lalgbre. Il introduit aussi les commandes de description et contrle de donnes et constitue en cela un langage unifi. Cest en tout cas un langage assez
proche de SQL1.
[Date84] Date C.J., A Critique of the SQL Database Language , ACM SIGMOD
Record, vol. 14, n 3, novembre 1984.
Chris Date, qui vient de quitter IBM en cette fin de 1984, critique la cohrence
du langage SQL et dmontre quelques insuffisances.
[Date89] Date C.J., A Guide to the SQL Standard, 2e dition, Addison-Wesley,
Reading, Mass., 1989.
Une prsentation didactique du standard SQL, avec beaucoup dexemples.
[IBM82] IBM Corporation, SQL/Data System Terminal Users Guide , IBM Form
Number SH24-5017-1, 1982.

Le langage SQL2 245

La prsentation du langage du systme SQL/DS dIBM, disponible sur

DOS/VSE. Il sagit de la premire implmentation commercialise du langage
SQL.
[IBM87] IBM Corporation, Systems Application Architecture (SAA) : Common
Programming Interface, Database Reference , IBM Form Number SC26-43480, 1987.
La dfinition du standard de convergence des systmes IBM supportant SQL,
dans le cadre de larchitecture unifie SAA. En principe, tous les systmes IBM
raliss dans des centres diffrents (DB2, SQL/DS, SQL AS/400, SQL OS2) ont
converg ou convergeront vers un mme langage dfini dans ce document, trs
proche de la norme SQL1.
[ISO89] International Organization for Standardization, Information Processing
Systems Database Language SQL with Integrity Enhancement ,
International Standard ISO/IEC JTC1 9075 : 1989(E), 2e dition, avril 1989.
Ce document de 120 pages prsente la norme SQL1 : concepts de base, lments communs, langage de dfinition de schmas, dfinition de modules de
requtes, langage de manipulation. Toute la grammaire de SQL1 est dcrite en
BNF. Ce document rsulte de la fusion du standard de 1986 et des extensions
pour lintgrit de 1989.
[ISO92] International Organization for Standardization, Database Language SQL ,
International Standard ISO/IEC JTC1/SC21 Doc. 9075 N5739, 1992.
Ce document de 522 pages prsente la norme SQL2 : dfinitions, notations et
conventions, concepts, expressions de scalaires, expressions de questions, prdicats, langage de dfinition et manipulation de schmas, langage de manipulation de donnes, langage de contrle, SQL dynamique, SQL intgr un langage, codes rponses, etc. Les niveaux entre et intermdiaire sont clairement
distingus. Lensemble constitue un document trs complet qui doit tre accept
par lISO en 1992. Lapprobation de cette nouvelle norme demande un vote
positif de 75% des corps reprsentatifs de lISO dans les diffrents pays habilits.
[Melton96] Melton J., An SQL3 Snapshot , Proc. Int. Conf. On Data Engineering,
IEEE Ed., p. 666-672, 1996.
Ce bref article donne un aperu du langage SQL3 tel quil tait en 1996. SQL3
est la nouvelle version de SQL pour les systmes objet-relationnel. Nous tudierons la version actuelle de SQL3 plus loin dans cet ouvrage. J. Melton tait
cette poque le responsable de la normalisation de SQL.
[Shaw90] Shaw Ph., Database Language Standards : Past, Present, and Future ,
Lecture Notes in Computer Science, n 466, Database Systems of the 90s,
A. Blaser Ed., Springer Verlag, novembre 1990.

246 BASES DE DONNES : OBJET ET RELATIONNEL

Cet article fait le point sur les efforts de standardisation de SQL. Il rsume les
dveloppements passs en matire de standardisation des bases de donnes et
introduit les propositions SQL2 et SQL3. Les niveaux de SQL2 sont particulirement dvelopps et illustrs par des exemples. Phil Shaw tait cette poque
le responsable de la normalisation de SQL.
[X/Open92] X/Open Group, Structured Query Language (SQL) Common
Application Environment CAE Specification C201, septembre 1992.
Ce document est une prsentation du langage SQL2 labore par lX/OPEN
Group.
[Zook77] Zook W. et al., INGRES Reference Manual , Dept. of EECS, University
of California, Berkeley, CA, 1977.
Ce document dcrit les interfaces externes de la premire version dINGRES et
plus particulirement le langage QUEL.
[Zloof77] Zloof M., Query-by-Example : A Data Base Language , IBM Systems
Journal, vol. 16, n 4, 1977, p. 324-343.
Cet article prsente QBE, le langage par grille propos par Zloof, alors chercheur IBM. Ce langage bidimensionnel est aujourdhui oprationnel en surcouche de DB2 et aussi comme interface externe du systme Paradox de
Borland. Zloof discute aussi des extensions bureautiques possibles, par
exemple pour grer le courrier (OBE).

Chapitre VIII

INTGRIT ET BD ACTIVES

1. INTRODUCTION
Un SGBD doit garantir la cohrence des donnes lors des mises jour de la base. En
effet, les donnes dune base ne sont pas indpendantes, mais obissent des rgles
smantiques appeles contraintes dintgrit. Ces rgles peuvent tre dclares
explicitement et mmorises dans le dictionnaire de donnes, ou plus discrtement
implicites. Les transactions sont des groupes de mises jour dpendantes qui font passer la base dun tat cohrent un autre tat cohrent. la fin de chaque transaction,
ou plus radicalement aprs chaque mise jour, il est ncessaire de contrler
quaucune rgle dintgrit nest viole.
Une contrainte dintgrit peut spcifier lgalit de deux donnes ; par exemple, un
numro de vins dans la table VINS doit tre gal au numro du mme vin dans la
table ABUS. De manire plus complexe, elle peut spcifier une assertion comportant
de multiples donnes ; par exemple, la somme des avoirs des comptes doit rester gale
lavoir de la banque. Nous tudions ci-dessous les diffrents types de contraintes
supportes par le modle relationnel. Quelle que soit la complexit de la contrainte, le
problme est de rejeter les mises jour qui la violent. Pour ce faire, diffrentes techniques sont possibles, fondes soit sur la prvention qui consiste empcher les mises
jour non valides de se produire, soit sur la dtection impliquant de dfaire les transactions incorrectes.

248 BASES DE DONNES : OBJET ET RELATIONNEL

Une autre manire de protger lintgrit des donnes est lutilisation de dclencheurs (en anglais, triggers). Ceux-ci permettent de dclencher une opration consquente suite une premire opration sur la base. La forme gnrale dun dclencheur
est ON <vnement> IF <condition> THEN <action>. Lvnement est
souvent une action de mise jour de la base. La condition est un prdicat logique vrai
ou faux. Laction peut permettre dinterdire la mise jour (ABORT) ou de la compenser (UPDATE). Ainsi, en surveillant les mises jour et en dclenchant des effets de
bord, il est possible de maintenir lintgrit dune base.
Mieux, les dclencheurs permettent de modliser au sein de la base de donnes le
comportement ractif des applications. Les SGBD traditionnels sont passifs, en ce
sens quils excutent des commandes de mises jour et de recherche en provenance
des applications. Avec des dclencheurs, ils deviennent actifs et sont capables de
ragir des vnements externes. Par exemple, la surveillance dun commerce lectronique peut ncessiter le refus de vente un client suspect, une demande dapprovisionnement en cas de rupture de stock, etc. Tous ces vnements peuvent tre capturs
directement par le SGBD avec des dclencheurs appropris. On passe alors la notion
de base de donnes actives, qui peut comporter des rgles avec conditions dclenches par des vnements composes de plusieurs sous-vnements (par exemple, une
conjonction dvnements simples). Une base de donnes active permet donc de
dplacer le comportement ractif des applications dans le SGBD. Ceci ncessite la
prise en compte dun modle de dfinition de connaissances et dun modle dexcution de rgles au sein du SGBD. Nous examinerons ces aspects dans la deuxime partie de ce chapitre.
Ce chapitre traite donc des rgles dintgrit et des bases de donnes actives. Aprs
cette introduction, la section 2 examine les diffrents types de contraintes dintgrit
et rsume le langage de dfinition de contraintes de SQL2. La section 3 introduit
quelques techniques danalyse (contrle de cohrence, de non-redondance) de
contraintes et quelques techniques de simplification : simplifications possibles compte
tenu du type dopration, diffrenciations en considrant les delta-relations, etc. La
section 4 montre comment contrler les contraintes lors des mises jour : diverses
techniques curatives ou prventives sont tudies, pour aboutir la technique prventive au vol souvent applique pour les contraintes simples exprimables en SQL. La
section 5 introduit les notions de base de donnes active et de dclencheur, et analyse
les composants dun SGBD actif. La section 6 tudie plus en dtail les dclencheurs et
donne lessentiel de la syntaxe SQL3, les dclencheurs napparaissant qu ce niveau
dans la norme. La section 7 montre comment sont excuts les dclencheurs dans un
SGBD actif. Au-del de SQL, elle soulve quelques problmes pineux lis aux
dclencheurs.

Intgrit et BD actives 249

2. TYPOLOGIE DES CONTRAINTES

DINTGRIT
Dans cette section, nous tudions les diffrents types de contraintes dintgrit.
Celles-ci sont classes selon leur utilisation modliser des relations statiques entre
donnes, ou des relations dynamiques dvolution des donnes. un second niveau,
nous numrons les diffrents types de contraintes.

2.1. CONTRAINTES STRUCTURELLES

Une contrainte structurelle fait partie intgrante du modle et sapplique sur les
structures de base (table, colonne, ligne).
Notion VIII.1 : Contrainte structurelle (Structural constraint)
Contrainte dintgrit spcifique un modle exprimant une proprit fondamentale dune structure
de donnes du modle.

Les contraintes structurelles sont gnralement statiques. Pour le modle relationnel,

elles permettent dexprimer explicitement certaines proprits des relations et des
domaines des attributs. Ces contraintes sont donc partie intgrante du modle et ont
dj t introduites lors de sa prsentation. Il est possible de distinguer les contraintes
structurelles suivantes :
1. Unicit de cl. Elle permet de prciser les attributs cls dune relation, cest--dire
un groupe dattributs non nul dont la valeur permet de dterminer un tuple unique
dans une table. Par exemple, la table VINS possde une cl unique NV ; la table
ABUS possde une cl multiple (NV, NB, DATE).
2. Contrainte rfrentielle. Elle spcifie que toute valeur dun groupe de colonnes
dune table doit figurer comme valeur de cl dans une autre table. Une telle
contrainte reprsente une association obligatoire entre deux tables, la table rfrence correspondant lentit, la table rfrenante lassociation. Par exemple, toute
ligne de la table ABUS rfrencera un numro de vin existant dans la table VINS,
ou toute ligne de commande rfrencera un produit existant, etc.
3. Contrainte de domaine. Ce type de contrainte permet de restreindre la plage de
valeurs dun domaine. En gnral, un domaine est dfini par un type et un ventuel
domaine de variation spcifi par une contrainte de domaine. Une contrainte de
domaine peut simplement prciser la liste des valeurs permises (dfinition en extension) ou une plage de valeurs (contrainte en intention). Par exemple, un cru sera
choisi parmi {Volnay, Beaujolais, Chablis, Graves, Sancerre} ; une quantit de vin
sera comprise entre 0 et 100.

250 BASES DE DONNES : OBJET ET RELATIONNEL

4. Contrainte de non nullit. Une telle contrainte spcifie que la valeur dun attribut
doit tre renseigne. Par exemple, le degr dun vin ne pourra tre nul, et devra
donc tre document lors de linsertion dun vin dans la base, ou aprs toute mise
jour.
Le choix des contraintes structurelles est effectu lors de la dfinition dun modle.
Codd a par exemple retenu la notion de cl compose dattributs visibles lutilisateur pour identifier les tuples dans une table. Ce choix est plutt arbitraire. Le modle
objet a choisi dutiliser des identifiants systme appels identifiants dobjets. Codd
aurait pu retenir les identifiants de tuples invariants (TID) pour identifier les tuples.
On aurait alors un modle relationnel diffrent, mais ceci est une autre histoire. Au
contraire, dans sa premire version, le modle relationnel nintroduisait pas les
contraintes rfrentielles : elles ont t ajoutes en 1981 pour rpondre aux critiques
des tenants du modle rseau, qui trouvaient que le modle relationnel perdait la
smantique des associations [Date81].

2.2. CONTRAINTES NON STRUCTURELLES

Les autres contraintes dintgrit, non inhrentes au modle de donnes, sont regroupes dans la classe des contraintes non structurelles. La plupart traitent plutt de
lvolution des donnes suite aux mises jour ; elles sont souvent appeles
contraintes de comportement.
Notion VIII.2 : Contrainte de comportement (Behavioral constraint)
Contrainte dintgrit exprimant une rgle dvolution que doivent vrifier les donnes lors des
mises jour.

Certaines contraintes structurelles peuvent aussi tre qualifies de contraintes de comportement (par exemple lunicit de cl). Quoi quil en soit, par opposition aux
contraintes structurelles, les non structurelles ne font pas partie intgrante du modle
relationnel, et ne sont donc pas dfinies dans la commande CREATE TABLE. Elles
sont dfinies par la commande additionnelle CREATE ASSERTION. Dans le cas du
modle relationnel, la plupart peuvent tre exprimes sous forme dassertions de la
logique du premier ordre, ventuellement temporelles. On distingue en particulier :
1. Les dpendances fonctionnelles. Celles-ci expriment lexistence dune fonction
permettant de dterminer la valeur dun groupe dattributs partir de celle dun
autre groupe. Comme nous le verrons dans le chapitre sur la conception, on dit que
X Y (X dtermine Y) si pour toute valeur de X il existe une valeur unique de Y
associe. Par exemple, le cru dtermine uniquement la rgion (dans une table de
vins franais).

Intgrit et BD actives 251

2. Les dpendances multivalues. Ce sont une gnralisation des prcdentes au cas

de fonctions multivalues. On dit que X->> Y (X multidtermine Y) dans une relation R si pour toute valeur de X il existe un ensemble de valeur de Y, et ceci indpendamment des valeurs des autres attributs Z de la relation R. Par exemple, dans
une relation BUVEURS (NOM, CRU, SPORT) dcrivant les vins bus (CRU) et les
sports pratiqus (SPORT) par les buveurs, NOM >> CRU indpendamment de
SPORT.
3. Les dpendances dinclusion. Elles permettent de spcifier que les valeurs dun
groupe de colonnes dune table doivent rester incluses dans celles dun groupe de
colonnes dune autre table. Elles gnralisent donc les contraintes rfrentielles
vues ci-dessus aux cas de colonnes quelconques. Par exemple, la colonne VILLE
de la table BUVEURS doit rester incluse dans la colonne VILLE de la table
REGION.
4. Les contraintes temporelles. Plus sophistiques que les prcdentes, elles font
intervenir le temps. Elles permettent de comparer lancienne valeur dun attribut
la nouvelle aprs mise jour. On exprimera par exemple avec une telle contrainte le
fait quun salaire ne peut que crotre.
5. Les contraintes quationnelles. Il sagit l de comparer deux expressions arithmtiques calcules partir de donnes de la base et de forcer lgalit ou une ingalit.
La dimension temporelle peut tre prise en compte en faisant intervenir des donnes
avant et aprs mise jour. Les calculs dagrgats sont aussi possibles. Un exemple
simple est une contrainte permettant dexprimer, dans une base de gestion de
stocks, le fait que la quantit en stock est gale la somme des quantits achetes
moins la somme des quantits vendues, et ce pour tout produit. Il est aussi possible
dexprimer des invariants en utilisant la dimension temps, par exemple le fait que
lavoir dune banque reste le mme aprs un transfert de fonds dun compte un
autre.
Nous regroupons sous le terme dpendances gnralises les diffrents types de
dpendances entre attributs (dpendances fonctionnelles, multivalues et dinclusion).
Trs utiles pour la conception des bases de donnes, elles permettent de mieux contrler les redondances au sein des relations.

2.3. EXPRESSION DES CONTRAINTES EN SQL

SQL1 permet la cration de contraintes lors de la cration des tables, par la commande indique figure VIII.1. On retrouve les contraintes de non nullit, dunicit de
cl, rfrentielles et de domaines. Les contraintes mono-attributs peuvent tre dclares chaque attribut, alors que les celles portant sur plusieurs attributs, appeles
contraintes de relation, sont factorises la fin de la dclaration. La figure VIII.2
illustre de telles contraintes classiques pour la table ABUS.

252 BASES DE DONNES : OBJET ET RELATIONNEL

CREATE TABLE <nom de table>

({<Attribut> <Domaine> [<CONTRAINTE DATTRIBUT>]}+)
[<CONTRAINTE DE RELATION>]
<CONTRAINTE DATTRIBUT> ::=
NOT NULL |
UNIQUE | PRIMARY KEY
REFERENCES <Relation> (<Attribut>) |
CHECK <Condition>
<CONTRAINTE DE RELATION> ::=
UNIQUE (<Attribut>+) | PRIMARY KEY (<Attribut>+) |
FOREIGN KEY (<Attribut>+)
REFERENCES <Relation> (<Attribut>+) |
CHECK <Condition>

Figure VIII.1 : Cration de table et contrainte dintgrit en SQL1

CREATE TABLE ABUS (

NB INT NOT NULL,
NV INT NOT NULL REFERENCES VINS(NV),
DATE DEC(6) CHECK BETWEEN 010180 AND 311299,
QUANTITE SMALLINT DEFAULT 1,
PRIMARY KEY(NB, NV, DATE),
FOREIGN KEY NB REFERENCES BUVEURS,
CHECK (QUANTITE BETWEEN 1 AND 100))

Figure VIII.2 : Exemple de cration de table avec contrainte en SQL1

SQL2 tend dune part les contraintes attaches une table et permet de dclarer
dautres contraintes par une commande spare CREATE ASSERTION. Lextension
essentielle au niveau du CREATE TABLE porte sur les contraintes rfrentielles. Il
devient possible de rpercuter certaines mises jour de la relation rfrence. La nouvelle syntaxe est donne figure VIII.3. La clause ON DELETE indique laction que
doit excuter le systme dans la table dpendante lors dune suppression dans la table
matre. NO ACTION ne provoque aucune action, et a donc un effet identique
labsence de la clause comme en SQL1. CASCADE signifie quil faut enlever les
tuples correspondant de la table dpendante. SET DEFAULT indique quil faut remplacer la cl trangre des tuples correspondant de la table dpendante par la valeur
par dfaut qui doit tre dclare au niveau de lattribut. SET NULL a un effet identique, mais cette fois avec la valeur nulle. La clause ON UPDATE indique comment le
systme doit modifier la cl trangre dans la table dpendante lors de la mise jour
dune cl primaire dans la table matre. Les effets sont identiques au ON DELETE,
ceci prs que CASCADE provoque la modification de la cl trangre de la mme
manire que la cl primaire.

Intgrit et BD actives 253

De mme pour la clause ON UPDATE lors dune mise jour de la cl rfrence dans
la table matre.
FOREIGN KEY (<Attribut>+)
REFERENCES <Relation> (<Attribut>+)
[ON DELETE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]
[ON UPDATE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]

Figure VIII.3 : Contrainte rfrentielle en SQL2

La syntaxe de la nouvelle clause de dfinition de contraintes est rsume

figure VIII.4. Une telle contrainte peut tre vrifie immdiatement aprs chaque mise
jour prcise (clause AFTER), ou en fin de transaction (clause BEFORE COMMIT).
La condition peut porter sur une table entire (option FOR), ou sur chaque ligne de la
table (option FOR EACH ROW OF).
CREATE ASSERTION <nom de contrainte>
[{BEFORE COMMIT |
AFTER {INSERT|DELETE|UPDATE[OF(Attribut+)]} ON <Relation>}...]
CHECK <Condition>
[FOR [EACH ROW OF] <Relation>]

Figure VIII.4 : Cration de contrainte indpendante en SQL2

Voici quelques exemples. Lassertion suivante permet de vrifier dune manire un

peu dtourne que chaque vin bien un degr suprieur 10 :
CREATE ASSERTION MINDEGR
BEFORE COMMIT
CHECK (SELECT MIN(DEGR) FROM VINS > 10)
FOR VINS ;

Celle qui suit vrifie que la quantit totale bue reste infrieure 100 pour chaque
buveur :
CREATE ASSERTION SOMMEQUANTITBUE
BEFORE COMMIT
CHECK (SELECT SUM(QUANTITE) FROM ABUS GROUP BY NB) < 100
FOR ABUS.

En supposant que la table VINS possde un attribut QUALIT, on pourra par exemple
vrifier que chaque vin de qualit suprieure a au moins dix tuples dABUS le rfrenant. Une telle contrainte ncessitera dinsrer les ABUS dabord et de reporter la
vrification de contrainte rfrentielle au COMMIT, ce qui peut tre fait par la clause
BEFORE COMMIT.

254 BASES DE DONNES : OBJET ET RELATIONNEL

CREATE ASSERTION QUALITSUP

AFTER INSERT ON VINS
CHECK ((SELECT COUNT(*)
FROM ABUS A, VINS V
WHERE A.NV = V.NV
AND V.QUALIT = SUPRIEURE) > 10).

On peut donc ainsi crire des contraintes trs complexes, difficiles vrifier pour le
systme.

3. ANALYSE DES CONTRAINTES

DINTGRIT
Les contraintes dintgrit dfinies par un administrateur de donnes sont cres en
SQL. Avant dtre stockes dans la mta-base, elles doivent tre analyses et contrles sur la base si celle-ci nest pas vide. Lanalyse doit mettre les contraintes sous une
forme interne facilement exploitable, et aussi rpondre aux questions suivantes :
1. Les contraintes sont-elles cohrentes entre elles ?
2. Ne sont-elles pas redondantes ?
3. Quelles contraintes doit-on vrifier suite une insertion, une suppression, une mise
jour dune table ?
4. Est-il possible de simplifier les contraintes pour faciliter le contrle ?
Ces diffrents points sont examins ci-dessous.

3.1. TEST DE COHRENCE ET DE NON-REDONDANCE

Soit I = {I1, I2...In} un ensemble de contraintes. Existe-t-il une base de donnes
capable de satisfaire toutes ces contraintes ? Si oui, on dira que lensemble de
contraintes est cohrent.
Notion VIII.3 : Cohrence de contraintes (Constraint consistency)
Ensemble de contraintes non contradictoires, pouvant en consquence tre satisfait par au moins
une base de donnes.

EXEMPLE
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 12 ;

Intgrit et BD actives 255

et :
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR < 11 ;

sont deux contraintes contradictoires, un vin ne pouvant tre de degr la fois

suprieur 12 et infrieur 11.
Si les contraintes sont exprimables en logique du premier ordre, il est possible dutiliser une mthode de preuve pour tester la cohrence des contraintes. De nos jours,
aucun SGBD nest capable de vrifier la cohrence dun ensemble de contraintes
(sauf peut-tre les trop rares SGBD dductifs).
tant donn un ensemble de contraintes, il est aussi possible que certaines contraintes
puissent tre dduites des autres, donc soient redondantes.
Notion VIII.4 : Contraintes redondantes (Redundant constraints)
Ensemble de contraintes dont lune au moins peut tre dduite des autres.

EXEMPLE
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 12 ;

et :
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 11 ;

sont deux contraintes redondantes, la seconde pouvant tre rduite de la premire.

L encore, si les contraintes sont exprimables en logique du premier ordre, il est possible dutiliser une mthode de preuve pour tester leur non-redondance. En cas de
redondance, il nest pas simple de dterminer quelle contrainte liminer. Le problme
est de trouver un ensemble minimal de contraintes vrifier permettant de dmontrer
que toutes les contraintes sont satisfaites. Lensemble retenu doit tre optimal du point
de vue du temps de vrification, ce qui implique lutilisation dune fonction de cot.
De nos jours, aucun SGBD (sauf peut-tre les trop rares SGBD dductifs) nest
capable de vrifier la non-redondance dun ensemble de contraintes, et encore moins
de dterminer un ensemble minimal de contraintes. Cela nest pas trs grave car les
contraintes non structurelles restent peu utilises.

3.2. SIMPLIFICATION OPRATIONNELLE

Certaines contraintes dintgrit ne peuvent tre violes que par certains types de mise
jour sur une relation donne. Par exemple, lunicit de cl dans une relation R ne

256 BASES DE DONNES : OBJET ET RELATIONNEL

peut tre viole par une suppression sur R. Pour viter des contrles inutiles, il est
important didentifier quel type de mise jour peut violer une contrainte donne. SQL
distingue les oprations dinsertion (INSERT), de suppression (DELETE) et de mise
jour (UPDATE). Il est alors intressant de marquer une contrainte gnrale I avec des
tiquettes (R,U), R indiquant les relations pouvant tre violes et U le type de mise
jour associ. Par exemple, lunicit de cl K sur une relation R sera tiquete
(R,INSERT) et (R,UPDATE).
Des rgles gnrales dtiquetage peuvent tre simplement nonces :
1. Toute contrainte affirmant lexistence dun tuple dans une relation R doit tre tiquete (R,DELETE).
2. Toute contrainte vraie pour tous les tuples dune relation R doit tre tiquete
(R,INSERT).
3. Toute contrainte tiquete (R,DELETE) ou (R,INSERT) doit tre tiquete
(R,MODIFY).
Soit par exemple une contrainte rfrentielle de R vers S. Celle-ci affirme que pour
tout tuple de R il doit exister un tuple de S vrifiant R.A = S.K. Un tuple de S doit
exister, do ltiquette (S,DELETE). Tout tuple de R doit vrifier la contrainte, do
ltiquette (R,INSERT). Il faut donc ajouter les tiquettes (S,MODIFY) et
(R,MODIFY). Ces petites manipulations peuvent tre plus formellement dfinies en
utilisant le calcul relationnel de tuples avec quantificateurs que nous verrons dans le
contexte des bases de donnes dductives.

3.3. SIMPLIFICATION DIFFRENTIELLE

Les contraintes dintgrit sont vrifies aprs chaque transaction ayant modifie la
base. Ainsi, une transaction transforme une base de donnes dtat cohrent en tat
cohrent (voir figure VIII.5).
Lors de la vrification dune contrainte dintgrit, il est possible de profiter du fait
que la contrainte tait vrifie en dbut de transaction, avant mise jour. Dans le
meilleur des cas, seules les donnes mises jour doivent tre vrifies. Plus gnralement, il est souvent possible de gnrer une forme simplifie dune contrainte dintgrit quil suffit de vrifier sur la base aprs mise jour pour garantir la satisfaction
de la contrainte.
Cherchons donc exprimer une contrainte dintgrit par rapport aux modifications
apportes la base afin de la simplifier par prise en compte de la vracit de la
contrainte avant modifications. Toute modification dune relation R est soit une insertion, soit une suppression, soit une mise jour pouvant tre modlise par une suppression suivie dune insertion du mme tuple modifi. Considrons une transaction t
modifiant une relation R. Notons R+ les tuples insrs et R les tuples supprims

Intgrit et BD actives 257

dans R. La transaction t fait passer R de ltat R ltat Rt comme suit :

Rt := (R R) R+. Considrons une contrainte dintgrit I portant sur la
relation R. Avant mise jour, la contrainte est vraie sur R, ce que nous noterons
R |= I (R satisfait I). Aprs mise jour, il faut vrifier que Rt satisfait I, soit
((R R) R+)|= I. Dans certains cas de contrainte et de transaction comportant un seul type de mise jour (Insertion, Suppression ou Mise jour), cette dernire
forme peut tre simplifie par lintroduction de tests diffrentiels [Simon87].
Notion VIII.5 : Test diffrentiel (Differential test)
Contrainte dintgrit simplifie vrifier aprs une opration sur R afin de garantir la satisfaction
de la contrainte aprs application de lopration.

Dbut Transaction
BD

U1
tat transitoire
U2
...
Un
BD
Fin Transaction

Figure VIII.5 : Modification dune base de donnes par une transaction

EXEMPLE

Considrons une contrainte de domaine telle que DEGRE > 10 et une transaction dinsertion dans la table VINS. Il est clair que seuls les nouveaux vins insrs doivent tre vrifis. Dans ce cas R = . On en dduit que ((R R)
R+) |= I est quivalent (R R+) |= I. La contrainte devant tre
vrifie pour chaque tuple, sa vrification commute avec lunion, et il suffit
donc vrifier que R+ |= I. Ceci est dailleurs vrai lors dune insertion pour
toute contrainte vrifie par chaque tuple.
De manire gnrale, ltablissement de tests diffrentiels est possible pour les diffrentes contraintes du modle relationnel tudies ci-dessus dans la section 2. Le
tableau de la figure VIII.6 donne quelques tests diffrentiels valuer pour les oprations dinsertion, de suppression et de diffrence.

258 BASES DE DONNES : OBJET ET RELATIONNEL

Opration

Suppression

Insertion

Mise jour

Type de contrainte
Cl primaire K de R

Les cls de R+ sont

uniques et ne figurent
pas dans R.

Pas de vrification

Les cls de R+ sont

uniques et ne figurent
pas dans RR.

Cl trangre
A de R Ref K de S

Les tuples de R+
rfrencent un tuple
de S.

R : Pas de vrification

Les tuples de R+
rfrencent un tuple
de S.

Domaine A de R

Domaine A sur R+

Pas de vrification

Domaine A sur R+

Non nullit

Non-nullit sur R+

Pas de vrification

Non-nullit sur R+

Dpendance
fonctionnelle AB

Pour tout tuple t de R+, Pas de vrification

sil existe u de R tel
que t.A = u.A alors
t.B = u.B

Pas de forme
simplifie

Contrainte
temporelle
sur attribut

Pas de vrification

Vrifier les tuples

de R+ par rapport
ceux de R-

S : Les cls K de S
ne figurent pas dans
A de R.

Pas de vrification

Figure VIII.6 : Quelques tests diffrentiels de contraintes typiques

4. CONTRLE DES CONTRAINTES

DINTGRIT
Pour garder la base cohrente, le SGBD doit vrifier que les contraintes dintgrit
sont satisfaites chaque fin de transaction. En pratique, cette opration saccomplit
chaque mise jour en SQL. Cette approche oblige ordonner les mises jour en cas
de contraintes rfrentielles : il faut par exemple insrer dans la relation matre avant
dinsrer dans la relation dpendante les tuples lis. Le problme essentiel tant les
performances, on pousse dailleurs la vrification avant la mise jour, ce qui peut
seffectuer par des tests appropris, comme nous allons le voir.

4.1. MTHODE DE DTECTION

Une mthode de dtection consiste simplement valuer la contrainte dintgrit,
ventuellement simplifie, sur la base aprs excution de la transaction. Pour amlio-

Intgrit et BD actives 259

rer les performances, la dtection recherche en gnral les tuples ne satisfaisant pas la
contrainte.
Notion VIII.6 : Mthode de dtection (Detection method)
Mthode consistant retrouver les tuples ne satisfaisant pas une contrainte dans la base aprs une
mise jour, et rejeter la mise jour sil en existe.

Ainsi, soit I une contrainte dintgrit mettant en jeu des relations R1, R2...Rn dans
une base de donnes. Une mthode de dtection nave lors dune mise jour consiste
excuter la requte :
SELECT COUNT(*)
FROM R1, R2...Rn
WHERE NOT (I)

et dfaire la mise jour si le rsultat nest pas 0.

En utilisant les stratgies de simplification vues ci-dessus, il est possible damliorer
la mthode en remplaant la requte par une requte plus labore mettant en jeu les
relations diffrentielles. Plus gnralement, il est possible de remplacer la requte
vrifiant quaucun tuple ne viole la contrainte par un post-test pour une opration de
modification donne (INSERT, DELETE ou UPDATE).
Notion VIII.7 : Post-test (Posttest)
Test appliqu la base aprs mise jour permettant de dterminer si une contrainte dintgrit I est
viole.

Un post-test diffrentiel prendra en compte le fait que la contrainte tait vrifie avant
la modification. Il portera sur les relations diffrentielles R et R+. Par exemple, pour
une contrainte de domaine et une insertion, un post-test possible consistera vrifier
simplement que les tuples insrs satisfont la condition :
(SELECT COUNT(*)
FROM R+
WHERE NOT (I)) = 0.

4.2. MTHODE DE PRVENTION

Une mthode efficace souvent applique consiste empcher les modifications invalides. Une telle mthode est appele mthode de prvention.
Notion VIII.8 : Mthode de prvention (Prevention Method)
Mthode consistant empcher les modifications de la base qui violeraient une quelconque
contrainte dintgrit.

260 BASES DE DONNES : OBJET ET RELATIONNEL

Pour cela, un test avant mise jour garantissant lintgrit de la base si elle est mise
jour est appliqu. Un tel test est appel un pr-test.
Notion VIII.9 : Pr-test (Pretest)
Test appliqu la base avant une mise jour permettant de garantir la non-violation dune
contrainte dintgrit par la mise jour.

Un pr-test peut ventuellement modifier la mise jour en la restreignant aux tuples

conservant lintgrit de la base. La dtermination dun pr-test peut tre effectue en
transformant la contrainte dintgrit en lui appliquant linverse de la mise jour. Plus
prcisment, soit u une mise jour sur une relation R et I(R) une contrainte dintgrit
portant sur R. La contrainte dintgrit modifie I(u(R)) est limage de I obtenue en
remplaant R par leffet de u sur R. Par exemple, soient la contrainte dintgrit (Pour
tout VINS : DEGRE < 15) et la mise jour u :
UPDATE VINS
SET DEGRE = DEGRE + 1.

La contrainte dintgrit modifie est (Pour tout VINS : DEGRE+1 < 15),
puisque leffet de la mise jour est de remplacer DEGRE par DEGRE+1.
partir dune contrainte dintgrit modifie I(u(R)), il est possible de gnrer un
pr-test en vrifiant simplement que la requte suivante a une rponse gale 0 :
SELECT COUNT(*)
FROM R
WHERE NOT (I(U(R)).

Dans le cas des vins de degr infrieur 15, on obtient :

SELECT COUNT(*)
FROM VINS
WHERE (DEGRE + 1) 15

Ceci permet donc la mise jour si aucun vin na un degr suprieur ou gal 14. En
effet, dans ce cas aucun vin ne pourra avoir un degr suprieur 15 aprs mise jour.
Une mthode de prvention plus connue est la modification de requtes
[Stonebraker75] applique dans INGRES. Elle amliore la mthode prcdente en
intgrant le pr-test la requte de mise jour, ce qui permet de restreindre cette mise
jour aux seuls tuples respectant la contrainte dintgrit aprs mise jour. Bien que
dfinie en QUEL, la mthode est transposable en SQL. Soit la mise jour gnrique :
UPDATE R
SET R = U(R)
WHERE Q.

Soit donc I(R) une contrainte dintgrit sur R et I(u(R)) la contrainte modifie par la
mise jour inverse, comme vu ci-dessus. La mise jour est alors transforme en :

Intgrit et BD actives 261

UPDATE R
SET R = U(R)
WHERE Q AND I(U(R)).
EXEMPLE

Dans le cas des vins de degr infrieur 15, on excutera la mise jour modifie :
UPDATE VINS
SET DEGRE = DEGRE+1
WHERE DEGRE < 14,

ce qui fait que seuls les vins de degr infrieur 14 seront incrments. La
contrainte ne sera pas viole, mais la smantique de la mise jour sera quelque
peu change.
Loptimisation des pr-tests peut tre plus pousse et prendre en compte la smantique
des mises jour. Par exemple, si la mise jour dcrot le degr dun vin, il nest pas
ncessaire dajouter un pr-test pour vrifier que le degr ne dpassera pas 15 ! Plus
gnralement, si la mise jour est intgre un programme, par exemple en C/SQL, il
est possible de bnficier de la smantique du programme pour laborer un pr-test.
Une technique pour laborer des pr-tests en PASCAL/SQL a t propose dans
[Gardarin79]. Lide est dutiliser les axiomes de Hoare dfinissant la smantique de
PASCAL pour pousser les contraintes dintgrit crites en logique du premier ordre
depuis la fin dune transaction vers le dbut, en laissant ainsi au dbut de chaque mise
jour les pr-tests ncessaires.
Dans le cas de contrainte avec agrgats, les pr-tests constituent une des rares
mthodes efficaces de contrle. Lide simple dveloppe dans [Bernstein80] est de
grer dans la mta-base des agrgats redondants. Par exemple, si la moyenne des
salaires dans une relation EMPLOYES doit rester infrieure 20 000 F, on grera cette
moyenne (note MOYENNE) ainsi que le nombre demploys (not COMPTE) dans la
mta-base. Un pr-test simple lors de linsertion dun nouvel employ consistera alors
vrifier que (MOYENNE*COMPTE+NOUVEAU SALAIRE)/(COMPTE+1)
< 2000. De mme, pour une contrainte spcifiant que toute valeur dune colonne A
doit rester infrieure toute valeur dune colonne B, on pourra garder le minimum de
B dans la mta-base. Lors dune mise jour de A, un pr-test efficace consistera simplement vrifier que la nouvelle valeur de A reste infrieure au minimum de B.
Bien que les mises jour ne soient pas effectues lors de lvaluation des pr-tests,
une mthode intermdiaire a t applique dans le systme SABRE lINRIA
[Simon87], base sur des pr-tests diffrentiels. Elle comporte deux tapes :
1. Prparer la mise jour en construisant les relations R+ et R, comme vu ci-dessus.
2. Pour chaque contrainte menace, appliquer un pr-test diffrentiel pour contrler la
validit de la mise jour.

262 BASES DE DONNES : OBJET ET RELATIONNEL

Cest seulement la fin de la transaction que R et R+ sont appliques la relation R.

Pour chaque contrainte dintgrit et chaque type de mise jour, un pr-test diffrentiel tait labor. Pour les cas usuels, ces pr-tests correspondent peu prs ceux du
tableau de la figure VIII.6. Pour les cas plus complexes, une mthode systmatique de
diffrentiation dexpression logique tait applique [Simon87].

4.3. CONTRLES AU VOL DES CONTRAINTES SIMPLES

La plupart des systmes implmentent une version des contraintes possibles en SQL2
rduite lunicit de cl, aux contraintes rfrentielles, et aux contraintes de domaines
de type liste ou plage de valeurs, ou comparaison avec une autre colonne de la mme
table (CHECK <condition>, o la condition peut tre toute condition SQL sans
variable). Ces contraintes sont relativement simples vrifier, bien que les actions
possibles en cas de violation dune contrainte rfrentielle (SET NULL, SET
DEFAULT, ou CASCADE) impliquent une complexit que nous verrons ci-dessous.
Elles peuvent pour la plupart tre vrifies au vol, cest--dire lors de la mise jour
du tuple, ou plutt juste avant.
La mthode de contrle gnralement employe consiste effectuer une prvention au
vol en employant un pr-test chaque modification de tuple. Cette mthode est efficace car elle rduit au maximum les entre-sorties ncessaires. Nous examinons cidessous les pr-tests mis en uvre dans chacun des cas.

4.3.1. Unicit de cl
Tout SGBD gre en gnral un index sur les cls primaires. Un pr-test simple
consiste vrifier que la nouvelle cl ne figure pas dans lindex. Ce pr-test est effectu lors de linsertion dun tuple ou de la modification dune cl dans la table, en
gnral dailleurs juste avant mise jour de lindex.

4.3.2. Contrainte rfrentielle

Du fait que deux tables, la table matre et la table dpendante, sont mises en jeu par
une contrainte rfrentielle, quatre types de modifications ncessitent des vrifications, comme vu ci-dessus :
1. Insertion dans la table dpendante. La colonne rfrence dans la table matre
tant une cl primaire, il existe un index. Un pr-test simple consiste donc vrifier
lexistence dans cet index de la valeur de la colonne rfrenante insrer.
2. Mise jour de la colonne rfrenante dans la table dpendante. Le pr-test est
identique au prcdent pour la nouvelle valeur de la colonne.

Intgrit et BD actives 263

3. Suppression dans la table matre. Le pr-test consiste vrifier quil nexiste pas
de tuple contenant la valeur de cl supprimer dans la colonne rfrenante. Si le
pr-test est faux, une complexit importante surgit du fait de la multitude des
actions prvues dans ce cas en SQL2. Il faut en effet soit rejeter la mise jour, soit
modifier voire supprimer les tuples de la table dpendante correspondant cette
valeur de cl. Ceci peut ncessiter dautres contrles dintgrit, source de complexit examine plus loin.
4. Modification de cl dans la table matre. Le pr-test est identique au prcdent
pour la valeur de cl avant modification.
Finalement, sauf pour les suppressions de cl dans la table matre, les vrifications
sont simples. Elles peuvent devenir trs complexes en cas de suppression en cascade
le long de plusieurs contraintes rfrentielles.

4.3.3. Contrainte de domaine

Pour les contraintes de type CHECK <condition> avec une condition simple, il
suffit de vrifier avant dappliquer la mise jour que la valeur qui serait donne
lattribut aprs mise jour vrifie la condition. Ce pr-test est simple et peut tre
effectu au vol.

4.4. INTERACTION ENTRE CONTRAINTES

Un problme difficile est celui pos par les interactions possibles entre contraintes. Il
serait souhaitable que quel que soit lordre dvaluation des contraintes ou de mise
jour de colonnes, une mise jour donne le mme effet. Ceci nest pas simple raliser, notamment en cas de cascade de contraintes rfrentielles. Les interactions avec
les mises jour au travers des vues avec option de contrle (WITH CHECK
OPTION) sont aussi une source dinteraction [Cochrane96]. Afin de garantir le dterminisme des mises jour, une smantique de type point fixe doit tre applique. Elle
consiste appliquer une procdure de contrle comportant les tapes suivantes :
1. valuer tous les pr-tests des modifications directement issues de lordre original.
2. Si lun au moins nest pas vrifi, accomplir toutes les modifications cascader
(SET NULL, SET DEFAULT ou DELETE) et dclencher rcursivement les
contrles induits par ces modifications.
3. valuer nouveau tous les pr-tests des modifications directement issues de lordre
original. Si tous sont vrifis, excuter la mise jour, sinon rejeter la mise jour et
dfaire toutes les modifications faites tous les niveaux.
Cette procdure rcursive permet de se prmunir contre les interactions entre
contraintes rfrentielles, mais aussi avec les contraintes de non-nullit, de domaine,

264 BASES DE DONNES : OBJET ET RELATIONNEL

etc. Elle est certes un peu complexe, ce qui dmontre finalement la difficult de traiter
efficacement les contraintes exprimables en SQL2.

5. SGBD ACTIFS ET DCLENCHEURS

Dans cette section, nous prcisons ce quest un SGBD actif, puis ce quest un dclencheur. Enfin nous tudions une architecture type pour un SGBD actif.

5.1. OBJECTIFS
La notion de SGBD actif soppose celle de SGBD passif, qui subit sans ragir des
oprations de modification et interrogation de donnes.
Notion VIII.10 : SGBD actif (Active DBMS)
SGBD capable de ragir des vnements afin de contrler lintgrit, grer des redondances,
autoriser ou interdire des accs, alerter des utilisateurs, et plus gnralement grer le comportement
ractif des applications.

La notion de base de donnes active va permettre de dplacer une partie de la smantique des applications au sein du SGBD. Dans sa forme la plus simple, une BD active
rpercute les effets de mises jour sur certaines tables vers dautres tables. Un SGBD
actif peut donc ragir par exemple lors doprations illicites, mais aussi lors doprations licites, parfois un instant donn, et cela sous certaines conditions. Comment
ragit-il ? Il pourra dclencher une opration subsquente un vnement donn (par
exemple, une mise jour), interdire une opration en annulant la transaction qui la
demande, ou encore envoyer un message lapplication, voire sur Internet.

5.2. TYPES DE RGLES

Les SGBD actifs ont intgr de manire procdurale les rgles de production de
lintelligence artificielle. Une rgle de production est une construction de la forme :
IF <Condition sur BD> THEN <Action sur BD>.

Une rgle de production permet dagir sur une base de donnes lorsque la condition
de la rgle est satisfaite : laction est alors excute et change en gnral ltat de la
base. Le systme de contrle choisit quelle rgle appliquer, jusqu saturation dune
condition de terminaison, ou jusquau point de saturation o plus aucune rgle ne peut
modifier ltat de la base : on a alors atteint un point fixe.

Intgrit et BD actives 265

Cette ide, qui est aussi la source des bases de donnes dductives comme nous le
verrons plus tard, a t reprise dans les SGBD relationnels en ajoutant aux rgles un
contrle procdural : chaque rgle sera applique suite un vnement. Les rgles
deviennent alors des dclencheurs ou rgles ECA (vnement Condition
Action).
Notion VIII.11 : Dclencheur (Trigger)
Rgle dont lvaluation de type procdural est dclenche par un vnement, gnralement exprime sous la forme dun triplet vnement Condition Action : WHEN <vnement> IF <Condition
sur BD> THEN <Action sur BD>.

Lorsque lvnement se produit, la condition est value sur la base. Si elle est vraie,
laction est effectue. Nous prciserons ultrieurement ce quest un vnement, une
condition et une action. Disons pour linstant que lvnement est souvent une modification de la base, la condition un prdicat vrai ou faux, et laction un programme de
mise jour. La condition est optionnelle ; sans condition, on obtient un dclencheur
dgnr vnement-action (EA). Il est a remarquer que, dans ce dernier cas, la condition peut toujours tre teste dans le programme constituant laction, mais celui-ci est
alors dclench plus souvent et inutilement.
Le modle dexcution des dclencheurs est trs variable dans les SGBD, mais il a t
propos une dfinition standard pour SQL [Cochrane96]. Malheureusement, les triggers apparaissent seulement au niveau de SQL3. Dans la suite, nous nous appuierons
sur ce modle, mais il faut savoir que les systmes ne le respectent en gnral gure.
Pour comprendre la smantique des dclencheurs dans un SGBD actif, il faut distinguer la prise en compte des vnements, la dtermination des rgles candidates
lexcution, le choix dune rgle si plusieurs sont candidates, lexcution dune rgle
qui comporte lvaluation de la condition puis lexcution de laction.
La faon dont les rgles sont excutes dans les SGBD actifs nest pas standard. La
smantique dune BD active est donc souvent difficile percevoir. Pour cela, un
SGBD actif se doit de rpondre aux questions suivantes :
1. Quand prendre en compte un vnement ? Ce peut tre ds son apparition, ou seulement lorsquune rgle nest pas en cours dexcution ; dans ce dernier cas, il ne sera
pas possible dinterrompre lexcution dune rgle pour en excuter une plus prioritaire.
2. Quand excuter les rgles ? Ce peut tre ds lapparition de lvnement, ou plus
tard lors dun retour au systme par exemple.
3. Comment choisir une rgle lorsque plusieurs sont candidates lexcution ? Des
mcanismes de priorit simples (par exemple, un niveau de priorit de 1 10) peuvent tre mis en uvre.
4. Quelle est la force du lien condition-action ? Autrement dit, doit-on excuter
laction ds que la condition a t value ou peut-on attendre ?

266 BASES DE DONNES : OBJET ET RELATIONNEL

5. Lorsquune rgle est excute et produit des vnements provoquant le dclenchement dautres rgles, doit-on se drouter ou attendre la fin de lexcution de toutes
les rgles actives ou seulement de celle en cours dexcution ?
Toutes ces questions ne sont pas indpendantes. Les rponses apportes fixent la
smantique du SGBD actif et conduisent des rsultats diffrents. Dans la suite, nous
utilisons la smantique dcrite dans [Cochrane96], propose pour SQL3. Par exemple,
ce modle procde en profondeur dabord : il interrompt la rgle en cours dexcution
chaque nouvel vnement.

5.3. COMPOSANTS DUN SGBD ACTIF

Les SGBD actifs ne sont donc pas standard. Cependant, la figure VIII.7 prsente une
architecture typique pour un SGBD actif. Les composants essentiels sont les suivants :
1. Lanalyseur de rgles permet de saisir les rgles en forme externe (souvent textuelle), de les analyser et de les ranger en format interne dans le dictionnaire de
rgles.
2. Le moteur de rgles coordonne lexcution des rgles suite aux vnements. Il
reoit les vnements primitifs et composites et dtermine les rgles candidates
lexcution. Une rgle devient alors active. Parmi les rgles actives, le moteur de
rgles choisi la plus prioritaire et lance sont excution, qui comporte donc lvaluation de la condition, puis lexcution de laction si la condition est satisfaite. Le
moteur de rgles gre aussi le contexte des rgles actives, cest--dire mmorise les
variables qui doivent tre maintenues et passes par exemple de la condition
laction.
3. Le moniteur dvnements dtecte les vnements primitifs et composites. Il
demande au moteur de rgles lexcution des rgles dclenches par ces vnements.
4. Sur demande du moteur de rgles, lvaluateur de conditions value les conditions
des rgles actives, ventuellement en demandant lexcution des recherches au
SGBD. Il dtermine si la condition est vraie et retourne cette information au moteur
de rgles.
5. Lexcuteur dactions excute les actions des rgles actives dont les conditions ont
t pralablement vrifies. Il invoque pour ce faire le SGBD.
6. Le dictionnaire de rgles est la partie de la mta-base du SGBD qui contient la
dfinition des rgles en format interne.
Deux approches sont possibles pour un SGBD actif [Llirbat97] : lapproche intgre
lie intimement les composants spcifiques du SGBD actif au SGBD, alors que
lapproche sur-couche construit au-dessus dun SGBD les composants ncessaires.
Lapproche intgre est souvent plus efficace, mais elle ne permet pas de raliser des

Intgrit et BD actives 267

systmes de dclencheurs portables, indpendants du SGBD natif (il en existe bien

peu).
Dfinitions

valuateur
Moteur

Analyseur
Excuteur

Moniteur d'vnements

Requtes

Noyau du SGBD

BD active
Dictionnaire

Figure VIII.7 : Architecture dun SGBD actif

6. LA DFINITION DES DCLENCHEURS

Dans cette section, nous dfinissons plus prcisment les lments constituant un
dclencheur. Puis, nous donnons la syntaxe permettant de dfinir les dclencheurs en
SQL3.

6.1. LES VNEMENTS

Notion VIII.12 : vnement (Event)
Signal instantan apparaissant un point spcifique dans le temps, externe ou interne, dtect par
le SGBD.

268 BASES DE DONNES : OBJET ET RELATIONNEL

Un vnement correspond donc lapparition dun point dintrt dans le temps. La

spcification dun vnement ncessite la dfinition dun type. Un type dvnement
peut correspondre au dbut (BEFORE) ou la fin (AFTER) dune recherche
(SELECT), dune mise jour (UPDATE, DELETE, INSERT) ou dune transaction
(BEGIN, COMMIT, ABORT), lcoulement dun dlai, au passage dune horodate, etc. Un type permet de dfinir un ensemble potentiellement infini dinstances
dvnements, simplement appel vnement. Une instance dvnement se produit
donc un instant donn. un vnement sont souvent associs des paramtres : une
valeur dune variable, un objet, une colonne de table, etc. Le contexte dun vnement est une structure de donnes nomme contenant les donnes ncessaires lvaluation des rgles dclenches par cet vnement, en particulier les paramtres de
lvnement. Parmi les vnements, on distingue les vnements simples (ou primitifs) et les vnements composs.

6.1.1. vnement simple

Dans un SGBD, les vnements simples (encore appels primitifs) particulirement
considrs sont lappel dune modification de donnes (BEFORE UPDATE, BEFORE
INSERT, BEFORE DELETE), la terminaison dune modification de donnes
(AFTER UPDATE, AFTER INSERT, AFTER DELETE), lappel dune recherche
de donnes (BEFORE SELECT), la fin dune recherche de donnes (AFTER
SELECT), le dbut, la validation, lannulation dune transaction (BEGIN, COMMIT,
ABORT), un vnement temporel absolu (AT TIMES <Heure>) ou relatif (IN
TIMES <Delta>), ou tout simplement un vnement utilisateur (avant ou aprs excution de procdure : BEFORE <procedure> ou AFTER <procedure>). Une typologie
simplifie des diffrents vnements primitifs apparat figure VIII.8. Dautres sont
dtectables, par exemple les erreurs.
vnement

Externe

Heure

Interne

Appel

Modification

Update

Insert

Interrogation

Delete

Select

Transaction

Begin

Figure VIII.8 : Typologie des vnements primitifs

Commit

Abort

Intgrit et BD actives 269

6.1.2. vnement compos

Un vnement compos est une composition dvnements simples. Celle-ci est effectue par des constructeurs spcifiques, tels le OU et le ET logique. On obtient ainsi des
expressions logiques simples et parenthsables dvnements. (A OU B) se produit
lorsque lun ou lautre des vnements est vrai. Alors que les vnements primitifs ne
sont pas mmoriss aprs leur production, le problme devient plus difficile pour les vnements composs. Par exemple, si A a t signal, (A OU B) aussi. Que doit-on faire si
B se produit ? Faut-il signaler nouveau (A OU B) ? Le problme nest pas simple et la
solution retenue peut changer compltement la smantique dune application.
Au-del des constructeurs logiques ET et OU, il est possible de faire intervenir des
constructeurs temporels tels que la squence (A PUIS B) qui est signale si B suit A, la
rptition (N FOIS A) dclenche si A se produit N fois, ou la production ou la non
production pendant un intervalle de temps (A IN <intervalle>, A NOT IN
<Intervalle>). Tout ceci complique la gestion des vnements, mais facilite la prise en
compte de la logique temporelle des applications. On pourra par exemple crire des vnements du style ((1H AFTER UPDATE) OR (AFTER INSERT THEN BEFORE
DELETE) AND (5 TIMES BEFORE INSERT) AND (COMMIT NOT IN
[10H, 12H])), dont la signification est un peu complexe. Heureusement, peu de
SGBD except quelques prototypes de recherche utilisent des vnements composs
[Gatziu92].

6.2. LA CONDITION
La condition est une expression logique de prdicats portant sur les variables de
contexte dexcution de la rgle ou/et sur la base de donnes. Peu de systmes permettent des requtes compltes au niveau de la condition.
Notion VIII.13 : Condition de dclencheur (Trigger condition)
Qualification (aussi appele condition de recherche, ou search condition) portant sur les variables
de contexte et/ou la base et donnant en rsultat une valeur boolenne.

Si lon souhaite tester lexistence de tuples, on utilisera les prdicats EXIST et NOT
EXIST, ou le compte de tuples rsultats (COUNT). La condition est en gnral optionnelle au niveau des dclencheurs : sans condition, on a simplement une rgle vnement-action.

6.3. LACTION
Laction est une procdure excute lorsque la condition est vrifie.

270 BASES DE DONNES : OBJET ET RELATIONNEL

Notion VIII.14 : Action de dclencheur (Trigger action)

Procdure excute lorsque la rgle est dclenche.

Ce peut tre une seule requte ou une squence de requtes SQL, une procdure stocke agissant sur la base crite en L4G ou dans un L3G intgrant SQL (C/SQL par
exemple), ou enfin une opration sur transaction (ABORT, COMMIT). Laction peut
utiliser les paramtres du contexte. Elle peut tre excute une seule fois suite lvnement ou pour chaque ligne satisfaisant la condition, comme nous le verrons plus en
dtail ci-dessous.

6.4. EXPRESSION EN SQL3

Avec SQL3, tous les objets (rgles, contraintes, etc.) sont nomms, donc en particulier
les dclencheurs. Les vnements sont simples et dclenchs par les requtes de modification INSERT, UPDATE, et DELETE. Lvnement peut tre dclench soit avant
excution de la modification (BEFORE), soit aprs (AFTER). Deux granularits sont
possibles afin de contrler lvaluation de la condition et lexcution ventuelle de
laction : les granularits ligne ou requte. Dans le premier cas, laction est excute
pour chaque ligne modifie satisfaisant la condition, dans le second elle est excute
une seule fois pour lvnement. Laction peut rfrencer les valeurs avant et aprs
mise jour (clause REFERENCING... AS...). Elle peut mme remplacer compltement la modification dont lappel a provoqu lvnement (clause INSTEAD OF).

6.4.1. Syntaxe
La figure VIII.9 donne la syntaxe rsume de la requte de cration de dclencheur en
SQL3. La smantique est explicite dans le paragraphe qui suit.
CREATE TRIGGER <nom>
// vnement (avec paramtres)
{BEFORE | AFTER | INSTEAD OF}
{INSERT | DELETE | UPDATE [OF <liste de colonnes>]}
ON <table> [ORDER <valeur>]
[REFERENCING{NEW|OLD|NEW_TABLE|OLD_TABLE} AS <nom>]...
// condition
(WHEN (<condition de recherche SQL>)
// action
<Procdure SQL3>
// granularit
[FOR EACH {ROW | STATEMENT}])

Figure VIII.9 : Syntaxe de la commande de cration de dclencheur

Intgrit et BD actives 271

6.4.2. Smantique
Lvnement de dclenchement est une mise jour (UPDATE), une insertion (INSERT)
ou une suppression (DELETE) dans une table. En cas de mise jour, un paramtre
optionnel permet de prciser une liste de colonnes afin de rduire la porte de lvnement. Lvnement nest pas instantan et a un effet. Afin de prciser linstant dactivation de la rgle, trois options sont disponibles : avant (BEFORE), aprs (AFTER) la
modification, ou la place de (INSTEAD OF). On revient donc l des vnements
instantans. Loption avant est trs utile pour contrler les paramtres et les donnes
dentres avant une modification. Loption aprs permet plutt de dclencher des
traitements applicatifs conscutifs une mise jour. Loption la place de permet de
remplacer un ordre par un autre, par exemple pour des raisons de scurit.
Un ordre optionnel est spcifi pour prciser les priorits lorsque plusieurs dclencheurs sont dfinis sur une mme table. La dclaration REFERENCING NEW AS
<nom> dfinit une variable de nom <nom> contenant la valeur de la dernire ligne
modifie dans la base par lvnement. De mme, REFERENCING OLD AS <nom>
dfinit une variable de nom <nom> contenant la valeur de la mme ligne avant lvnement. Des tables diffrentielles contenant les valeurs avant et aprs lvnement
sont dfinies par les options NEW_TABLE et OLD_TABLE. Les dclencheurs sur
INSERT ne peuvent que dclarer les nouvelles valeurs. Les dclencheurs sur
DELETE ne peuvent que dclarer les anciennes.
Chaque dclencheur spcifie en option une action garde par une condition. La condition est un critre de recherche SQL pouvant porter sur les variables de contexte ou
sur la base via des requtes imbriques. Laction est une procdure contenant une
squence dordre SQL. Condition et action peuvent donc interroger la base de donnes et le contexte du dclencheur (par exemple, manipuler les variables et les tables
diffrentielles). Condition et action lisent ou modifient les valeurs de la base avant
mise jour dans un dclencheur avant (BEFORE), aprs mise jour dans un dclencheur aprs (AFTER).
La granularit dun dclencheur est soit ligne (FOR EACH ROW), soit requte (FOR
EACH STATEMENT). Dans le premier cas, il est excut pour chaque ligne modifie
(0 fois si aucune ligne nest modifie), alors que dans le second, il lest une seule fois
pour la requte.

6.5. QUELQUES EXEMPLES

6.5.1. Contrle dintgrit
Cet exemple porte sur la table des VINS. Le premier dclencheur de la figure VIII.10
contrle lexistence dun vin lors de lajout dun abus. Le second cascade la suppression dun vin, cest--dire supprime les abus correspondant au vin supprim.

272 BASES DE DONNES : OBJET ET RELATIONNEL

// Ajout dun abus

CREATE TRIGGER InsertAbus
BEFORE INSERT ON ABUS
REFERENCING NEW AS N
(WHEN (NOT EXIST (SELECT * FROM Vins WHERE NV=N.NV))
ABORT TRANSACTION
FOR EACH ROW) ;
// Suppression dun vin
CREATE TRIGGER DeleteVins
BEFORE DELETE ON VINS
REFERENCING OLD AS O
(DELETE FROM ABUS WHERE NV = O.NV
FOR EACH ROW) ;

Figure VIII.10 : Contrle dintgrit rfrentielle

Le dclencheur de la figure VIII.11 est associ la table des employs, de schma :

EMPLOYE (ID Int, Nom Varchar, Salaire Float).

Il effectue un contrle dintgrit temporelle : le salaire ne peut que crotre.

CREATE TRIGGER SalaireCroissant
BEFORE UPDATE OF Salaire ON EMPLOYE
REFERENCING OLD AS O, NEW AS N
(WHEN O.Salaire > N.Salaire
SIGNAL.SQLState 7005 (Les salaires ne peuvent dcrotre)
FOR EACH ROW);

Figure VIII.11 : Contrle dintgrit temporelle

6.5.2. Mise jour automatique de colonnes

Le dclencheur de la figure VIII.12 est dclench lors de la mise jour de la table
PRODUITS (NP Int, NF Int, Cot Real, Auteur String, DateMaj Date).

Il positionne les attributs Auteur et DateMaj aux valeurs courantes de la transaction

pour lequel il est excut.
CREATE TRIGGER SetAuteurDate
BEFORE UPDATE ON PRODUITS
REFERENCING NEW_TABLE AS N
(UPDATE N
SET N.Auteur = USER, N.DateMaj = CURRENT DATE);

Figure VIII.12 : Complment de mise jour

Intgrit et BD actives 273

Le dclencheur de la figure VIII.13 est aussi associ la table PRODUITS. Il cre

automatiquement la cl lors de linsertion dun tuple. Attention : si vous insrez plusieurs tuples ensemble, vous obtenez plusieurs fois la mme cl ! Il faut alors crire le
programme en L4G et travailler sur chaque ligne.
CREATE TRIGGER SetClVins
BEFORE INSERT ON PRODUITS
REFERENCING NEW_TABLE AS N
(UPDATE N
SET N.NP = SELECT COUNT(*) +1 FROM PRODUITS);

Figure VIII.13 : Gnration automatique de cl

6.5.3. Gestion de donnes agrgatives

Le dclencheur de la figure VIII.14 est associ la table EMPLOYE vue ci-dessus permettant de grer le salaire des employs. Il rpercute les mises jour du salaire sur la
table de cumul des augmentations de schma : CUMUL (ID int,
Augmentation float).
CREATE TRIGGER CumulSal
AFTER UPDATE OF salaire ON EMPLOYE
REFERENCING OLD AS a, NEW AS n
(UPDATE CUMUL SET Augmentation = Augmentation +
n.salaire a.salaire WHERE ID = a.ID
FOR EACH ROW) ;

Figure VIII.14 : Gestion de donnes agrgative

7. EXCUTION DES DCLENCHEURS

Nous examinons ici brivement les mcanismes ncessaires au sein dun moteur de
rgles afin de cordonner lexcution des rgles, en plus bien sr de la gestion du
contexte des vnements. Ces mcanismes sont difficiles du fait de la smantique plutt complexe des dclencheurs, base sur une application jusqu saturation (point
fixe) de rgles de mise jour. Nous utilisons ici la smantique de rfrence de SQL3
[Cochrane96].

274 BASES DE DONNES : OBJET ET RELATIONNEL

7.1. PROCDURE GNRALE

La procdure gnrale dexcution dune modification (UPDATE, INSERT ou
DELETE) doit prendre en compte les dclencheurs et la vrification des contraintes
dintgrit. Les deux peuvent interagir. La procdure doit distinguer les actions
effectuer avant lexcution de lopration de modification ayant dclench la rgle de
celle excute aprs. Il faut excuter avant les dclencheurs avec option BEFORE et
aprs ceux avec option AFTER. Les contrles dintgrit, gnralement accomplis par
des pr-tests, seront aussi effectus avant. Dans tous les cas, la modification doit tre
prpare afin de rendre accessibles les valeurs avant et aprs mise jour. La
figure VIII.15 rsume lenchanement des contrles lors de lexcution dune mise
jour. La figure VIII.16 montre comment est excute une rgle, selon loption. Cette
procdure est au cur du moteur de rgles.
// Excution dune modification dune relation R
Modification(R) {
Prparer les mises jour de R dans R+ et R ;
// Excuter les dclencheur avant mise jour (BEFORE)
For each dclencheur BEFORE d do {Excuter(d.Rgle)} ;
// Effectuer les contrles dintgrit, puis la mise jour
If (Not Integre) then ABORT TRANSACTION ;
// effectuer la mise jour
R = (R R) R+ ;
// Excuter les dclencheurs aprs mise jour (AFTER)
For each dclencheur AFTER do {Excuter(d.Rgle)} ;
} ;

Figure VIII.15 : Excution dune modification

// Excution dune rgle WHEN Condition Action FOR EACH <Option>

Excuter(Condition, Action, Option) {
// Appliquer chaque tuple si option ligne
if Option = FOR EACH ROW then
{For each t de R = R+ R do {
if (Condition(t) = True) then Excuter (Action(t)) ;}
if Option = FOR EACH STATEMENT then {
if (Condition(R) = True) then Excuter (Action(R) ;}
} ;

Figure VIII.16 : Excution dune rgle

Intgrit et BD actives 275

7.2. PRIORITS ET IMBRICATIONS

En fait, suite un vnement, plusieurs rgles peuvent tre candidates lexcution.
Dans lalgorithme de la figure VIII.15, nous avons choisi dexcuter les dclencheurs
avant puis aprs dans un ordre quelconque (boucle FOR EACH). Malheureusement,
lordre peut influer sur le rsultat. Par exemple, un dclencheur peut dfaire une mise
jour excute par un autre. Ceci ne se produirait pas si on excutait les dclencheurs
dans un ordre diffrent ! Il y a donc l un problme de smantique.
Avec SQL3, il est prvu une priorit affecte soit par lutilisateur (clause ORDER), soit
selon lordre de dfinition des dclencheurs. Cette priorit doit donc tre respecte :
les boucles For each de la figure VIII.15 doivent choisir les dclencheurs en respectant les priorits.
Plus complexe, lexcution dune rgle peut entraner des mises jour, qui peuvent
leur tour impliquer lexcution de dclencheurs sur la mme relation ou sur une autre.
Dans ce cas, les contextes dexcution des modifications sont empils, comme lors de
lappel de sous-programmes. chaque fin dexcution dune modification, un dpilage est ncessaire afin de revenir la modification prcdente. Deux problmes se
posent cependant, que nous examinons successivement.
Le premier problme tient aux mises jour cumulatives. Si la modification porte sur la
mme relation R, de nouveaux tuples sont insrs dans R+ et R par la modification
imbrique. On peut soit empiler les versions de R+ et R, soit ne sintresser qu leffet
net de lensemble des mises jour. La smantique des dclencheurs sera alors diffrente.
Notion VIII.15 : Effet net (Net effect)
Impact cumul dun ensemble de mise jour en termes de relations diffrentielles R+ (tuples insrer) et R (tuples supprimer).

Leffet net est une notion importante aussi pour les transactions qui sont composes de
plusieurs mises jour. Par exemple, une transaction qui insre puis supprime un tuple
a un effet net vide.
Le second problme concerne les risques de bouclage. En effet, il peut exister des
boucles de dclencheurs qui ne sarrtent pas. En effet, une mise jour peut impliquer
une nouvelle mise jour, et ainsi de suite. Le nombre de relations tant fini, la boucle
reviendra forcment plusieurs fois sur une mme relation. Cest un critre simple
dtectable par lanalyseur de dclencheurs. Cependant, ceci limite fortement lusage
des dclencheurs. Par exemple, on ne peut crire un dclencheur qui en cas de baisse
de votre salaire dclenche une autre rgle pour vous donner une prime compensatrice ! Une solution plus sophistique consiste dtecter les boucles lexcution en
limitant le nombre de dclencheurs activs lors dune mise jour. Une approche plus
sophistique encore consiste prendre en compte leffet net dun ensemble de dclencheurs successifs et vrifier quil change de manire continue.

276 BASES DE DONNES : OBJET ET RELATIONNEL

7.3. COUPLAGE LA GESTION DE TRANSACTIONS

Jusque-l, nous avons suppos que les dclencheurs taient excuts lors de chaque
modification, pour le compte de la transaction qui effectue la modification. En fait,
diffrents types de liaisons avec les transactions sont possibles, notamment pour les
dclencheurs aprs, pour les conditions et/ou les actions. On distingue :
1. Le mode dexcution qui prcise quand excuter le dclencheur. Ce peut tre
immdiat, cest--dire ds que lvnement se produit (IMMEDIAT), ou diffr en
fin de transaction (DEFERRED).
2. Le mode de couplage qui prcise si le dclencheur doit tre excut dans la mme
transaction (COUPLED) ou dans une transaction indpendante (DECOUPLED).
3. Le mode de synchronisation qui dans le cas dune transaction indpendante prcise si elle est synchrone (aprs) ou asynchrone (en parallle) (SYNCHRONOUS)
avec la transaction initiatrice.
Tout ceci complique la smantique des dclencheurs. Dans le cas du mode diffr,
seul leffet net de la transaction sera pris en compte par les dclencheurs. Le cas de
transaction dcouple asynchrone devient complexe puisque les deux transactions
peuvent interagir via les mises jour. Lune, pourquoi pas la transaction initiatrice,
peut tre reprise alors que lautre ne lest pas. Ainsi, le dclencheur peut tre excut
sans que la transaction dclenchante ne le soit ! Les SGBD actuels vitent ce mode de
synchronisation et dailleurs plus radicalement le mode dcoupl.

8. CONCLUSION
Un systme de rgles supporte au minimum des vnements simples de mise jour.
Cest le cas de SQL3 et des SGBD relationnels du commerce. Il est aussi possible de
considrer les vnements de recherche (SELECT) comme dans Illustra
[Stonebraker90]. Seuls des systmes de recherche grent des vnements composs,
avec OU, ET, squences et intervalles de temps. On citera par exemple HIPAC
[Dayal88] et SAMOS [Gatziu92].
Le standard SQL3 supporte des conditions et actions excutes avant le traitement
naturel de lopration initiatrice, ou aprs, ou sa place. Il permet aussi de diffrer
lexcution de certains dclencheurs en fin de transaction. Par contre, les dclencheurs
sont excuts pour le compte de la transaction dclenchante. Ils ne peuvent tre
dcoupls. Le dcouplage pose beaucoup de problmes de smantique et a t partiellement explor dans des projets de recherche comme SAMOS.

Intgrit et BD actives 277

Les dclencheurs sont trs utiles dans les SGBD. Ils correspondent cependant une
vision procdurale des rgles. De ce fait, la smantique est souvent obscure. La
conception de bases de donnes actives efficaces reste un problme difficile.

9. BIBLIOGRAPHIE
[Agrawal91] Agrawal R., Cochrane R.J., Linsay B., On Maintaining Priorities in a
Production Rule System , Proc. 17th Int. Conf. on Very Large Data Bases,
Barcelona, Spain, Morgan Kaufman Ed., p. 479-487, Sept. 1991.
Cet article rapporte sur lexprimentation du mcanisme de priorit entre
rgles implment IBM dans le projet Starburst. Il montre lintrt du mcanisme.
[Bernstein80] Bernstein P., Blaustein B., Clarke E..M., Fast Maintenance of semantic Integrity Assertions Using Redundant Aggregate Data , Proc. 6th Int. Conf.
on Very Large Data Bases, Montreal, Canada, Morgan Kaufman Ed., Oct.
1991.
Les auteurs furent les premiers proposer la maintenance dagrgats redondants pour faciliter la vrification des contraintes dintgrit lors des mises
jour. Depuis, ces techniques se sont rpandues sous la forme de vues concrtes.
[Ceri90] Ceri S., Widom J., Deriving Production Rules for Constraint
Maintenance , Proc. 16th Intl. Conf. on Very Large Data Bases, Brisbane,
Australia, Morgan Kaufman Ed., p. 566-577, Aug. 1990.
Les auteurs proposent des algorithmes pour gnrer des dclencheurs permettant la vrification automatique de rgles dintgrit lors des mises jour. De
tels algorithmes pourraient tre intgrs un compilateur de dfinitions de
contraintes dintgrit.
[Cochrane96] Cocherane R., Pirahesh H., Mattos N., Integrating triggers and
Declarative Constraints in SQL Database Systems, Proc. 16th Intl. Conf. on
Very Large Data Bases, Brisbane, Australia, Morgan Kaufman Ed., p. 566-577,
Aug. 1990.
Larticle de rfrence pour la smantique des dclencheurs en SQL3. Aprs un
rappel des contraintes dintgrit existant en SQL2, larticle montre comment
on excute les dclencheurs en absence de contraintes, puis les interactions
entre ces deux mcanismes. Il dfinit ensuite une smantique de point fixe pour
les dclencheurs.

278 BASES DE DONNES : OBJET ET RELATIONNEL

[Date81] Date C.J., Referential Integrity , Proc. 7th Intl. Conf. on Very Large Data
Bases, Cannes, France, IEEE Ed., Sept. 1981.
Larticle de base qui a introduit les contraintes rfrentielles. Celles-ci taient
intgres au relationnel pour rpondre aux attaques de perte de smantique du
modle par rapport aux modles type rseau ou entit-association.
[Dayal88] Dayal U., Blaunstein B., Buchmann A., Chakravavarthy S., Hsu M., Ladin
R., McCarthy D., Rosenthal A., Sarin S., Carey M. Livny M., Jauhari J., The
HiPAC Project : Combining Active databases and Timing Constraints , SIGMOD Record V 17, n 1, Mars 1988.
Un des premiers projets tudier un systme de dclencheurs avec contraintes
temporelles. Le systme HiPAC fut un prcurseur en matire de dclencheurs.
[Dittrich95] K.R., Gatziu S., Geppert A., The Active Database Management System
Manifesto , Proc. 2nd Int. Workshop on Rules in Databas Systems, Athens,
Greece, Sept. 1995.
Ce manifesto se veut lquivalent pour les bases de donnes actives du manifesto des bases de donnes objet. Il dfinit prcisment les fonctionnalits que
doit supporter un SGBD actif.
[Eswaran75] Eswaran K.P., Chamberlin D.D., Functional Specifications of a
Subsystem for Database Integrity , Proc. 1st Intl. Conf. on Very Large Data
Bases, Framingham, Mass., p. 48-67, Sept. 1975.
La description dtaille du premier sous-systme dintgrit ralis. Ce travail
a t effectu dans le cadre du System R IBM.
[Eswaran76] Eswaran K.P., Chamberlin D.D., Specifications, Implementations and
Interactions of a Trigger Subsystem in an Integrated Database System , IBM
Research report RJ 1820, IBM Research Lab., San Jos, California, Aot 76.
La description dtaille du premier sous-systme de dclencheurs ralis. Ce
travail a t effectu dans le cadre du System R IBM.
[Gardarin79] Gardarin G., Melkanoff M., Proving Consistency of Database
Transactions , Proc. 5th Int. Conf. on Very Large Data Bases, Rio de Janeiro,
Brsil, Sept. 1979.
Cet article propose une mthode pour gnrer automatiquement des pr-tests
dans des programmes crits en PASCAL/SQL. La mthode est base sur une
technique de preuve dassertions en utilisant la smantique de Hoare.
[Hammer78] Hammer M., Sarin S., Efficient Monitoring of Database Assertions ,
Proc. ACM SIGMOD Int. Conf. On Management of Data, 1978.
Cet article propose des techniques de simplification de contraintes dintgrit
bases sur ltude logique de ces contraintes.

Intgrit et BD actives 279

[Horowitz92] Horowith B., A Runtime Excecution Model for referential Integrity

Maintenance , Proc. 8th Intl. Conf. on Data Engineering, Tempe, Arizona,
p. 546-556, 1992.
Les auteurs dcrivent un prototype ralisant efficacement la vrification des
contraintes rfrentielles lors de lexcution des mises jour.
[Llirbat97] Llirbat F., Fabret F., Simon E., Eliminating Costly Redundant
Computations from SQL Trigger Executions Proc. ACM SIGMOD Int. Conf.
on Management of data, Tucson, Arizona, p. 428-439, Juin 1997.
Cet article dveloppe une nouvelle technique doptimisation des dclencheurs
en SQL. Cette technique, au cur de la thse de F. Llirbat, permet dextraire
les invariants dans les boucles et de les mmoriser afin dviter les recalculs.
Le papier dveloppe aussi un modle pour dcrire les programmes, les dclencheurs, et leurs interactions.
[Simon87] Simon E., Valduriez P., Design and Analysis of a Relational Integrity
Subsystem , MCC Technical report Number DB-015-87, Jan. 1987.
Ce rapport rsume la thse dric Simon (Paris VI, 1987) et dcrit le systme
de contrle dintgrit du SGBD SABRE ralis lINRIA. Ce systme est bas
sur des post-tests diffrentiels.
[Stonebraker75] Stonebraker M., Implementation of integrity Constraints and Views
by Query Modification , Proc. ACM SIGMOD, San Jos, California, 1975.
Cet article prsente le premier sous-systme de gestion de vues et dintgrit
dIngres, bas sur la modification de questions. Celle-ci est utilise afin de
gnrer des pr-tests intgrs aux requtes modifies.
[Stonebraker90] Stonebraker M., Jhingran A., Goh J., Potamianos S., On Rules,
Procedures, Caching, and Views in Database Systems , Proc. ACM SIGMOD
Int. Conf. on Management of Data, Atlantic City, New Jersey, p. 281-290, Juin
1990.
Suite aux expriences dIngres et Postgres, les auteurs commentent les mcanismes de gestion de vues, caches, procdures et rgles dans les SGBD. Ils proposent dintgrer tous ces composants autour du mcanisme de contrle de
concurrence, en tendant les types de verrous possibles. Les ides originales
dveloppes furent implmentes au cur de Postgres.
[Widom91] Widom J, Cochrane R., Lindsay B., Implementing Set-oriented
Production Rules as an Extension to Starburst , Proc. 17th Int. Conf. on Very
Large Data Bases, Barcelona, Spain, Morgan Kaufman Ed., p. 275-285, Sept.
1991.
Cet article dcrit limplmentation des rgles ralise dans Starburst au centre
de recherche dIBM en Californie. Ce prototype fut la source du systme de
triggers aujourdhui support par DB2.

280 BASES DE DONNES : OBJET ET RELATIONNEL

[Widom96] Widom J., Ceri S., Active Database Systems: Triggers and Rules for
Advanced Database Processing, Morgan-Kaufmann, San Fransisco, California,
1996.
Ce livre de synthse sur les bases de donnes actives prsente les concepts de
base, diffrents prototypes et de multiples expriences ralises sur le sujet.

Chapitre IX

LA GESTION DES VUES

1. INTRODUCTION
Pourquoi des vues ? Elles permettent de raliser, dans le monde des SGBD relationnels, le niveau externe des SGBD selon larchitecture ANSI/SPARC. Rappelons que
le niveau externe propose lutilisateur une perception de la base plus proche de ses
besoins, en termes de structures et de formats de donnes. De manire gnrale, les
vues garantissent une meilleure indpendance logique des programmes par rapport
aux donnes. En effet, le programme restera invariant aux modifications de schma
sil accde la base via une vue qui lisole de celle-ci. Lors des modifications du
schma de la base, ladministrateur modifiera seulement la dfinition des vues, et les
programmes dapplication pourront continuer travailler sans modification. Les vues
ont aussi un rle de scurit : lutilisateur ne peut accder quaux donnes des vues
auxquelles il a droit daccs ; ainsi, les donnes en dehors de la vue sont protges. De
manire dtourne, les vues permettent aussi certains contrles dintgrit lorsquelles
sont utilises pour les mises jour : on dit alors quon effectue une mise jour au travers dune vue. De telles mises jour sont trs contrles, comme nous le verrons cidessous.
Ces dernires annes, les vues ont trouv de nouvelles applications. Elles permettent
de dfinir des tables virtuelles correspondant aux besoins des programmes dapplication en termes de donnes. Dans le monde du client-serveur, les vues constituent un
lment essentiel doptimisation de performance. Par exemple, la dfinition dune vue

282 BASES DE DONNES : OBJET ET RELATIONNEL

jointure de deux tables, ou rsultant dun calcul dagrgat, vite au client les risques
de lire les tuples des tables et de faire le calcul de jointure ou dagrgat sur le client :
seules les donnes rsultant du calcul de la vue sont exportes sur le site client. On
laisse ainsi faire au serveur les calculs de jointure, agrgat, etc., quil sait en principe
bien faire. Dans le monde des entrepts de donnes et du dcisionnel, les vues peuvent tre concrtises. Elles permettent de raliser par avance des cumuls ou synthses plus sophistiqus de quantits extraites de la base selon plusieurs dimensions.
Des mcanismes de mises jour des vues concrtes lors des mises jour des relations
de base sont alors dvelopps afin dviter le recalcul des cumuls.
Les vues ont donc une importance croissante dans les bases de donnes. En pratique,
ce sont des relations virtuelles dfinies par des questions. Cette dfinition est stocke
dans la mtabase. Les vues sont interroges comme des relations normales.
Idalement, elles devraient pouvoir tre mises jour comme des relations normales.
Les vues concrtes sont calcules sur disques lors de leurs crations. Des mcanismes
de mise jour diffrentiels permettent le report efficace des mises jour des relations
de base. Toutes ces techniques sont aujourdhui bien matrises ; nous allons les prsenter ci-dessous.
Afin dillustrer les mcanismes de vues, nous utiliserons tout dabord la base de donnes viticole classique compose des relations :
BUVEURS (NB, NOM, PRENOM, ADRESSE, TYPE)
VINS (NV, CRU, REGION, MILLESIME, DEGRE)
ABUS (NV, NB, DATE, QUANTIT).

dcrivant respectivement les buveurs, les vins, et les consommations de vins quotidiennes. Comme habituellement, les cls des relations sont soulignes. Des vues
typiques sont les vins de Bordeaux, les gros buveurs, les quantits de vins bues par
crus, etc.
Pour des exemples plus avancs, intgrant notamment des agrgats complexes, nous
utiliserons la base MAGASINS suivante :
VENTES(NUMV, NUMPRO, NUMFOU, DATE, QUANTIT, PRIX)
PRODUITS (NUMPRO, NOM, MARQUE, TYPE,PRIX)
FOURNISSEURS (NUMFOU, NOM, VILLE, RGION, TELEPHONE)

Des vues typiques sont les quantits de produits vendus par fournisseurs et par mois,
les volutions des quantits commandes par rgion, etc. La relation Ventes dcrit les
ventes journalires de produits. NUMPRO est la cl de produits et NUMFOU celle de
fournisseurs. Dans une telle base de donnes, les faits de base sont les ventes, alors
que produits et fournisseurs constituent des dimensions permettant dexplorer les
ventes selon une ville ou une rgion par exemple.
Ce chapitre est organis comme suit. Aprs cette introduction, la section 2 expose
plus formellement le concept de vue, dtaille le langage de dfinition et prsente
quelques exemples simples de vues. La section 3 dveloppe les mcanismes dinterro-

La gestion des vues 283

gation de vues. La section 4 pose le problme de la mise jour des vues et isole les
cas simples tolrs par SQL. La section 5 traite des vues concrtes, notamment en vue
des applications dcisionnelles. En particulier, les techniques de report des mises
jour depuis les relations de base sur des vues concrtes avec agrgats sont tudies. La
conclusion voque quelques autres extensions possibles du mcanisme de gestion des
vues.

2. DFINITION DES VUES

Dans cette partie, nous dfinissons tout dabord prcisment ce quest une vue, puis
nous introduisons la syntaxe SQL pour dfinir une vue.
Notion IX.1 : Vue (View)
Une ou plusieurs tables virtuelles dont le schma et le contenu sont drivs de la base relle par un
ensemble de questions.

Une vue est donc un ensemble de relations dduites dune base de donnes, par composition des relations de la base. Le schma de la vue est un schma externe au sens
ANSI/SPARC. Dans la norme SQL, la notion de vue a t rduite une seule relation
dduite. Une vue est donc finalement une table virtuelle calculable par une question.
La syntaxe gnrale de la commande SQL1 de cration de vue est :
CREATE VIEW <NOM DE VUE> [ (LISTE DATTRIBUT)]
AS <QUESTION>
[WITH CHECK OPTION]

Le nom de vue est le nom de la table virtuelle correspondant la vue, la liste des attributs dfinit les colonnes de la table virtuelle, la question permet de calculer les tuples
peuplant la table virtuelle. Les colonnes du SELECT sont appliques sur celles de la
vue. Si les colonnes de la vue ne sont pas spcifies, celle-ci hrite directement des
colonnes du SELECT constituant la question.
La clause WITH CHECK OPTION permet de spcifier que les tuples insrs ou mis
jour via la vue doivent satisfaire aux conditions de la question dfinissant la vue. Ces
conditions seront vrifies aprs la mise jour : le SGBD testera que les tuples insrs
ou modifis figurent bien parmi la rponse la question, donc dans la vue. Ceci
garantit que les tuples insrs ou modifis via la vue lui appartiennent bien. Dans le
cas contraire, la mise jour est rejete si la clause WITH CHECK OPTION est prsente. Par exemple, si la vue possde des attributs dune seule table et la question un
critre de jointure avec une autre table, les tuples insrs dans la table correspondant

284 BASES DE DONNES : OBJET ET RELATIONNEL

la vue devront joindre avec ceux de lautre table. Ceci peut tre utilis pour forcer la
vrification dune contrainte rfrentielle lors dune insertion via une vue. Nous tudierons plus en dtail la justification de cette clause dans la partie traitant des mises
jour au travers de vues.
La suppression dune vue seffectue simplement par la commande :
DROP <NOM DE VUE>.

Cette commande permet de supprimer la dfinition de vue dans la mtabase (aussi

appele catalogue) de la base. En principe, sauf comme nous le verrons ci-dessous,
dans le cas des vues concrtes, une vue na pas dexistence physique : cest une
fentre dynamique (et dformante), non matrialise sur les disques, par laquelle un
utilisateur accde la base. La destruction de vue na donc pas se soucier de dtruire
des tuples.
Voici maintenant quelques exemples de dfinition de vues. Soit la base de donnes
Viticole dont le schma a t rappel en introduction.
(V1) Les vins de Bordeaux :
CREATE VIEW VINSBORDEAUX (NV, CRU, MILL, DEGR)
AS SELECT NV, CRU, MILLSIME, DEGR
FROM VINS
WHERE RGION = BORDELAIS.

Cette vue est simplement construite par une restriction suivie dune projection de la
table Vins. Chaque tuple de la vue est driv dun tuple de la table Vins.
(V2) Les gros buveurs :
CREATE VIEW GROSBUVEURS
AS SELECT NB, NOM, PRNOM, ADRESSE
FROM BUVEURS B, ABUS A
WHERE B.NB = A.NB AND A.QUANTIT > 10
WITH CHECK OPTION

Un tuple figure dans la vue GrosBuveurs si le buveur correspondant a commis au

moins un abus en quantit suprieure 10 verres. Cest l une dfinition trs large des
gros buveurs. La dfinition de vue comporte une restriction et une jointure. La clause
WITH CHECK OPTION prcise que lors dune insertion dun buveur via la vue, on
doit vrifier quil sagit bien dun gros buveur, cest--dire que le buveur a dj commis un abus de quantit suprieure 10. Notez que ceci spcifie une rgle dintgrit
rfrentielle lenvers pour les gros buveurs, ce qui est paradoxal.
(V3) Les quantits de vins bues par crus :
CREATE VIEW VINSBUS (CRU, MILL, DEGR, TOTAL)
AS SELECT CRU, MILLSIME, DEGR, SUM(QUANTIT)
FROM VINS V, ABUS A
WHERE V.NV = A.NV
GROUP BY CRU.

La gestion des vues 285

Cette vue fait appel une jointure (suivant une contrainte rfrentielle) suivie dun
calcul dagrgat (la somme). Un tuple de la table Vins donne plusieurs tuples lors de
la jointure (autant quil y a dabus) ; ceux-ci sont ensuite regroups selon le cru.
Pour la base MAGASINS, nous dfinirons seulement une vue (V4) documentant la
table VENTES selon les dimensions PRODUITS et FOURNISSEURS, rsultant
de jointures sur cl de ces tables :
CREATE VIEW VENTEDOC (NUMV,NOMPRO,MARQUE,NOMFOU,VILLE,RGION, DATE,
QUANTIT, PRIX) AS
SELECT V.NUMV,P.NOM,P.MARQUE,F.NOM,F.VILLE,F.RGION,V.DATE,
V.QUANTIT, V.PRIX
FROM VENTES V, PRODUITS P, FOURNISSEURS F
WHERE V.NUMPRO=P.NUMRO AND V.NUMFOU=F.NUMFOU

Nous verrons des vues plus complexes, notamment avec des agrgats ci-dessous.
La suppression des vues ci-dessus seffectuera par les commandes :
DROP
DROP
DROP
DROP

VINSBORDEAUX.
GROSBUVEURS.
VINBUS.
VENTESDOC.

3. INTERROGATION AU TRAVERS DE VUES

Du point de vue de lutilisateur, linterrogation au travers dune vue seffectue comme
pour une table normale. Le rle du serveur est alors denrichir la question avec la dfinition de vue quil retrouve dans la mtabase. Pus formellement, la dfinition dune
vue V sur des relations R1, R2...Rn est une fonction V = F(R1, R2...Rn), o F est une
expression de lalgbre relationnelle tendue avec des agrgats. F est donc une
expression de restriction, projection, jointure, union, diffrence et agrgats. Une question Q est exprime sur la vue en SQL. Il sagit aussi dune fonction calculant la
rponse R = Q(V), o Q est aussi une expression de lalgbre relationnelle tendue.
Calculer R partir de la base revient donc remplacer V dans la requte R = Q(V) par
sa dfinition. On obtient alors la fonction compose :
R = Q(F(R1, R2...Rn)).
Ce mcanisme est illustr figure IX.1. La requte rsultante peut alors tre passe
loptimiseur et le plan dexcution correspondant peut tre calcul. Cest ainsi que
fonctionnent les SGBD : ils gnrent la requte composition de la dfinition de vue et
de la requte usager, et traitent ensuite cette requte plus complexe, mais valuable
sur les relations de la base.

286 BASES DE DONNES : OBJET ET RELATIONNEL

Base
Vue
R1
...

;;;
;
Rponse

Rn

Figure IX.1 : Composition dune question Q avec la dfinition de vue F

Deux techniques sont possibles pour raliser la composition de la vue et de la requte

utilisateur : la transformation de la requte source appele modification de question,
ou la transformation de larbre relationnelle, parfois appele concatnation darbre.
Notion IX.2 : Modification de question (Query modification)
Mcanisme consistant modifier une question en remplaant certaines vues du FROM par les relations de base sources de ces vues et en enrichissant les conditions de la clause WHERE pour obtenir
le rsultat de la question initiale.

La modification de question est une technique invente dans le projet Ingres Berkeley
[Stonebraker75]. Elle permet de remplacer les vues par leurs dfinitions lors des
recherches ou dajouter des prdicats afin de vrifier des proprits avant dexcuter une
requte. La figure IX.2 illustre cette technique pour la recherche des gros buveurs habitant Versailles. Cette technique peut aussi tre utilise pour les mises jour afin denrichir le critre pour vrifier par exemple la non-violation de contraintes dintgrit.
(1)

Question
SELECT NOM, PRNOM
FROM GROSBUVEURS
WHERE ADRESSE LIKE VERSAILLES.

(2)

Dfinition de vue
CREATE VIEW GROSBUVEURS
AS SELECT NB, NOM, PRNOM, ADRESSE
FROM BUVEURS B, ABUS A
WHERE B.NB = A.NB AND A.QUANTIT > 10.

(3)

Question modifie
SELECT NOM, PRNOM
FROM BUVEURS B, ABUS A
WHERE B.ADRESSE LIKE VERSAILLES AND B.NB=A.NB AND A.QUANTIT>10.

Figure IX.2 : Exemple de modification de question

La gestion des vues 287

Notion IX.3 : Concatnation darbres (Tree concatenation)

Mcanisme consistant remplacer un nud pendant dans un arbre relationnel par un autre arbre
calculant le nud remplac.

La concatnation darbres est une technique invente dans le fameux systme R

San-Jos [Astrahan76]. La dfinition de vue se retrouve dans la mtabase sous la
forme dun arbre relationnel. Larbre rsultant de lanalyse de la question est simplement connect celui dfinissant la vue. Lensemble constitue un arbre qui reprsente
la question enrichie, qui est alors passe loptimiseur. La figure IX.3 illustre ce
mcanisme pour la recherche des gros buveurs habitant Versailles.
Rsultat

B.NOM, B.PRENOM
Question
B.ADRESSE =

Vue

"Versailles"

Vue

B.NB, B.NOM, B.PRENOM, B.ADRESSE

A.NB

B.NB
Dfinition de vue

A.QTE >10

BUVEURS B

ABUS A

Figure IX.3 : Exemple de concatnation darbres

288 BASES DE DONNES : OBJET ET RELATIONNEL

4. MISE JOUR AU TRAVERS DE VUES

Dans cette section, nous examinons, dun point de vue pratique puis thorique, le problme des mises jour au travers des vues.

4.1. VUE METTABLE JOUR

Le problme est de traduire une mise jour (ou une insertion, ou une suppression)
portant sur une vue en mise jour sur les relations de la base. Toute vue nest pas
mettable jour.
Notion IX.4 : Vue mettable jour (Updatable view)
Vue comportant suffisamment dattributs pour permettre un report des mises jour dans la base
sans ambigut.

De manire plus fine, une vue peut tre mettable jour en insertion, en suppression,
ou en modification. Par exemple, la vue V1 dfinissant les vins de Bordeaux est totalement mettable jour, cest--dire que toute opration INSERT, DELETE ou
UPDATE est reportable sur la base. Ajoutons la vue V2 dfinissant les gros buveurs
la quantit bue (QUANTIT) aprs le SELECT. Ceci pose problme lors dune insertion : comment gnrer le numro de vins (NV) et la date (DATE) de labus qui doit
obligatoirement tre insr puisque NB, NV, DATE est cl de ABUS ? Si lon obligeait
lexistence de labus avant dinsrer le buveur il ny aurait pas de problme. La clause
WITH CHECK OPTION permet justement de vrifier lexistence de tels tuples.
Malheureusement, sa prsence simultane la contrainte rfrentielle ABUS.NB
REFERENCE BUVEURS est impossible ! La suppression et la modification de tuples
existants ne pose pas non plus de problme. La vue V3 est encore plus difficile
mettre jour : il est impossible de dterminer les quantits lmentaires partir de la
somme ! En rsum, lutilisation de certaines vues en mises jour est problmatique.

4.2. APPROCHE PRATIQUE

En pratique, la plupart des systmes rsolvent le problme en restreignant les possibilits de mise jour des vues monotable : seuls les attributs dune table de la base
doivent apparatre dans la vue. En imposant de plus que la cl de la table de la base
soit prsente, il est possible de dfinir une stratgie de mise jour simple. Lors dune
insertion, on insre simplement les nouveaux tuples dont la cl nexiste pas, avec des
valeurs nulles pour les attributs inexistants. Lors dune suppression, on supprime les
tuples rpondant au critre. Lors dune modification, on modifie les tuples rpondant

La gestion des vues 289

au critre. La dfinition de vue peut rfrencer dautres tables qui permettent de prciser les tuples de la vue. En thorie, il faut vrifier que les tuples insrs, supprims ou
modifis appartiennent bien la vue. En pratique, SQL neffectue cette vrification
que si elle a t demande lors de la dfinition de vue par la clause WITH CHECK
OPTION.
Restreindre la mise jour des vues monotables est beaucoup trop fort. On peut simplement tendre, au moins en insertion et en suppression, aux vues multitables comportant les cls des tables participantes. Les attributs non documents sont alors remplacs par des valeurs nulles lors des insertions. Cette solution pratique gnre cependant des bases de donnes avec de nombreuses valeurs nulles. Elle sera souvent
interdite dans les systmes commercialiss. Ceux-ci sont donc loin de permettre toutes
les mises jour thoriquement possibles, comme le montre la figure IX.4.
Ensemble de toutes
les vues

Vues thoriquement
mettables jour

Vues mettables jour en SQL

(la qualification peut invoquer
plusieurs tables)

Vues multitables
avec cls
Vues monotables
avec cls

Figure IX.4 : Classification des vues selon les possibilits de mise jour

4.3. APPROCHE THORIQUE

Le problme thorique est de dfinir une stratgie de report qui prserve la vue quelle
que soit la mise jour : si lon calcule la vue et on lui applique la mise jour, on doit
obtenir le mme rsultat que si on applique les mises jour la base et on calcule
ensuite la vue. Lquation u(V(B)) = V(u(B)) doit donc tre vrifie, en notant
B la base, v le calcul de vue, u la mise jour sur la vue et u les mises jour correspondantes sur la base. Autrement dit, le diagramme de la figure IX.5 doit commuter.
Dautre part, il est vident quune bonne stratgie doit prserver le complment de la
base, cest--dire toutes les informations de la base qui ne figurent pas dans la vue
[Bancilhon81]. Selon ces hypothses raisonnables, le problme du calcul de u na pas
toujours une solution unique [Abiteboul91].

290 BASES DE DONNES : OBJET ET RELATIONNEL

Mise jour u

Vue
as Question V

BD

Mise jour rpercute u

Vue
as Question V

BD

Figure IX.5 : Diagramme de mise jour et drivation de vue

Une approche intressante a t propose rcemment dans [Bentayeb97]. Lide est de

dfinir linverse de chaque opration relationnelle. En effet, soit V = E(R1, R2...Rn) une
dfinition de vue. E est une expression de lalgbre relationnelle. Si lon peut dfinir
linverse de chaque opration de lalgbre sur une relation, on pourra alors calculer R1
R2... Rn = E1(V). La rpercussion dune mise jour de V se fera simplement en unifiant Ri avec la projection de E1(V) sur Ri. Le problme de linversion de lalgbre
relationnelle a aussi t tudi dans [Imielinski83]. Dsignons par t un tuple de la vue V
et par [t] une table compose de ce seul tuple. Limage rciproque dun tuple t par E
peut tre vue comme un ensemble de tables T1, T2..., Tn telles que E (T1, T2...,
Tn) = [t]. Les tables Ti peuvent possder des attributs inconnus dsigns par des
variables x,y, etc. Elles ne doivent pas contenir de tuples inutiles pour composer t, donc
pour tout tuple ti Ti, E (T1..., Ti-[ti]..., Tn) [t]. Insrer le tuple t dans la vue V a alors
pour effet de modifier les relations de base Ri en les unifiant avec les relations Ti. Lunification est une opration difficile, pas toujours possible, explicite dans [Bentayeb97]
sous forme dalgorithmes pour linsertion et la suppression.
En rsum, la mise jour au travers de vue est un problme complexe, bien tudi en
thorie, mais dont les solutions pratiques sont rduites. Certains SGBD permettent des
mises jour de vues multitables en laissant ladministrateur dfinir la stratgie de report.

5. VUES CONCRTES ET DCISIONNEL

Dans cette section, nous abordons le problme des vues concrtes. Celles-ci sont particulirement intressantes dans les entrepts de donnes (data warehouse), o elles
facilitent lanalyse de donnes (OLAP) pour laide la dcision.

5.1. DFINITION
Une vue est en principe une fentre dynamique sur une base de donnes, dont une partie est instancie lors dune question. La concrtisation de la vue par le serveur peut

La gestion des vues 291

tre plus avantageuse si celle-ci est souvent utilise et si les tables sources sont peu
modifies. Ainsi, certains serveurs supportent des vues concrtes.
Notion IX.5 : Vue concrte (Concrete view)
Table calcule partir des tables de la base par une question et matrialise sur disques par le
SGBD.

Une vue concrte est calcule ds sa dfinition et mise jour chaque fois quune transaction modifie la base sous-jacente. La mise jour seffectue si possible en diffrentiel, cest--dire que seuls les tuples modifis sont pris en compte pour calculer les
modifications apporter la vue. Mais ceci nest pas toujours possible. Dans le cas de
vues dfinies par des slections, projections et jointures (SPJ), le report diffrentiel
des insertions est simple, celui des mises jour de type suppression ou modification
beaucoup plus difficile. Pour rpercuter suppressions et mises jour, il faut en gnral
retrouver au moins partiellement les chanes de drivation qui ont permis de calculer les tuples de la vue concrte. Dans le cas gnral (vues avec diffrence, agrgat,
etc.), les reports diffrentiels sont trs difficiles, comme nous le verrons ci-dessous
Les vues concrtes sont dfinissables par une requte du type :
CREATE CONCRETE VIEW <SPCIFICATION DE VUE>.

Elles sont particulirement intressantes lorsquelles contiennent des agrgats, car

elles permettent de mmoriser des rsums compacts des tables. Par exemple, il est
possible de dfinir des vues concrtes avec agrgats de la table VENTES dfinie dans
lintroduction :
VENTES(NUMV, NUMPRO, NUMFOU, DATE, QUANTIT, PRIX)

Les tables PRODUITS et FOURNISSEURS permettent de gnrer des exemples de

vues avec jointures :
PRODUITS (NUMPRO, NOM, MARQUE, TYPE,PRIX)
FOURNISSEURS (NUMFOU, NOM, VILLE, RGION, TELEPHONE)

La vue suivante donne les ventes de produits par fournisseur et par jour :
CREATE CONCRETE VIEW VENTESPFD(NUMPRO,NUMFOU,DATE,COMPTE,QUANTOT)AS
SELECT NUMPRO,NUMFOU,DATE,COUNT(*)AS COMPTE,SUM(QUANTIT) AS QUANTOT
FROM VENTES
GROUP BY NUMPRO, NUMFOU, DATE.

La notation VENTESPFD signifie ventes groupes par produits, fournisseurs et

dates . Une vue plus compacte liminera par exemple les fournisseurs :
CREATE CONCRETE VIEW VENTESPD (NUMPRO,DATE,COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,COUNT(*)AS COMPTE,SUM(QUANTIT) AS QUANTOT
FROM VENTES
GROUP BY NUMPRO, DATE.

292 BASES DE DONNES : OBJET ET RELATIONNEL

Notez que la vue VENTESPD peut tre drive de la vue VENTESPFD par la dfinition suivante :
CREATE CONCRETE VIEW VENTESPD (NUMPRO, DATE, COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,SUM(COMPTE)AS COMPTE,SUM(QUANTOT) AS QUANTOT
FROM VENTESPFD
GROUP BY NUMFOU.

Il est aussi possible de driver des vues concrtes avec agrgats par jointures avec les
tables dimensions, par exemple en cumulant les ventes par rgion des fournisseurs :
CREATE CONCRETE VIEW VENTESPRD(NUMPRO,RGION,DATE,COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,COUNT(*)AS COMPTE,SUM(QUANTIT) AS QUANTOT
FROM VENTES V, FOURNISSEURS F
WHERE V.NUMFOU = F.NUMFOU
GROUP BY V.NUMPRO, F.RGION.

Toutes ces vues concrtes sont trs utiles pour laide la dcision dans un contexte
dentrept de donnes, o lon souhaite analyser les ventes selon diffrentes dimensions [Gray96].

5.2. STRATGIE DE REPORT

Les vues concrtes doivent tre mises jour lors de la mise jour des relations de la
base. Un problme important est de dterminer une stratgie de report efficace des
mises jour effectues sur les relations de base. Bien sr, il est possible de recalculer
compltement la vue aprs chaque mise jour, mais ceci est inefficace.
Une meilleure stratgie consiste maintenir la vue concrte de manire diffrentielle, ou
si lon prfre incrmentale. Soit une vue V = F(R1, R2...Rn) dfinie sur les relations
R1, R2... Rn. Des mises jour sont effectues par exemple sur la relation Ri. Soient des
insertions de tuples notes +Ri et des suppressions notes Ri. Une modification de
tuples existants peut toujours se ramener une suppression suivie dune insertion.
Leffet net des mises jour sur Ri est donc Ri = (Ri Ri) +Ri. Le problme est de
calculer leffet net sur V, qui peut tre exprim par des tuples supprims, puis par des
tuples insrs comme suit : V = (V V) +V. Dans certains cas, les mises jour
apporter sur V (V, +V) peuvent tre calcules partir de celles apportes sur Ri
(Ri, +Ri). La vue V est alors qualifie dauto-maintenable [Tompa88, Gupta95]
Notion IX.6 : Vue auto-maintenable (Self-maintenable view)
Vue concrte contenant suffisamment dinformations pour tre mise jour partir des mises jour
des relations de base, sans accs aux tuples des relations de la base.

Cette notion est trs importante dans les architectures distribues (client-serveur,
entrepts de donnes, copies), o la vue est matrialise sur un site diffrent de celui

La gestion des vues 293

de la base. Elle est illustre figure IX.6. Il est possible de distinguer lauto-maintenabilit en insertion ou en suppression, cest--dire lors des insertions ou suppressions
dans une relation de base. Lauto-maintenabilit peut aussi tre caractrise pour
chaque relation, et enfin gnralise au cas dun groupe de vues [Huyn97].
mise jour

mise jour

BD

BD
V

F()

V
F()

F()

F(, )

V
BD

BD
V

Vue auto-maitenable :
lors dune mise jour celle-l
suffit pour mettre jour la vue.

Vue non auto-maitenable : lors dune mise jour ,

celle-l ne suffit pas pour mettre jour la vue ; il faut
en plus les tuples de la base.

Figure IX.6 : Maintenance de vues avec ou sans accs la base

En guise dillustration, considrons la vue V1 des vins de Bordeaux dfinie ci-dessus

comme une restriction de la table Vins : V1 = REGION = Bordelais (VINS). Cette
vue est auto-maintenable. En effet, comme la restriction commute avec la diffrence,
il est simple de calculer :
+V1 = REGION = Bordelais (+VINS).
-V1 = REGION = Bordelais (-VINS).
Par suite, les mises jour apporter V1 sont calculables sans accder la table
VINS, mais seulement partir des mises jour de VINS. Malheureusement, ds
quune vue comporte des projections avec limination de doubles, des jointures ou
des diffrences, elle nest gnralement plus auto-maintenable [Fabret94]. Par
exemple, dans le cas de projections sans double, lorsque lon enlve un tuple dune
table source, on ne sait plus sil faut lenlever dans la vue car sa projection peut provenir dun autre tuple. De mme, pour calculer le tuple enlever dans une vue jointure lors dune suppression dun tuple dans une table, il faut accder lautre table
pour trouver les tuples jointures. De manire gnrale, savoir si une vue est auto-

294 BASES DE DONNES : OBJET ET RELATIONNEL

maintenable savre difficile, et mme trs difficile lorsque la vue contient des agrgats [Gupta96]. Ce dernier cas est examin dans le paragraphe qui suit.
Dans le cas dune vue calcule par slections, projections et jointures (SPJ), les problmes essentiels semblent provenir des jointures. Toute vue comportant toutes les informations de la base ncessaires son calcul (attributs de projection et de jointure, tuples)
est auto-maintenable en insertion ; en effet, la nouvelle instance de la vue V est :
V = F (R1..., Ri +Ri..., Rn) .
Comme F ne contient pas de diffrence, on a :
V = F (R1..., Ri..., Rn) F (R1..., +Ri..., Rn) = V F (R1..., +Ri..., Rn)
do lon dduit :
V+ = F (R1..., +Ri..., Rn).
Si F (R1..., +Ri..., Rn) est calculable partir de V et +Ri, la vue est auto-maintenable en insertion. Tel est le cas condition que V contienne les attributs et les tuples
de R1...Rn ncessaires son calcul. Les jointures externes seules ne perdent pas de
tuples. Donc, une vue calcule par des jointures externes et projections est gnralement auto-maintenable en insertion.
Pour lauto-maintenabilit en suppression, le problme est plus difficile encore. On
ne peut distribuer F par rapport Ri Ri, ce qui rend le raisonnement prcdent
caduc. Cependant, toute vue contenant les attributs de R1..., Rn ncessaires son calcul et au moins une cl de chaque relation de base est auto-maintenable. En effet,
lorigine des tuples de la vue peut tre identifie exactement par les cls, ce qui permet de reporter les suppressions.
Des structures annexes associes une vue peuvent aussi tre maintenues [Colby96,
Colby97]. Les reports sur la vue concrte peuvent tre diffrs. La vue devient alors
un clich (snapshot) [Adiba80]. Beaucoup de SGBD supportent les clichs.
Notion IX.7 : Clich (Snapshot)
Vue concrte dune base de donnes mise jour priodiquement.

La gestion de structures diffrentielles associes au clich, par exemple les mises

jour sur chaque relation dont il est driv (les Ri), peut permettre un accs intgr
la vue concrte jour et conduit au dveloppement dalgorithmes de mise jour spcialiss [Jagadish97].

5.3. LE CAS DES AGRGATS

Le cas de vues avec agrgats est particulirement important pour les systmes dcisionnels, comme nous allons le voir ci-dessous. Le problme de lauto-maintenabilit

La gestion des vues 295

des agrgats a t tudi dans [Gray96], qui propose de distinguer trois classes de
fonctions : distributives, algbriques, et non rgulires (holistic).
Les fonctions agrgatives distributives peuvent tre calcules en partitionnant leurs
entres en ensembles disjoints, puis en appliquant la fonction chacun, enfin en agrgeant les rsultats partiels pour obtenir le rsultat final. Une fonction distributive
AGG vrifie donc la proprit :
AGG(v1,v2...vn) = AGG(AGG(v1...vi},AGG(vi+1..vn)).

Parmi les fonctions standard de calcul dagrgats, SUM, MIN et MAX sont distributives.
La fonction COUNT, qui compte le nombre dlments sans liminer les doubles, peut
tre considre comme distributive en linterprtant comme une somme de comptes
partiels gaux 1 pour des singletons ; par contre, COUNT DISTINCT nest pas distributive car se pose le problme des doubles.
Les fonctions agrgatives algbriques peuvent tre exprimes comme fonctions algbriques de fonctions distributives. Par exemple, la moyenne AVG est une fonction
algbrique, car AVG(v1...vn) = SUM(v1...vn) / COUNT(v1...vn).
Pour le problme de la maintenance des vues concrtes, les fonctions algbriques peuvent tre remplaces par plusieurs fonctions distributives ; par exemple, une colonne
AVG sera remplace par deux colonnes SUM et COUNT.
Les fonctions non rgulires ne peuvent tre calcules par partitions. Des vues comportant de telles fonctions sont a priori non auto-maintenables.
La notion de vue auto-maintenable sapplique tout particulirement aux vues rsultant
dune agrgation dune table de base. On parle alors dagrgats auto-maintenables.
Notion IX.8 : Agrgats auto-maintenables (Self-maintenable aggregate)
Ensemble dagrgats pouvant tre calculs partir des anciennes valeurs des fonctions dagrgats
et des mises jour des donnes de base servant au calcul de la vue.

Comme pour les vues en gnral, on peut distinguer lauto-maintenabilit en insertion

et en suppression. [Gray96] a montr que toutes les fonctions dagrgats distributives
sont auto-maintenables en insertion. En gnral, ce nest pas le cas en suppression.
Savoir quand liminer un tuple de la vue pose problme. En introduisant un compteur
du nombre de tuples source dans la base pour chaque tuple de la vue (COUNT(*)), il
est facile de dterminer si un tuple doit tre supprim : on le supprime quand le compteur passe 0. COUNT(*) est toujours auto-maintenable en insertion comme en suppression. Lorsque les valeurs nulles sont interdites dans lattribut de base, SUM et
COUNT(*) forment un ensemble auto-maintenables : SUM est maintenu par ajout ou
retrait de la valeur, et COUNT(*) par ajout ou retrait de 1 ; COUNT(*) permet de
savoir quand supprimer le tuple. En prsence de valeurs nulles, il devient difficile de
maintenir la somme. MIN et MAX sont aussi des fonctions non auto-maintenable en sup-

296 BASES DE DONNES : OBJET ET RELATIONNEL

pression. En effet, si on supprime la valeur minimale ou maximale, on ne peut recalculer

le nouveau minimum ou maximum qu partir des valeurs figurant dans la base.
Par exemple, la vue :
CREATE CONCRETE VIEW VENTESPFD (NUMPRO,NUMFOU,DATE,COMPTE,QUANTOT)AS
SELECT NUMPRO,NUMFOU,COUNT(*)AS COMPTE,SUM(QUANTIT) AS QUANTOT
FROM VENTES
GROUP BY NUMPRO, NUMFOU

est compose dagrgats auto-maintenables en insertion et en suppression, donc automaintenables condition que Quantit ne puisse tre nulle (cest--dire de valeur
inconnue) dans lentre dune suppression : il faut alors aller rechercher sa valeur
dans la base pour enlever la vritable quantit la somme.
Par contre, la vue :
CREATE CONCRETE VIEW VENTESPFD (NUMPRO,NUMFOU,DATE,COMPTE,QUANTOT)AS
SELECT NUMPRO,NUMFOU,COUNT(*)AS COMPTE,MIN(QUANTIT) AS QUANMIN
FROM VENTES
GROUP BY NUMPRO, NUMFOU

est compose dagrgats auto-maintenables en insertion mais pas en suppression (problme avec le MIN).

6. CONCLUSION
La gestion de vues en interrogation est un problme bien compris dans les SGBD relationnels depuis la fin des annes 70. Nous avons introduit ci-dessus ses principes de
base. Le report des mises jour des vues sur la base est un problme plus difficile
encore. Des solutions pratiques et gnrales restent inventer. Lutilisation de dclencheurs sur les vues peut tre une solution pour dfinir les stratgies de report.
La matrialisation des vues a connu une nouvelle activit ces dernires annes, avec
lapparition des entrepts de donnes. Les vues avec agrgats sont particulirement
importantes pour grer des donnes rsumes, en particulier le fameux cube de donnes trs utile en dcisionnel. Les techniques sont maintenant connues. Il reste les
mettre en uvre efficacement dans les systmes, qui gre pour linstant peu de redondances et souvent des organisations physiques ad hoc pour le multidimensionnel. Ceci
nest plus vrai dans les entrepts de donnes, qui utilisent souvent les vues concrtes
pour faciliter les calculs dagrgats [Bello98].
Les vues connaissent aussi un nouveau dveloppement dans le monde objet avec lapparition de vues orientes objets au-dessus de bases de donnes relationnelles par exemple.
Nous aborderons cet aspect dans le cadre des SGBD objet ou objet-relationnel.

La gestion des vues 297

7. BIBLIOGRAPHIE
[Abiteboul91] Abiteboul S., Hull R., Vianu V., Foundations of Databases, AddisonWesley, 1995.
Comme son nom lindique, ce livre traite des fondements des bases de donnes
relationnelles et objet. Souvent fond sur une approche logique ou algbrique,
il reprend toute la thorie des bases de donnes, y compris le problme de la
mise jour au travers des vues, parfaitement bien analys.
[Adiba80] Adiba M., Lindsay B., Database Snapshots , Intl. Conf. on Very Large
Databases, IEEE Ed., Montral, Canada, Sept. 1980.
Cet article introduit la notion de clich (snapshot) et montre son intrt, notamment dans les bases de donnes rparties. Il dcrit aussi la ralisation effectue
dans le fameux systme R*.
[Adiba81] Adiba M., Derived Relations : A Unified Mechanism for Views,
Snapshots and Distributed Data , Intl. Conf. on Very Large Databases, IEEE
Ed., Cannes, France, Sept. 1981.
Lauteur gnralise les clichs aux relations drives, dont il montre lintrt dans
les bases de donnes rparties. Il discute aussi les algorithmes de mise jour.
[Astrahan76] Astrahan M. M. et al., System R : Relational Approach to Database
Management , ACM TODS, V1, N2, Juin 1976.
Larticle de rfrence sur le fameux System R. Il dcrit aussi le mcanisme de
concatnation darbres implment pour la premire fois dans ce systme.
[Bancilhon81] Bancilhon F., Spyratos N., Update Semantics and Relational
Views , ACM TODS, V4, N6, Dec. 1981, p. 557-575.
Un article de rfrence en matire de mises jour de vues. Les auteurs posent
le problme en termes dinvariance de la vue suite aux mises jour directes ou
rpercutes dans la base. Ils montrent quune condition suffisante de maintenabilit est la possibilit de dfinir des stratgies de report complments
constants.
[Bello98] Bello R.G, Dias K., Downing A., Freenan J., Norcott D., Dun H.,
Witkowski A., Ziauddin M., Materialized Views in Oracle , Intl. Conf. on
Very Large Databases, Morgan & Kauffman Ed., New York, USA, Aot 1998,
p. 659-664.
Cet article explique la gestion des vues matrialises dans Oracle 8. Celles-ci
sont utilises pour les entrepts de donnes et la rplication. Elles peuvent tre
rafrachies la fin des transactions, sur demande ou priodiquement. Les
rafrachissements par lots sont optimiss. Loptimisation des requtes prend en
compte les vues concrtes laide dune technique de rcriture base sur un
modle de cot.

298 BASES DE DONNES : OBJET ET RELATIONNEL

[Bentayeb97] Bentayeb F., Laurent D., Inversion de lalgbre relationnelle et mises

jour , 13e Journes Bases de Donnes Avances (BDA 97), Ed. INRIA,
Grenoble, 1997, p. 199-218.
Cet article propose une approche dterministe de la mise jour au travers de
vue, fonde sur la notion dimage rciproque. Des algorithmes dinversion de
lalgbre sont proposs. Une stratgie de report avec stockage ventuel dans la
vue concrtise est tudie.
[Chamberlin75] Chamberlin D., Gray J., Traiger I., Views, Authorization and
Locking in a Relational Database System , Proc. National Computer Conf.,
1975, p. 425-430.
Cet article dtaille les mcanismes de vue, dautorisation et de verrouillage
implante dans System R.
[Colby96] Colby L.S., Griffin T., Libkin L., Mumick I., RTrickey H., Algorithms
for Deferred View Maintenance , Proc. ACM SIGMOD Int. Conf. on
Management of Data, Montreal, USA, Mai 1996.
[Colby97] Colby L.S., Kawaguchi A., Lieuwen D.F, Mimick I.S., Ross K.,
Supporting Multiple View Maintenance Policies , Proc. ACM SIGMOD Int.
Conf. on Management of Data, Tucson, USA, p. 405-416, Mai 1997.
Ces deux articles explorent diffrentes stratgies pour la maintenance de vues
concrtes. Les auteurs proposent notamment des algorithmes qui garantissent
la cohrence dans des cas de reports des mises jour en temps diffrs, avec
divers niveaux et groupes de vues.
[Dayal82] Dayal U., Bernstein P., On the Correct Translation of Update Operations
on Relational Views , ACM TODS, V8, N3, Dept. 1982.
Cet article discute des stratgies de report de mise jour au travers de vues et
dfinit des critres de correction.
[Fabret94] Fabret F., Optimisation du calcul incrmental dans les langages de rgles
pour bases de donnes, Thse, Universit de Versailles SQ, Dcembre 1994.
Cette thse prsente une caractrisation des vues concrtes auto-maintenables dans
les bases de donnes. Les vues sont dfinies par projection, jointure, union, diffrence et restriction. Cette thse propose aussi des algorithmes afin de maintenir des
rseaux de vues pour acclrer le calcul des requtes dans une BD dductive.
[Gray96] Gray J., Bosworth A., Layman A., Pirahesh H., Datacube : A relational
Aggregation Operator Generalizing Group-by, Cross-tab, and Sub-totals ,
IEEE Int. Conf. on Data Engineering, p. 152-159, 1996.
Cet article introduit un nouvel oprateur dagrgation, appel Datacube, afin
de calculer des agrgats multidimensionnels. Nous tudierons plus en dtail les
oprateurs des bases de donnes multidimensionnelles dans le cadre du chapitre sur les entrepts de donnes.

La gestion des vues 299

[Gupta95] Gupta M., Mumick I.S., Maintenance of Materialized Views : Problems,

Techniques and Applications , IEEE Data Engineering Bulletin, special Issue
on Materialized Views and data Warehousing, N18(2), Juin 1995.
Les auteurs introduisent les diffrents problmes poss par la gestion de vues
concrtes dans une base de donnes. Ils proposent quelques solutions et montrent quelques applications possibles pour la gestion dentrepts de donnes
performants.
[Gupta96] Gupta A., Jagadish H.V., Mumick I.S., Data Integration Using SelfMaintainable Views , Intl. Conf. on Extended Database Technology (EDBT),
LCNS N1057, Avignon, France, 1996, p. 140-144.
Cet article dfinit prcisment la notion de vue auto-maintenable. Les auteurs
tablissent des conditions suffisantes pour quune vue selection-projection-jointure soit auto-maintenable.
[Huyn97] Huyn N., Multiple-View Self-Maintenance in Data Warehousing
Environments Intl. Conf. on Very Large Databases, Morgan & Kauffman Ed.,
Athens, Grce, Aot 1997, p. 26-35.
Cet article tudie le problme de lauto-maintenabilit dun ensemble de vues.
Il propose des algorithmes qui permettent de tester si un groupe de vues est
auto-maintenable par gnration de requtes SQL. De plus, dans le cas o la
rponse est positive, les algorithmes gnrent les programmes de mises jour.
[Jagadish97] Jagadish H.V., Narayan P.P.S., Seshadri S., Sudarshan S., Kanneganti R.,
Incremental Organization for Data Recording and Warehousing , Intl. Conf.
on Very Large Databases, Morgan & Kauffman Ed., Athens, Greece, Aot
1997, p. 16-25.
Les auteurs proposent deux techniques, la premire base sur des squences
tries insres dans un B-tree, la seconde sur une organisation par hachage,
pour stocker les enregistrements lors de leur arrive dans un entrept de donnes, avant leur intgration dans les vues matrialises. Ces techniques prcisment values supportent des environnements concurrents avec reprises.
[Keller87] Keller M.A., Comments on Bancilhon and Spyratoss Update Semantics
and Relational Views , ACM TODS, V12, N3, Sept. 1987, p. 521-523.
Cet article montre que la condition suffisante de maintenabilit quest la possibilit de dfinir des stratgies de report complments constants est trop forte,
et quelle peut conduire interdire des stratgies intressantes.
[Kerherv86] Kerherv B., Vues Relationnelles : Implmentation dans un SGBD
centralis et distribu , Thse de doctorat, Universit de Paris VI, Mars 1986.
Cette thse dcrit limplmentation de vues ralise dans le SGBD SABRE
lINRIA. Un mcanisme de gestion de vues concrtes par manipulation de
compteurs au niveau des oprateurs relationnels est aussi propos.

300 BASES DE DONNES : OBJET ET RELATIONNEL

[Nicolas83] Nicolas J-M., Yazdanian K., An Outline of BDGen : A Deductive

DBMS , Woldwide IFIP Congress, Paris, 1983.
Cet article introduit le systme dductif BDGen ralis au CERT Toulouse. Il
maintient des vues dfinies par des rgles en utilisant des compteurs de raisons
de prsence dun tuple.
[Stonebraker74] Stonebraker M.R., A Functional View of Data Independance ,
ACM SIGMOD Workshop on Data Description, Access and Control, ACM Ed.,
mai 1974.
Un des premiers articles de Mike Stonebraker, lun des pres du systme
INGRES. Il plaide ici pour lintroduction de vues assurant lindpendance
logique.
[Stonebraker75] Stonebraker M., Implmentation of Integrity Constraints and Views
by Query Modification , Proc. ACM-SIGMOD Intl. Conf. On Management of
data, San Jos, CA 1975.
Cet article propose de modifier les questions au niveau du source par la dfinition de vues pour rpondre aux requtes. La technique est formalise avec le
langage QUEL dINGRES, o elle a t implmente.

Chapitre X

OPTIMISATION DE QUESTIONS
1. INTRODUCTION
La plupart des SGBD relationnels offrent aujourdhui des langages de manipulation
bass sur SQL, non procduraux et utilisant des oprateurs ensemblistes. Avec de tels
langages, lutilisateur dfinit les donnes quil veut visualiser sans fournir les algorithmes daccs aux donnes. Le but des algorithmes doptimisation de questions est
justement de dterminer les algorithmes daccs. Ces algorithmes sont aussi utiles
pour les mises jour, car une mise jour est une question suivie dun remplacement.
Plus prcisment, il sagit dlaborer un programme daccs compos doprations de
bas niveau attaches des algorithmes efficaces de recherche dans les tables. Il est
essentiel pour un systme de dterminer des plans daccs optimiss ou au moins
proches de loptimum pour les questions les plus frquentes. Ce nest pas l un problme facile, comme nous allons le voir dans ce chapitre.
Depuis les annes 1975, loptimisation de requtes dans les bases de donnes relationnelles a reu une attention considrable [Jarke84, Kim85, Graefe93]. Les systmes ont
beaucoup progress. Alors que les premiers taient trs lents, capables seulement
dexcuter quelques requtes par seconde sur les bases de donnes du benchmark
TPC/A ou B [Gray91], ils supportent aujourdhui des milliers de transactions par
seconde. Bien sr, cela nest pas d seulement loptimiseur, mais aussi aux progrs
du matriel (les temps dentre-sortie disque restent cependant de lordre de la dizaine
de millisecondes) et des mthodes daccs. Loptimiseur est donc un des composants

302 BASES DE DONNES : OBJET ET RELATIONNEL

essentiels du SGBD relationnel ; avec les nouveaux SGBD objet-relationnel ou objet,

il devient encore plus complexe. Dans ce chapitre, nous nous consacrons au cas relationnel. Nous tudierons plus loin dans cet ouvrage le cas des nouveaux SGBD, o
loptimiseur doit tre extensible, cest--dire capable de supporter des oprateurs non
prvus au dpart.
Classiquement, un optimiseur transforme une requte exprime dans un langage
source (SQL) en un plan dexcution compos dune squence doprations de bas
niveau ralisant efficacement laccs aux donnes. Le langage cible est donc constitu
doprateurs de bas niveau, souvent drivs de lalgbre relationnelle complte par
des informations de niveau physique, permettant de dterminer lalgorithme choisi
pour excuter les oprateurs [Selinger79]. Ces informations associes chaque oprateur, appeles annotations, dpendent bien sr du schma interne de la base (par
exemple, de lexistence dun index) et de la taille des tables. Elles compltent utilement lalgbre pour choisir les meilleurs chemins daccs aux donnes recherches.
Au-del de lanalyse de la question, loptimisation de requtes est souvent divise en
deux phases : loptimisation logique, qui permet de rcrire la requte sous une
forme canonique simplifie et logiquement optimise, cest--dire sans prendre en
compte les cots daccs aux donnes, et loptimisation physique, qui effectue le
choix des meilleurs algorithmes pour les oprateurs de bas niveau compte tenu de la
taille des donnes et des chemins daccs disponibles. Loptimisation logique reste au
niveau de lalgbre relationnelle, alors que loptimisation physique permet en particulier dlaborer les annotations. Les optimisations logique et physique ne sont malheureusement pas indpendantes ; les deux peuvent en effet changer lordre des oprateurs dans le plan dexcution et modifier le cot du meilleur plan retenu.
Ce chapitre prsente dabord plus prcisment les objectifs de loptimisation et introduit les lments de base. La section 3 est consacre ltude des principales
mthodes doptimisation logique ; celles-ci recherchent en gnral la question la plus
simple quivalente la question pose et utilise une heuristique de restructuration
algbrique pour laborer une forme canonique. Nous abordons ensuite ltude des diffrents algorithmes daccs physique aux donnes : slection, tri, jointure et calcul
dagrgats. Les variantes sans index et avec index des algorithmes sont discutes.
Pour chaque algorithme, un cot approch est calcul en nombre dentres-sorties. En
effet, loptimisation physique ncessite un modle de cot pour estimer le cot de
chaque plan dexcution afin de choisir le meilleur, ou au moins un proche du
meilleur. Un modle de cot complet est dcrit au paragraphe 5. Enfin, le paragraphe
6 rsume les stratgies essentielles permettant de retrouver un plan dexcution
proche de loptimal. En conclusion, nous discutons des problmes plus avancs en
matire doptimisation relationnelle, lis au paralllisme et la rpartition des donnes.

Optimisation de questions 303

2. LES OBJECTIFS DE LOPTIMISATION

Cette section propose deux exemples de bases de donnes, situe les objectifs de loptimisation, et dfinit les concepts de base essentiels.

2.1. EXEMPLES DE BASES ET REQUTES

titre dillustration, nous utiliserons une extension de notre base favorite des
buveurs, compose de cinq relations :
BUVEURS (NB, NOM, PRNOM, TYPE)
VINS (NV, CRU, MILLESIME, DEGR)
ABUS (NB, NV, DATE, QUANTIT)
PRODUCTEURS (NP, NOM, REGION)
PRODUIT (NV, NP)

Les tables BUVEURS, VINS et PRODUCTEURS correspondent des entits alors que
ABUS et PRODUIT sont des tables reprsentant des associations. La table BUVEURS
dcrit des buveurs caractriss par un numro, un nom et un prnom. La table VINS
contient des vins caractriss par un numro, un cru, un millsime et un degr. Les abus
commis par les buveurs associant un numro de buveur, un numro de vin bu, une date et
une quantit bue, sont enregistrs dans la table ABUS. La table PRODUCTEURS dcrit des
producteurs caractriss par un numro, un nom et une rgion. Lassociation entre un vin
et le producteur qui la produit est mmorise dans la table PRODUIT. On considrera par
exemple la question Quels sont les crus des vins produits par un producteur bordelais en
1976 ayant un degr infrieur ou gal 14 ? . Celle-ci scrit comme suit en SQL :
(Q1) SELECT V.CRU
FROM PRODUCTEURS P, VINS V, PRODUIT R
WHERE V.MILLESIME = 1976 AND V.DEGRE 14
AND P.REGION = BORDELAIS AND P.NP = R.NP
AND R.NV = V.NV.

Pour diversifier un peu les exemples, nous considrerons aussi parfois la base de donnes drive du banc dessai (benchmark) TPC-D [TPC95]. Ce banc dessai est centr
sur laide la dcision et comporte donc beaucoup de questions avec des agrgats sur
une base plutt complexe. Cest dans de telles conditions que loptimisation de questions devient une fonction trs importante. Le schma simplifi de la base est le suivant :
COMMANDES(NUMCO, NUMCLI, ETAT, PRIX, DATE, PRIORIT, RESPONSABLE,
COMMENTAIRE)
LIGNES(NUMCO, NUMLIGNE, NUMPRO, FOURNISSEUR, QUANTIT, PRIX, REMISE,
TAXE, TAT, DATELIVRAISON, MODELIVRAISON, INSTRUCTIONS, COMMENTAIRE)
PRODUITS(NUMPRO, NOM, FABRIQUANT, MARQUE, TYPE, FORME, CONTAINER,
PRIX, COMMENTAIRE)
FOURNISSEURS(NUMFOU, NOM, ADRESSE, NUMPAYS, TELEPHONE, COMMENTAIRE)
PRODFOURN(NUMPRO, NUMFOU, DISPONIBLE, COUTLIVRAISON, COMMENTAIRE)

304 BASES DE DONNES : OBJET ET RELATIONNEL

CLIENTS(NUMCLI, NOM, ADRESSE, NUMPAYS, TELEPHONE, SEGMENT, COMMENTAIRE)

PAYS(NUMPAYS, NOM, NUMCONT, COMMENTAIRE)
CONTINENTS(NUMCONT, NOM, COMMENTAIRE)

Cette base dcrit des commandes composes dun numro absolu, dun numro de
client ayant pass la commande, dun tat, dun prix, dune date, dune priorit, dun
nom de responsable et dun commentaire textuel de taille variable. Chaque ligne de
commande est dcrite par un tuple dans la table LIGNES. Celle-ci contient le numro
de la commande rfrence, le numro de la ligne et le numro de produit qui rfrence un produit de la table PRODUITS. Les fournisseurs et les clients sont dcrits par
les attributs indiqus dont la signification est vidente, lexception de lattribut
SEGMENT qui prcise le type de client. La table associative PROFOURN relie chaque
fournisseur aux produits quil est capable de fournir ; elle contient pour chaque couple
possible la quantit disponible, le cot de la livraison par unit, et un commentaire
libre. Les tables PAYS et CONTINENTS sont lies entre elles par le numro de continent ; elles permettent de connatre les pays des fournisseurs et des clients, ainsi que
le continent dappartenance de chaque pays.
La question suivante est une requte dcisionnelle extraite de la vingtaine de requtes du
banc dessai. Elle calcule les recettes ralises par des ventes de fournisseurs des clients
appartenant au mme pays, cest--dire les recettes rsultant de ventes internes un pays,
et ceci pour tous les pays dEurope pendant une anne commenant la date D1.
(Q2) SELECT
FROM

P.NOM, SUM(L.PRIX * (1-L.REMISE* QUANTIT) AS RECETTE

CLIENTS C, COMMANDES O, LIGNES L, FOURNISSEURS F, PAYS P,
CONTINENTS T
WHERE
C.NUMCLI = O.NUMCLI
AND
O.NUMCOM = L.NUMCO
AND
L.NUMFOU = F.NUMFOU
AND
C.NUMPAYS = F.NUMPAYS
AND
F.NUMPAYS = P.NUMPAYS
AND
P.NUMCONT = T.NUMCONT
AND
T.NOM = EUROPE
AND
O.DATE $D1
AND
O.DATE < $D1 + INTERVAL 1 YEAR
GROUP BY P.NOM
ORDER BY P.NOM, RECETTE DESC ;

Il sagit l dune requte complexe contenant six jointures, trois restrictions dont deux
paramtres par une date ($D1), un agrgat et un tri ! De telles requtes sont courantes
dans les environnements dcisionnels.

2.2. REQUTES STATIQUES OU DYNAMIQUES

Certaines requtes sont figes lors de la phase de dveloppement et imbriques dans
des programmes dapplication, donc excutes aussi souvent que le programme qui

Optimisation de questions 305

les contient. Dautres au contraire sont construites dynamiquement, par exemple saisies une seule fois pour un test ou une recherche ad hoc. Pour loptimiseur, il est
important de distinguer ces diffrents types de requtes. Les premires rptitives sont
appeles requtes statiques, alors que les secondes sont qualifies de requtes dynamiques.
Notion X.1 : Requte statique (Static Query)
Requte SQL gnralement intgre un programme dapplication dont le code SQL est connu
lavance et fix, souvent excute plusieurs fois.

Ce premier type de requte gagne tre optimis au mieux. En effet, loptimisation

est effectue une seule fois, lors de la compilation du programme contenant la requte,
pour des milliers voire des millions dexcutions. La requte SQL peut tre paramtre, les valeurs constantes tant passes par des variables de programme. Loptimiseur doit donc tre capable doptimiser des requtes paramtres, par exemple contenant un prdicat CRU = $x, ou x est une variable de programme.
Notion X.2 : Requte dynamique (Dynamic Query)
Requte SQL gnralement compose en interactif dont le code nest pas connu lavance, souvent
excute une seule fois.

Ce deuxime type de requtes, aussi appel requtes ad hoc car correspondant des
requtes souvent saisies en ligne sans une longue rflexion pralable, est excut une
seule fois. On doit donc limiter le temps doptimisation afin de ne pas trop pnaliser
lunique excution de la requte.

2.3. ANALYSE DES REQUTES

Dans un premier temps, une question est analyse du point de vue syntaxique. Lexistence des noms de relations et dattributs cits est vrifie par rapport au schma. La
correction de la qualification de la question est analyse. Aussi, la requte est mise
dans une forme canonique. Par exemple, celle-ci peut tre mise en forme normale
conjonctive (ET de OU) ou disjonctive (OU de ET), selon quelle sera ultrieurement
traite par des oprateurs lmentaires supportant le OU (forme normale conjonctive),
ou simplement comme plusieurs questions (forme normale disjonctive). Souvent,
cette transformation est accomplie au niveau suivant. Finalement, ce premier traitement est analogue lanalyse syntaxique dexpressions dans un langage de programmation.
partir de la requte analyse, la plupart des systmes gnre un arbre doprations
de lalgbre relationnelle (projection, restriction, jointure, union, diffrence, intersec-

306 BASES DE DONNES : OBJET ET RELATIONNEL

tion), ventuellement tendu avec des agrgats et des tris, appel arbre algbrique,
ou arbre relationnel, ou parfois aussi arbre de traitement (processing tree).
Notion X.3 : Arbre algbrique (Algebraic tree)
Arbre reprsentant une question dont les nuds terminaux reprsentent les relations, les nuds
intermdiaires des oprations de lalgbre relationnelle, le nud racine le rsultat dune question,
et les arcs les flux de donnes entre les oprations.

Dans larbre algbrique, chaque nud est reprsent par un graphisme particulier,
dj dcrit lors de lintroduction des oprateurs algbriques. Nous rappelons les notations figure X.1, en introduisant une notation particulire pour les tris (simplement un
rectangle avec le nom des attributs de tri lintrieur) et les agrgats, qui peuvent tre
vus comme un tri suivi dun groupement avec calculs de fonctions pour chaque monotonie. Les agrgats sont ainsi reprsents par un rectangle contenant les attributs de la
clause GROUP BY, suivi dun rectangle contenant les attributs rsultats calculs.
RESTRICTION

PROJECTION

TRI

V.NV,
V.CRU

V.CRU, V.MILL

V. CRU

"BEAUJOLAIS"
V

JOINTURE

A. NV

=
A

DIFFRENCE

V. NV

AGRGAT
B2

B1

COUNT(*),AVG(DEGRE)
UNION

PRODUIT CARTSIEN

V.CRU, V.MILL
V

U
A

B1

B2

Figure X.1 : Reprsentation des oprateurs de lalgbre tendue

Plusieurs arbres reprsentent une mme question, selon lordre choisi pour les oprations. Une mthode de gnration simple dun arbre consiste prendre les prdicats
de qualification dans lordre o ils apparaissent et leur associer lopration relation-

Optimisation de questions 307

nelle correspondante, puis ajouter les agrgats, et enfin une projection finale pour
obtenir le rsultat avec un tri ventuel. Cette mthode permet par exemple de gnrer
larbre reprsent figure X.2 pour la question Q1, puis larbre de la figure X.3 pour la
question Q2.

RECETTE

P.NOM, RECETTE
P.NOM
V.CRU

C.NUMCLI
O.NUMCOM

V.MILLESIME

1976

V.DEGRE

14

O.NUMCLI and
L.NUMCO

L.NUMFOU

F.NUMFOU

L
P.REGION

P.NP

"Bordelais"

C.NUMPAYS

F.NUMPAYS

R.NP

F.NUMPAYS

P
R. NV

=
R

V. NV

P.NUMPAYS

P.NUMCONT

Figure X.2 : Un arbre algbrique pour

la question Q1 sur la base des vins

T.NUMCONT

P
$D1

O.DATE
<$D1+1
O

T.NOM

"EUROPE"

Figure X.3 : Un arbre algbrique pour la question Q2

sur la base TPC/D

partir dun arbre algbrique, il est possible de gnrer un plan dexcution en parcourant larbre, des feuilles vers la racine. Une opration peut tre excute par
ensembles de tuples ou tuple tuple, ds que ses oprandes sont disponibles. Lexcu-

308 BASES DE DONNES : OBJET ET RELATIONNEL

tion ensembliste consiste attendre la disponibilit des oprandes pour excuter une
opration.
Notion X.4 : Excution ensembliste (Set-oriented Execution)
Mode dexcution consistant calculer lensemble des tuples des relations en entre dun oprateur
avant dvaluer cet oprateur.

Dans ce mode, si lopration O1 nutilise pas les rsultats de lopration O2, les oprations O1 et O2 peuvent tre excutes en parallle. Ce mode dexcution peut tre
intressant pour des algorithmes capables de travailler efficacement sur des ensembles
(bass sur le tri par exemple).
Plus souvent, on cherche dmarrer une opration ds quun tuple est disponible dans
lune des tables arguments. Cest le mode tuple tuple ou pipeline.
Notion X.5 : Excution pipline (Pipline execution)
Mode dexcution consistant dmarrer une opration le plus tt possible, si possible ds quun
tuple est disponible pour au moins un oprande.

Pour les oprations unaires, il suffit quun tuple soit disponible. On peut ainsi excuter deux oprations successives de restriction en pipeline, cest--dire commencer la
deuxime ds quun tuple (ou un groupe de tuples, par exemple une page) a t gnre par la premire. Les oprations binaires comme la diffrence peuvent ncessiter
davoir calculer compltement lun des deux oprandes pour commencer. Le mode
pipeline est donc seulement possible sur un des deux oprandes. Ceci peut dpendre
de lalgorithme pour la jointure.

2.4. FONCTIONS DUN OPTIMISEUR

Un optimiseur a donc pour objectif dlaborer un plan dexcution optimis.
Notion X.6 : Plan dexcution (Execution plan)
Programme ventuellement parallle doprations lmentaires excuter pour valuer la rponse
une requte.

Ceci seffectue en gnral en deux phases, la rcriture et le planning, encore appel

ordonnancement [Haas89].
Notion X.7 : Rcriture (Rewriting)
Phase doptimisation consistant transformer logiquement la requte de sorte obtenir une reprsentation canonique.

Optimisation de questions 309

Cette phase comporte un aspect smantique pouvant aller jusqu prendre en compte
des rgles dintgrit, et un aspect syntaxique concernant le choix dune forme canonique. Celle-ci comprend la mise sous forme normale des critres et laffectation dun
ordre fix pour les oprateurs algbriques.
La phase suivante est donc le planning, qui peut remettre en question certains choix
effectus lors de la rcriture.
Notion X.8 : Planning (Planning)
Phase doptimisation consistant ordonner les oprateurs algbriques et choisir les algorithmes et
mode dexcution.

Alors que la premire phase gnre un arbre logique, la seconde ajoute les annotations
et obtient un plan dexcution. Elle sappuie de prfrence sur un modle de cot. Les
deux phases ne sont pas indpendantes, la premire pouvant influer sur la seconde et
biaiser le choix du meilleur plan. Cependant, on les distingue souvent pour simplifier.
On cherche bien sr optimiser les temps de rponse, cest--dire minimiser le
temps ncessaire lexcution dun arbre. Le problme est donc de gnrer un arbre
optimal et de choisir les meilleurs algorithmes pour excuter chaque oprateur et
larbre dans son ensemble. Pour cela, il faut optimiser simultanment :
le nombre dentres-sorties ;
le paralllisme entre les oprations ;
le temps de calcul ncessaire.
La fonction de cot doit si possible prendre en compte la taille des caches mmoires
disponibles pour lexcution. Loptimisation effectue dpend en particulier de lordre
des oprations apparaissant dans larbre algbrique utilis et des algorithmes retenus.
Il est donc essentiel dtablir des rgles permettant de gnrer, partir dun arbre initial, tous les plans possibles afin de pouvoir ensuite choisir celui conduisant au cot
minimal. En fait, le nombre darbres tant trs grand, on est amen dfinir des heuristiques pour dterminer un arbre proche de loptimum.
Nous allons maintenant tudier les principales mthodes proposes pour accomplir
tout dabord la rcriture, puis le planning. Leur objectif essentiel est videmment
doptimiser les temps de rponse aux requtes.

310 BASES DE DONNES : OBJET ET RELATIONNEL

3. LOPTIMISATION LOGIQUE
OU RCRITURE
La rcriture permet dobtenir une reprsentation canonique de la requte, sous la
forme dun arbre algbrique dans lequel les oprations sont ordonnes et les critres
mis sous forme normale. Elle peut comporter elle-mme deux tapes : la rcriture
smantique qui transforme la question en prenant en compte les connaissances
smantiques sur les donnes (par exemple, les contraintes dintgrit), et la rcriture
syntaxique qui profite des proprits simples de lalgbre relationnelle pour ordonner
les oprations.

3.1. ANALYSE ET RCRITURE SMANTIQUE

Ce type danalyse a plusieurs objectifs, tels que la dtermination de la correction de la
question, la recherche de questions quivalentes par manipulation de la qualification
ou laide des contraintes dintgrit. Ce dernier type doptimisation est dailleurs
rarement ralis dans les systmes. On peut aussi inclure dans la rcriture les modifications de questions ncessaires pour prendre en compte les vues, problme tudi
dans le chapitre traitant des vues.

3.1.1. Graphes support de lanalyse

Plusieurs types de graphes sont utiliss pour effectuer lanalyse smantique dune
question. Tout dabord, le graphe de connexion des relations a t introduit dans
INGRES [Wong76].
Notion X.9 : Graphe de connexion des relations (Relation connection graph)
Graphe dans lequel: (a) un sommet est associ chaque occurrence de relation, (b) une jointure est
reprsente par un arc entre les deux nuds reprsentant les relations jointes, (c) une restriction est
reprsente par une boucle sur la relation laquelle elle sapplique, (d) la projection finale est
reprsente par un arc dun nud relation vers un nud singulier rsultat.

Avec SQL, chaque instance de relation dans la clause FROM correspond un nud.
Les arcs sont valus par la condition quils reprsentent. Ainsi, le graphe de
connexion des relations de la question Q1 est reprsent figure X.4. Notez la difficult
reprsenter des questions avec des disjonctions (ou) de jointures qui peuvent tre
modlises par plusieurs graphes.
Plusieurs variantes dun tel graphe ont t proposes, en particulier le graphe des
jointures [Berstein79] o seules les jointures sont matrialises par un arc entre les
nuds relations. Le nud singulier figurant le rsultat, les arcs reprsentant les pro-

Optimisation de questions 311

jections finales, et les boucles symbolisant les restrictions sont omis. Ce graphe simplifi peut tre utilis pour diverses manipulations smantiques sur les jointures, mais
aussi pour ordonner les jointures ; il est alors coupl un modle de cot.
V.MILL. = 1976 and V.DEGRE 14
Rsul

V.CRU

P.REGION = "BORDELAIS"

V=
R.N
V
V.N

P
P.N

P
.N
=R

Figure X.4 : Graphe de connexion des relations de la question Q1

Le graphe de connexion des attributs peut tre dfini comme suit [Hevner79].
Notion X.10 : Graphe de connexion des attributs (Attribute connection graph)
Graphe dans lequel : (a) un sommet est associ chaque rfrence dattribut ou de constante, (b)
une jointure est reprsente par un arc entre les attributs participants, (c) une restriction est reprsente par un arc entre un attribut et une constante.

V.DEGRE

V.MIL.

V.NV

P.NP

P.REGION

14

1976

R.NV

R.NP

"BORDELAIS"

Figure X.5 : Graphe de connexion des attributs de la question Q1

La figure X.5 reprsente le graphe de connexion des attributs de la question Q1. Notez
que ce graphe perd la notion de tuple, chaque attribut tant reprsent individuellement.

312 BASES DE DONNES : OBJET ET RELATIONNEL

Il est possible dintroduire des hyper-nuds (cest--dire des groupes de nuds) pour
visualiser les attributs appartenant un mme tuple, comme reprsents figure X.5. Un
tel graphe permet de dcouvrir les critres contenant une contradiction : il possde alors
un cycle qui ne peut tre satisfait par des constantes. Il peut aussi permettre de dcouvrir
des questions quivalentes la question pose par transitivit (voir ci-dessous).

3.1.2. Correction de la question

La notion de question correcte est prciser. Deux catgories dincorrection sont
distinguer :
1. Une question peut tre mal formule car certaines parties apparaissent inutiles dans
la question ; cest sans doute que lutilisateur a oubli une jointure dans la question.
2. Une question peut prsenter une qualification contradictoire, qui ne peut tre satisfaite par aucun tuple ; ainsi par exemple la question crus des vins de degr suprieur 14 et infrieur 12 .
Deux rsultats importants ont t tablis afin dliminer les questions incorrectes,
dans le cas des questions conjonctives (sans ou) avec des oprateurs de comparaisons
=, <, >, , :
1. Une question est gnralement mal formule si son graphe de connexion des relations nest pas connexe [Wong76]. En effet, tout sous-graphe non reli au nud
rsultat ne participe pas ce rsultat. Il peut cependant sagir dun filtre qui rend la
rponse vide si aucun tuple de la base ne le satisfait.
2. Une question est contradictoire si son graphe de connexion des attributs complt
par des arcs de comparaison entre constantes prsente un cycle non satisfiable
[Rosenkrantz80]. En effet, dans ce cas aucun tuple ne peut satisfaire les prdicats
du cycle, par exemple du style AGE < 40 et AGE >50.

3.1.3. Questions quivalentes par transitivit

La notion de questions quivalentes mrite une dfinition plus prcise [Aho79].
Notion X.11 : Questions quivalentes (Equivalent queries)
Deux questions sont quivalentes si et seulement si elles donnent le mme rsultat pour toute extension possible de la base de donnes.

Ainsi, quels que soient les tuples dans la base (obissant videmment aux contraintes
dintgrit), deux questions quivalentes excutes au mme instant donneront le
mme rsultat.
Tout dabord, des questions quivalentes peuvent tre gnres par ltude des proprits de transitivit du graphe de connexion des attributs. Si lon considre ce der-

Optimisation de questions 313

nier, tout couple dattributs (x, y) relis par un chemin x > y dont les arcs sont tiquets par des galits doit vrifier x = y. Il est alors possible de gnrer la fermeture
transitive de ce graphe. Tous les sous-graphes ayant mme fermeture transitive gnrent des questions quivalentes, bien quexprimes diffremment. Ils correspondent en
effet des contraintes quivalentes sur le contenu de la base. Par exemple, considrons la question Q3 : Noms des buveurs ayant bu un Bordeaux de degr suprieur
ou gal 14 . Elle peut sexprimer comme suit :
(Q3) SELECT B.NOM
FROM BUVEURS B, ABUS A, PRODUIT R, PRODUCTEURS P, VINS V
WHERE B.NB = A.NB AND A.NV = R.NV AND R.NV = V.NV
AND R.NP = P.NP AND P.REGION = BORDELAIS
AND V.DEGRE 14 ;

o B, A, R, P, V dsignent respectivement les relations BUVEURS, ABUS, PRODUIT,

PRODUCTEURS et VINS. Le graphe de connexion des attributs rduit aux jointures
de Q3 est reprsent figure X.6. Sa fermeture transitive apparat en pointills. Un
graphe ayant mme fermeture transitive est reprsent figure X.7. Ainsi la question
Q3 peut tre pose par la formulation rsultant du graphe de la figure X.7 avec les
mmes variables, comme suit :
(Q3) SELECT B.NOM
FROM BUVEURS B, ABUS A, PRODUIT R, PRODUCTEURS P, VINS V
WHERE B.NB = A.NB AND A.NV = R.NV AND A.NV = V.NV
AND R.NP = P.NP AND P.REGION = BORDELAIS
AND V.DEGRE 14 ;

La diffrence rside dans le choix des jointures, le prdicat R.NV = V.NV tant
remplac par A.NV = V.NV. Dautres expressions sont possibles. Le problme
consiste bien sr choisir celle qui pourra tre value le plus rapidement. Le problme est plus difficile si lon considre des ingalits, mais il peut tre rsolu en
tendant le graphe de connexion des attributs [Rosenkrantz80].
=

B.NB

A.NV

A.NB

R.NV
=

V.NV

R.NP

P.NP

Figure X.6 : Graphe de connexion des attributs de jointure de la question Q3

314 BASES DE DONNES : OBJET ET RELATIONNEL

B.NB

A.NV

A.NB

R.NV
=

V.NV

R.NP

P.NP

Figure X.7 : Graphe ayant mme fermeture transitive

3.1.4. Questions quivalentes par intgrit

Une autre manire de gnrer des questions quivalentes consiste utiliser les
contraintes dintgrit [Chakravarthy90, King81, Finance94]. Le problme peut tre
pos comme suit. tant donne une question de qualification Q et un ensemble de
contraintes dintgrit I1, I2 In, si Q est contradictoire une contrainte, la
question a une rponse vide. Sinon, il suffit dvaluer la meilleure qualification
Q impliquant Q sous les contraintes I1, I2... In, cest--dire telle que I1 I2
In Q Q.
Le problme est un problme de dduction que nous illustrerons simplement par un
exemple. Soit la contrainte exprimant que tous les Bordeaux sont de degr suprieur
15 (o P dsigne un tuple de PRODUCTEURS, R un tuple de PRODUIT et V dsigne
un tuple de VINS) :
P.REGION = BORDELAIS AND P.NP = R.NP AND R.NV = V.NV
AND V.DEGRE > 15.

Alors, la qualification de la question Q1 est contradictoire avec cette contrainte et par

consquence sa rponse est vide. En revanche, cette contrainte permet de simplifier la
question Q3 car la condition V.DEGRE 14 est inutile et peut donc tre supprime.
Il nest pas sr que cette simplification rduise le temps dexcution.
Loptimisation smantique a t particulirement dveloppe dernirement dans le
contexte des bases de donnes objet, o elle peut conduire des optimisations importantes. Les contraintes dquivalence, dimplication, dunicit de cl et dinclusion
sont particulirement utiles pour transformer et simplifier les requtes.

Optimisation de questions 315

3.2. RCRITURES SYNTAXIQUES

ET RESTRUCTURATIONS ALGBRIQUES
Nous introduisons ici une technique de base pour transformer les arbres algbriques et
changer lordre des oprations. Cette technique rsulte des proprits de commutativit et dassociativit des oprateurs de lalgbre. Elle provient dune traduction dans
le contexte de lalgbre relationnelle des techniques de rcriture des expressions
arithmtiques. Aujourdhui, la plupart des optimiseurs mixent les restructurations
algbriques avec la phase de planning, base sur un modle de cot, que nous dcrivons plus loin. Cependant, pour la commodit de la prsentation, nous introduisons
ci-dessous les rgles de transformation des arbres, puis un algorithme simple de
restructuration algbrique, et aussi des heuristiques plus complexes de dcomposition
appliques parfois par certains optimiseurs [Stonebraker76, Gardarin84].

3.2.1. Rgles de transformation des arbres

Les rgles suivantes ont pour la premire fois t prcises dans [Smith75]. Elles sont
bien dveloppes dans [Ullman88]. Elles dpendent videmment des oprations relationnelles prises en compte. Nous considrons ici lensemble des oprations de restriction, jointure, union, intersection et diffrence. Nous reprsentons figure X.8 neuf
rgles sous forme de figures donnant deux patrons darbres quivalents. Ces rgles
sont trs classiques. Ce sont les suivantes :
1. commutativit des jointures ;
2. associativit des jointures ;
3. fusion des projections ;
4. regroupement des restrictions ;
5. quasi-commutativit des restrictions et des projections ;
6. quasi-commutativit des restrictions et des jointures ;
7. commutativit des restrictions avec les unions, intersections ou diffrences ;
8. quasi-commutativit des projections et des jointures ;
9. commutativit des projections avec les unions.
Notez que dans toutes les rgles o figurent des jointures, celles-ci peuvent tre remplaces par des produits cartsiens qui obissent aux mmes rgles. En effet, le produit cartsien nest jamais quune jointure sans critre. La quasi-commutativit signifie quil y a en gnral commutativit, mais que quelques prcautions sont ncessaires
pour viter par exemple la perte dattributs, ou quune opration commute ne soit
effectue que sur lune des relations.

316 BASES DE DONNES : OBJET ET RELATIONNEL

1. Commutativit des jointures

2. Associativit des jointures

3. Fusion des projections

A1,Ap
A1,Ap
Ai,...Aj,
A1, Ap

Figure X.8 (dbut) : Rgles de restructurations algbriques

Optimisation de questions 317

4. Regroupement des restrictions

Ai = a
Ai = a
et
Aj = b

Aj = b

5. Quasi-commutativit des restrictions et projections (lattribut de restriction doit tre

conserv par la projection)

A1,Ap

A1,Ap
Ai = a

Ai = a
Ai,
A1,Ap

Figure X.8 (suite) : Rgles de restructurations algbriques

318 BASES DE DONNES : OBJET ET RELATIONNEL

6. Quasi-commutativit des restrictions et des jointures (la restriction est applique sur
la relation contenant lattribut restreint)

Ai = a

S(...Bj...)

Ai = a

R(...Ai...)

S(...Bj...)

R(...Ai...)

7. Commutativit des restrictions avec les unions, intersections ou diffrences

Ai = a

Ai = a

Ai = a

Figure X.8 (suite) : Rgles de restructurations algbriques

Optimisation de questions 319

8. Quasi-commutativit des projections et jointures (la projection ne doit pas perdre

les attributs de jointure)

A1,Ap
B1,Bq
A1,Ap
B1,Bq
Ai
Ai

Bj

Bj

R(...Ai...)

A1,Ap
Ai

S(...Bj...)

B1,Bp
Bj

R(...Ai...)

S(...Bj...)

9. Commutativit des projections avec les unions

A1,Ap

A1,Ap

A1,Ap

Figure X.8 (fin) : Rgles de restructurations algbriques

3.2.2. Ordonnancement par descente des oprations unaires

Une premire optimisation simple consiste excuter tout dabord les oprations
unaires (restriction, projection), puis les oprations binaires (jointure, produit cartsien, union, intersection, diffrence). En effet, les oprations unaires sont des rducteurs de la taille des relations, alors quil nen est pas ainsi de certaines oprations

320 BASES DE DONNES : OBJET ET RELATIONNEL

binaires qui ont tendance accrotre la taille des rsultats par rapport aux relations
arguments. Par exemple, une jointure peut gnrer une trs grande relation. Ceci se
produit lorsque de nombreux tuples de la premire relation se compose de nombreux
de la seconde. la limite, elle peut se comporter comme un produit cartsien si tous
les couples de tuples des deux relations vrifient le critre de jointure.
Aussi, afin de ne considrer que les arbres flux de donnes minimal et de rduire
ainsi le nombre dentres-sorties effectuer, on est conduit descendre les restrictions
et projections. De plus, quand deux projections successives portent sur une mme
relation, il est ncessaire de les regrouper afin dviter un double accs la relation.
De mme pour les restrictions. Ces principes prcdents conduisent lalgorithme
doptimisaton suivant :
1. Sparer les restrictions comportant plusieurs prdicats laide de la rgle 4 applique de la droite vers la gauche.
2. Descendre les restrictions aussi bas que possible laide des rgles 5, 6, et 7.
3. Regrouper les restrictions successives portant sur une mme relation laide de la
rgle 4 applique cette fois de la gauche vers la droite.
4. Descendre les projections aussi bas que possible laide des rgles 8 et 9.
5. Regrouper les projections successives partir de la rgle 3 et liminer dventuelles
projections inutiles qui auraient pu apparatre (projection sur tous les attributs dune
relation).
Pour simplifier les arbres et se rapprocher des oprateurs physiques rellement implments dans les systmes, une restriction suivie par une projection est note par un
unique oprateur de slection (restriction + projection) ; celui-ci permet dviter
deux passes sur une mme relation pour faire dabord la restriction puis la projection.
Il en est de mme pour une jointure suivie par une projection : on parle alors doprateur de jointure-projection.
titre dillustration, lalgorithme de descente des restrictions et des projections a t
appliqu larbre de la figure X.2. On aboutit larbre reprsent figure X.9. Cet
arbre nest pas forcment optimal pour au moins deux raisons : la descente des restrictions et des projections nest quune heuristique et lordre des oprations binaires na
pas t optimis.

3.3. ORDONNANCEMENT PAR DCOMPOSITION

La dcomposition est une stratgie dordonnancement qui fut applique dans le systme INGRES [Wong76]. Elle est base sur deux techniques de transformation de
questions appeles dtachement et substitution. Appliqu rcursivement, le dtachement permet dordonner les oprations selon lordre slection, semi-jointure, et enfin
jointure. La substitution consiste simplement valuer une question portant sur une

Optimisation de questions 321

V.CRU
V.CRU
P.NP

V.MILLESIME

1976

V.DEGRE

14

P.REGION

"Bordelais"

P.NP

R.NP

R.NP,
V.CRU

P.NP

P.REGION

=
P

R.NP

"Bordelais"
R. NV

V. NV

R
V.CRU,
V. NV

P
R. NV

=
R

V. NV

V.MILLESIME
V.DEGRE

1976 and
14
V

Figure X.9 : Optimisation dun arbre par descente des restrictions et des projections

relation en lappliquant sur chacun des tuples de la relation. Cette technique revient
donc au balayage et nous ninsisterons pas dessus. Le dtachement permet par contre
un premier ordonnancement des jointures.

3.3.1. Le dtachement de sous-questions

Le dtachement permet de dcomposer une question Q en deux questions successives
Q1 et Q2, ayant en commun une variable unique rsultat de Q1. Cest une transformation de question consistant diviser une question en deux sous-questions successives
ayant une seule table commune. De manire plus formelle, la situation gnrale o le
dtachement est possible est la suivante. Soit une question QT de la forme :
(QT) SELECT T(X1, X2 , Xm)
FROM R1 X1, R2 X2..., Rn Xn
WHERE B2(X1, X2 , Xm)
AND B1(Xm, Xm+1 , Xn).

322 BASES DE DONNES : OBJET ET RELATIONNEL

B1 et B2 sont des qualifications incluant respectivement les variables X1,X2 Xm et

Xm, Xm+1 Xn, alors que T est un rsultat de projection partir des variables
X1, X2 Xm.
Une telle question peut tre dcompose en deux questions, q1 suivie de q2, par
dtachement :
(q1) SELECT K(Xm) INTO Rm
FROM RM Xm, Rm+1Xm+1... Rn Xn
WHERE B1(Xm, Xm+1, Xn)

K(Xm) contient les informations de Xm ncessaires la deuxime sous-question :

(q2) SELECT T(X1, X2, Xm)
FROM R1 X1, R2 X2... Rm Xm
WHERE B2(X1, X2, Xm).

Le dtachement consiste en fait transformer une question en deux questions imbriques q1 et q2 qui peuvent tre crites directement en SQL comme suit :
SELECT T(X1, X2, Xm)
FROM R1 X1, R2 X2... Rm Xm
WHERE B2(X1, X2, Xm) AND K(Xm) IN
SELECT K(Xm)
FROM RM Xm, Rm+1 Xm+1... Rn Xn
WHERE B1(X m, Xm+1, Xn).

Les questions nayant pas de variables communes, il est possible dexcuter la question interne q1, puis la question externe q2.
Une question dans laquelle aucun dtachement nest possible est dite irrductible. On
peut montrer quune question est irrductible lorsque le graphe de connexion des relations ne peut tre divis en deux classes connexes par limination dun arc [Wong76].

3.3.2. Diffrents cas de dtachement

Comme indiqu plus haut, certaines techniques doptimisation de questions cherchent
excuter tout dabord les oprations qui rduisent la taille des relations figurant dans
la question. Une telle opration correspond souvent une slection (restriction suivie
de projection), mais parfois aussi une semi-jointure [Bernstein81].
Notion X.12 : Semi-jointure (Semi-join)
La semi-jointure de la relation R par la relation S, note R
des attributs de R.

S, est la jointure de R et S projete sur

Autrement dit, la semi-jointure de R par S est compose de tuples (ou partie de tuples)
de R qui joignent avec S. On peut aussi voir la semi-jointure comme une gnralisation de la restriction : cette opration restreint les tuples de R par les valeurs qui appa-

Optimisation de questions 323

raissent dans le (ou les) attribut(s) de jointure de S (par la projection de S sur ce (ou
ces) attributs(s)). La semi-jointure R
S est donc une opration qui rduit la taille
de R, tout comme une restriction.
Le dtachement permet de faire apparatre dune part les restrictions, dautre part les
semi-jointures. Ce sont les deux seuls cas de dtachement possibles. Nous allons illustrer ces dtachements sur la question Q1 dj vue ci-dessus :
SELECT DISTINCT V.CRU
FROM PRODUCTEURS P, VINS V, PRODUIT R
WHERE V.MILLESIME = 1976 AND V.DEGRE 14
AND P.REGION = BORDELAIS AND P.NP = R.NP
AND R.NV = V.NV.

Le graphe de connexion des relations de cette question est reprsent figure X.4.
Tout dabord, les deux slections :
(q11) SELECT V.NV INTO V1
FROMS VINS V
WHERE V.DEGRE 14 AND V.MILLESIME = 1976

et
(q12) SELECT P.NP INTO P1
FROMS PRODUCTEURS P
WHERE P.REGION = BORDELAIS

peuvent tre dtaches.

En faisant maintenant varier V sur la relation V1 rsultat de Q11 et P sur la relation
P1 rsultat de Q12, il reste excuter la question :
(q1) SELECT DISTINCT V.CRU
FROM P1 P, V1 V, PRODUIT R
WHERE P.NP = R.NP
AND R.NV = V.NV.

Larc du graphe des relations correspondant la jointure P.NP = R.NP peut ensuite
tre enlev, ce qui correspond au dtachement de la sous-question :
(q13) SELECT R.NV INTO R1
FROM P1 P, PRODUIT R
WHERE P.NP = R.NP.

q13 est bien une semi-jointure. Finalement, en faisant varier R sur la relation R1
rsultat de q13, il ne reste plus qu excuter une dernire semi-jointure :
(Q14) SELECT DISTINCT V.CRU
FROM V1 V, R1 R
WHERE V.NV = R.NV

324 BASES DE DONNES : OBJET ET RELATIONNEL

Q1 a t dcompose en une suite de slection et semi-jointures ((q11 | q12) ;

q13 ; q14). q11 et q12 peuvent tre excutes en parallle, puis q13 peut ltre, et
enfin q14.
Toutes les questions ne sont pas ainsi dcomposables en slections suivies par des
semi-jointures. Il est toujours possible de dtacher les slections. Par contre
[Bernstein81] a montr que seules les questions dont les graphes de connexion aprs
limination des boucles (dtachement des slections) sont des arbres peuvent tre
dcomposes en squences de semi-jointures (dailleurs pas uniques). Les questions
irrductibles prsentent donc des cycles dans le graphe de connexion des relations.
Cependant, certaines questions peuvent paratre irrductibles alors quil existe des
questions quivalentes dcomposables par dtachement [Bernstein81].
Il existe donc des questions qui ne peuvent tre ramenes des questions monovariables par dtachement : celles qui prsentent des cycles dans le graphe de
connexion des attributs. En fait, ces questions retrouvent des rsultats partir de plusieurs relations et comportent donc de vraies jointures, non transformables en semijointures. Par exemple, la question Q4 qui recherche les couples (noms de buveurs,
noms de producteurs) tels que le buveur ait bu un vin du producteur :
(Q4) SELECT B.NOM, P.NOM
FROM BUVEURS B, ABUS A, PRODUIT R, PRODUCTEUR P
WHERE B.NB = A.NB AND A.NV = R.NV AND R.NP = P.NP

est une question irrductible. Son graphe de connexion des relations prsente en effet
un cycle, comme le montre la figure X.10.

B.NOM

B.NB = A.NB

A.NV=R.NV

Rsultat

P.NOM

R.NP=P.NP

Figure X.10 : Graphe de connexion de relations avec cycle

Afin de rsoudre les questions irrductibles, le systme INGRES de lUniversit de

Berkeley appliquait une mthode trs simple : une des relations tait balaye squentiellement, par substitution des tuples successifs la variable. Pour chaque tuple ainsi
obtenu, la sous-question gnre par substitution de la variable par le tuple lu tait traite par dtachement. En cas de gnration dune nouvelle sous-question irrductible, la
substitution tait nouveau applique. Lalgorithme tait donc rcursif [Wong76]. Des
mthodes de jointures beaucoup plus sophistiques sont aujourdhui disponibles.

Optimisation de questions 325

3.4. BILAN DES MTHODES DOPTIMISATION LOGIQUE

Les mthodes de rcriture travaillant au niveau des oprateurs logiques sont suffisantes pour traiter les problmes de correction de requtes. Du point de vue optimisation, elles permettent dordonner les oprateurs laide dheuristiques simples. Les
unions peuvent tre accomplies avant les jointures. Lintersection et la diffrence ne
sont que des cas particuliers de jointures.
La dcomposition est une heuristique dordonnancement sophistique qui consiste
excuter tout dabord les slections, puis ordonner les jointures de sorte faire apparatre en premier les semi-jointures possibles. Puisque les semi-jointures rduisent les
tailles des relations, on peut ainsi esprer rduire les tailles des rsultats intermdiaires et donc le nombre dentres-sorties. Cette heuristique apparat ainsi comme
suprieure lordonnancement par restructuration algbrique qui nordonne pas du
tout les jointures.
Le vrai problme est celui dordonner les jointures, et plus gnralement les oprations binaires. La rcriture est une premire approche qui permet un certain ordonnancement et ne ncessite aucune estimation de la taille des rsultats des jointures.
Cette approche est tout fait insuffisante pour obtenir un plan dexcution de cot
minimal, car elle ne permet ni dordonner les oprations de manire optimale, ni de
choisir les algorithmes optimaux pour chaque opration.

4. LES OPRATEURS PHYSIQUES

Avant daborder loptimisation physique, il est ncessaire de comprendre les algorithmes excutant laccs aux tables. Ceux-ci ralisent les oprateurs relationnels et
sont au centre du moteur du SGBD responsable de lexcution des plans. En consquence, leur optimisation est importante. Dans la suite, nous nous concentrons sur la
slection, le tri, la jointure et les calculs dagrgats. Les autres oprations ensemblistes peuvent tre effectues de manire analogue la jointure.

4.1. OPRATEUR DE SLECTION

Le placement des donnes dans les fichiers est effectu dans le but doptimiser les
slections les plus frquentes, et aussi les jointures. La prsence dindex sur les attributs rfrencs dans le prdicat argument de la slection change radicalement lalgorithme de slection. Cependant, il existe des cas dans lesquels lutilisation dindex est
pnalisante, par exemple si la slectivit du prdicat est mauvaise (plus de 20 % des

326 BASES DE DONNES : OBJET ET RELATIONNEL

tuples satisfont le critre). De plus, aucun index nest peut tre spcifi. En rsum, on
doit donc considrer deux algorithmes diffrents : la slection par balayage squentiel
et par utilisation dindex.

4.1.1. Slection sans index

Le balayage squentiel (sequential scan) ncessite de comparer chaque tuple de la
relation oprande avec le critre. Si celui-ci est vrai, les attributs utiles sont conservs
en rsultat. La procdure effectue donc la fois restriction et projection.
Le critre peut tre compil sous la forme dun automate afin dacclrer le temps de
parcours du tuple. Lautomate peut tre vu comme une table ayant en colonnes les codes
caractres et en lignes les tats successifs. Il permet pour chaque caractre lu dappliquer une action et de dterminer ltat suivant de lautomate. Ltat suivant est soit
continuation, soit chec, soit succs. En cas de continuation, le caractre suivant est
trait. Sinon, le tuple est retenu en cas de succs, ou ignor en cas dchec. La
figure X.11 illustre lautomate qui peut tre utilis pour traiter le critre COULEUR = ROUGE OU COULEUR = ROSE. Des filtres matriels ont t raliss
selon ce principe afin deffectuer la slection en parallle lentre-sortie disque. Les
SGBD effectuent plutt le filtrage en mmoire aprs avoir lu une page du fichier en
zone cache.
Echec

Init

U
S

Echec
E
E
Succs

Figure X.11 : Exemple dautomate

signifie tout autre caractre que ceux cits)

Un paramtre important pour la slection sans index est le fait que le fichier soit tri
ou non sur lattribut de restriction. Dans le cas o le fichier nest pas tri, le balayage
squentiel (BS) complet du fichier est ncessaire. Le nombre dentres-sorties ncessaire est alors le nombre de pages du fichier : Cot(BS) = Page(R).

Optimisation de questions 327

Dans le cas o le fichier est tri sur lattribut test, une recherche dichotomique (RD)
est possible : le bloc mdian du fichier sera dabord lu, puis selon que la valeur cherche de lattribut est infrieure ou suprieure celle figurant dans le premier tuple du
bloc, on procdera rcursivement par dichotomie avec la premire ou la seconde partie du fichier. Quoi quil en soit, la recherche sans index est longue et conduit lire
toutes les pages du fichier si celui-ci nest pas tri, ou Log2(Page(R)) pages si le
fichier est tri sur lattribut de slection : Cot(RD) = Log2(Page(R)).

4.1.2. Slection avec index de type arbre-B

Un index associe les valeurs dun attribut avec la liste des adresses de tuples ayant
cette valeur. Il est gnralement organis comme un arbre-B et peut tre plaant, cest-dire que les tuples sont placs dans les pages selon lordre croissant des valeurs de
cl dans lindex. Il sagit alors dun arbre-B+ ; celui-ci peut tre parcouru squentiellement par ordre croissant des cls. Dans les bases de donnes relationnelles, lindex
primaire est souvent plaant, alors que les index secondaires ne le sont pas.
Voici maintenant le principe dvaluation dun critre dont certains attributs sont
indexs. On choisit les index intressants (par exemple, ceux correspondant une
slectivit du sous-critre suprieure 60%). Pour chacun, on construit une liste
dadresses de tuples en mmoire. Puis on procde aux intersections (critre ET) et aux
unions (critre OU) des listes dadresses. On obtient ainsi la liste des adresses de
tuples qui satisfont aux sous-critres indexs. On peut ensuite accder ces tuples et
vrifier pour chacun le reste du critre par un test en mmoire.
Certains systmes retiennent seulement le meilleur index et vrifie tout le reste du critre en lisant les tuples slectionns par le premier index. Si un index est plaant, on a
souvent intrt lutiliser comme critre daccs. Un cas dgnr est le cas de placement par hachage. Alors, seul le sous-critre rfrenant lattribut de hachage est en
gnral retenu et le reste est vrifi en mmoire.
La figure X.12 illustre une table VINS place en squentielle et possdant deux index
sur CRU et DEGRE. Pour simplifier, le numro de vin a t port la place des
adresses relatives dans les entres des index secondaires. Aucun index nest plaant.
Le traitement du critre (CRU = CHENAS) AND (MILLESIME 1986)
AND (DEGRE = 12) conduit considrer les deux index. On retient les index sur
CRU et DEGRE, et lon effectue la vrification du millsime par accs au fichier.
Do le plan daccs indiqu figure X.12.
En gnral, le choix des meilleurs chemins daccs (index ou fonction de hachage)
nest pas vident. Par exemple, on pourrait croire que les index sont inutiles dans les
cas de comparateurs infrieur (<) ou suprieur (>). Il nen est rien au moins pour les
index plaants : laccs lindex permet de trouver un point dentre dans le fichier
que lon peut ensuite balayer en avant ou en arrire en profitant du fait quil est tri.

328 BASES DE DONNES : OBJET ET RELATIONNEL

Les index non plaants peuvent parfois tre utiles avec des comparateurs suprieurs
ou infrieurs, mais ceci est plus rare car ils provoquent des accs dsordonns au
fichier. Tout cela montre lintrt dun modle de cot qui permet seul de faire un
choix motiv, comme nous le verrons ci-dessous.
FICHIERS DE VINS
(NV,CRU,QUALITE,DEGRE,MILLESIME)

INDEX SECONDAIRE SUR CRU :

Beaujolais

1,5,18

1,Beaujolais, Excellente, 11,1987

Chenas

2,7,14

2, Chenas,Mediocre,12,1990

Julienas

3,6,15,25

3, Julienas, Mediocre,12,1990
5, Beaujolais, Bonne,10,1985
6, Julienas, Mediocre,12,1987
7, Chenas, Excellente,11,1989

INDEX SECONDAIRE SUR DEGRE :

14, Chenas, Bonne,10,1994

10

5,14,18

15, Julienas, Excellente,11,1995

11

1,7,15

18, Beaujolais, Bonne,10,1988

12

2,3,6,25

25, Julienas, Mediocre,12,1990

PLAN DACCS
(table VINS critre (CRU = CHENAS) AND (MILLESIME 1986)
AND (DEGRE = 12))
{ C = LIRE (index CRU entre CHENAS)
D = LIRE (index DEGRE entre 12)
L = UNION (C, D)
Pour chaque l de L faire
{ Tuple = LIRE (table VINS adresse l)
if Tuple.MILLESIME 1986 alors
rsultat = UNION (rsultat, Tuple)}
}
}

Figure X.12 : Exemple de slection via index

4.2. OPRATEUR DE TRI

Le tri est un oprateur important car il est utilis pour les requtes demandant une prsentation de rsultats tris, mais aussi pour liminer les doubles, effectuer certaines
jointures et calculer des agrgats.

Optimisation de questions 329

Le tri de donnes qui ne tiennent pas en mmoire est appel tri externe. Des algorithmes de tri externes ont t proposs bien avant lavnement des bases de donnes
relationnelles [Knuth73]. On distingue les algorithmes par tri-fusion (sort merge) et
les algorithmes distributifs. Les algorithmes par tri-fusion crent des monotonies en
mmoire. Par exemple, si (B+1) pages sont disponibles, des monotonies de B pages
sont cres, sauf la dernire qui comporte en gnral moins de pages. Le nombre de
monotonies cres correspond au nombre de pages de la relation R crer divis par
B en nombre entier, plus la dernire :
Nmon = 1+ ENT(Page(R)/B).
Pour constituer une monotonie, au fur et mesure des lectures denregistrements, un
index tri est cr en mmoire. Lorsque les B pages ont t lues, les enregistrements
sont crits par ordre croissant des cls dans un fichier qui constitue une monotonie. La
constitution de toutes les monotonies ncessite de lire et dcrire la relation, donc
2*Page(R) entres-sorties.
Dans une deuxime phase, les monotonies sont fusionnes. Comme seulement B
pages en mmoire sont disponibles pour lire les monotonies, il faut ventuellement
plusieurs passes pour crer une monotonie unique. Le nombre de passes ncessaires
est LOGB(Nmon). Chaque passe lit et crit toutes les pages de la relation. Do le
nombre total dentres-sorties pour un tri-fusion :
Cot(TF) = 2*Page(R)*(1+LOGB(1+ ENT(Page(R)/B))).
Lorsque Page(R) est grand, un calcul approch donne :
Cot(TF) = 2*Page(R)*(1+LOGB(Page(R)/B))),
On obtient :
Cot(TF) = 2*Page(R)*LOGB(Page(R)).

4.3. OPRATEUR DE JOINTURE

Comme avec les slections, il est possible de distinguer deux types dalgorithmes
selon la prsence dindex sur les attributs de jointure ou non. Dans la suite, nous dveloppons les principes des algorithmes de jointure sans index puis avec index. Nous
considrons lqui-jointure de deux relations R1 et R2 avec un critre du type
R1.A = R2.B, o A et B sont respectivement des attributs de R1 et R2. Dans le cas
dinqui-jointure (par exemple, R1.A > R2.B), les algorithmes doivent tre adapts,
lexception des boucles imbriques qui fonctionne avec tout comparateur. Nous supposons de plus que R1 a un nombre de tuples infrieur celui de R2.

330 BASES DE DONNES : OBJET ET RELATIONNEL

4.3.1. Jointure sans index

En labsence dindex, il existe trois algorithmes fondamentaux : les boucles imbriques, le tri-fusion, et le hachage [Blasgen76, Valduriez84, DeWitt84]. Les algorithmes hybrides sont souvent les plus efficaces [Fushimi86, DeWitt92].

4.3.1.1. Boucles imbriques

Lalgorithme des boucles imbriques est le plus simple. Il consiste lire squentiellement la premire relation R1 et comparer chaque tuple lu avec chaque tuple de la
deuxime R2. R1 est appele relation externe et R relation interne. Pour chaque tuple
de R1, on est donc amen lire chaque tuple de R2. Lalgorithme est schmatis
figure X.13. Loprateur + permet de concatner les deux tuples oprandes. Le test
dgalit des attributs Tuple1.A et Tuple2.B doit tre remplac par la comparaison des
attributs en cas dinqui-jointure.
Les entres-sorties seffectuant par page, en notant Page(R) le nombre de pages dune
relation R, on obtient un cot en entres-sorties de :
Cot(BI) = Page(R1) + Page(R1) * Page(R2).
Si la mmoire cache permet de mmoriser (B+1) pages, il est possible de garder B
pages de R1 en mmoire et de lire R2 seulement Page(R1)/B fois.
La formule devient alors :
Cot(BI) = Page(R1) + Page(R1)* Page(R2)/B.
Ceci souligne lintrt dune grande mmoire cache qui permet de rduire le nombre
de passes.
Boucles_Imbriques (R1,A, R2,B){
Pour chaque page B1 de R1 faire{
Lire (R1,B1) ;
Pour chaque page B2 de R2 faire{
Lire (R2,B2) ;
Pour chaque tuple Tuple1 de B1 faire
Pour chaque tuple Tuple2 de B2 faire{
si Tuple1.A = Tuple2.B alors
ECRIRE(Rsultat, Tuple1 + Tuple2) ;
}
}
}
}

Figure X.13 : Algorithme des boucles imbriques

Optimisation de questions 331

4.3.1.2. Tri-fusion
Lalgorithme par tri-fusion effectue le tri des deux relations sur lattribut respectif de
jointure. Ensuite, la fusion des tuples ayant mme valeur est effectue. Lalgorithme
est schmatis figure X.14. En supposant des tris de N pages en 2N LOG N comme
ci-dessus, le cot en entres-sorties de lalgorithme est :
Cot(JT) = 2*Page(R1)*LOG(Page(R1)) + 2*Page(R2)*LOG(Page(R2))
+ Page(R1) + Page(R2).
Les logarithmes (LOG) sont base 2 pour des tris binaires, et base B pour des tris
avec (B+1) pages en mmoire cache. Lalgorithme est en gnral beaucoup plus efficace que le prcdent. Son efficacit dpend cependant de la taille mmoire disponible. Soulignons aussi que si lune des relations est dj trie sur lalgorithme de
jointure, il nest pas ncessaire de refaire le tri.
Tri_Fusion (R1,A, R2,B){
R1T = TRIER (R1,A) ;
R2T = TRIER (R2,B) ;
Rsultat = FUSIONNER (R1T,R2T) }

Figure X.14 : Algorithme de tri-fusion

4.3.1.3. Partition
Il sagit dune mthode par hachage qui peut aisment tre combine avec lune des
prcdentes. Lalgorithme par partition consiste dcouper les deux relations en partitions en appliquant une mme fonction de hachage h sur les attributs de jointure A et
B. Dans la mesure du possible, les partitions gnres sont gardes en mmoire. On
est alors ramen joindre les paquets de mme rang par lun des algorithmes prcdents. En effet, pour pouvoir tre joints, deux tuples doivent donner la mme valeur
par la fonction de hachage applique aux attributs de jointure, car ceux-ci doivent tre
gaux.
Lalgorithme peut tre amlior par la gestion dun tableau de bits de dimension N en
mmoire [Babb79] (N aussi grand que possible). Lastuce consiste hacher la premire relation simultanment avec la fonction h pour crer les partitions et une autre
fonction g distribuant uniformment les valeurs de A sur [1,N]. La fonction g permet
de maintenir un tableau de bits servant de filtre pour la deuxime relation. chaque
tuple hach de R1, le bit g(B) est mis 1 dans le tableau de bits. Lorsquon partitionne la deuxime relation, on effectue pour chaque tuple de R2 un test sur le bit
g(B) du tableau. Sil est 0, on peut liminer ce tuple qui na aucune chance de jointure (aucun tuple de R1 ne donne la mme valeur par g). Le principe de lalgorithme
par hachage est reprsent figure X.15 : seuls les paquets de mme rang, donc de la
diagonale sont joints.

332 BASES DE DONNES : OBJET ET RELATIONNEL

R2 g(B)
Partition de R2 par h(B)

Tableau de bits
0
1
0
0
1

R1 g(A)

Partition de R1
par h(A)

1
0
.
.
.

Jointure R1.A = R2.B

Figure X.15 : Illustration de lalgorithme par partition

4.3.1.4. Hachage
Lalgorithme par hachage le plus simple consiste hacher seulement la premire relation dans un fichier hach si possible gard en mmoire. Ensuite, on balaye la
deuxime relation, et pour chaque tuple lu on tente daccder au fichier hach en testant lexistence denregistrement de cl identique dans le fichier hach (fonction
PROBE). Tant que lon trouve des enregistrements de cl similaire, on compose la
jointure rsultat. Cet algorithme est schmatis figure X.16.
Hachage (R1,A, R2,B) {
Pour chaque page B1 de R1 faire {// hacher R1 sur A
Lire (R1,B1) ;
Pour chaque tuple Tuple1 de B1 faire{
p = h(Tuple1,A) ;
ECRIRE (Fichier_Hach, Paquet p, Tuple1) ;}}
Pour chaque page B2 de R2 faire {// Parcourir R2
Lire (R2,B2) ;
Pour chaque tuple Tuple2 de B2 faire {
Tant que PROBE(Fichier_Hach,Tuple2) faire {
// Joindre si succs
ACCEDER (Fichier_Hach, Tuple1) ;
si Tuple1.A = Tuple2.B alors
ECRIRE(Rsultat,Tuple1 + Tuple2) ;
}
}
}
}

Figure X.16 : Algorithme par hachage

Optimisation de questions 333

Le cot de lalgorithme par hachage dpend beaucoup de la taille mmoire disponible.

Au mieux, il suffit de lire les deux relations. Au pire, on est oblig de faire plusieurs
passes pour hacher la premire relation, le nombre de passes tant le nombre de
paquets de la table hache divis par le nombre de paquets disponibles en mmoire.
On peut estimer ce nombre par Page(R1)/B, B+1 tant toujours le nombre de pages
disponibles en mmoire. On obtient donc Page(R1)*Page(R1)/B entres-sorties pour
hacher R1. Il faut ensuite lire R2. Pour chaque tuple de R2, on va accder au fichier
hach. Notons Tuple(R) le nombre de tuples dune relation R. Pour laccs au fichier
hach, on obtient un cot maximal de Tuple(R2) entres-sorties, en ngligeant leffet
de la mmoire cache. Lutilisation additionnelle dun tableau de bits permet de diminuer Tuple(R2) dun facteur difficile valuer, not f avec f < 1, qui dpend de la
slectivit de la jointure. Ce facteur peut aussi intgrer leffet de la mmoire cache.
On obtient donc au total :
Cot(JH) = Page(R1)*Page(R1)/B + Page(R2) + f*Tuple(R2)
Ceci est difficilement comparable avec les formules prcdentes, mais trs bon si B
est grand et la slectivit de la jointure faible (f petit).

4.3.1.5. Table de hachage

Une variante souvent utilise de lalgorithme prcdent consiste construire
en mmoire une table de hachage pour la plus petite relation. Cette table remplace
le fichier hach et conserve seulement ladresse des enregistrements, et pour chacun
deux la valeur de lattribut de jointure. La deuxime phase consiste lire chaque
tuple de la deuxime relation et tester sil existe des tuples ayant mme valeur
pour lattribut de jointure dans la table de hachage. Lalgorithme comporte donc une
phase de construction (Build) de la table de hachage et une phase de tests (Probe)
pour les tuples de la deuxime relation. La table de hachage mmorise pour chaque
valeur de la fonction de hachage v la liste des adresses de tuples tels que H(A) = v,
ainsi que la valeur de lattribut A pour chacun des tuples. La table de hachage est
gnralement suffisamment petite pour tenir en mmoire. Le cot de lalgorithme
est donc :
Cot(TH) = Page(R1) + Page(R2) + Tuple(R1

R2).

Le pseudo-code de cet algorithme est reprsent figure X.17. Lalgorithme prsente

aussi lavantage de permettre lvaluation des requtes en pipeline : ds que la table
de hachage sur R1 a t construite, le pipeline peut tre lanc lors du parcours squentiel de R2. Nous considrons donc cet algorithme comme lun des plus intressants. Il
peut tre coupl avec la construction de partition vue ci-dessus lorsque la table de
hachage devient trop importante.

334 BASES DE DONNES : OBJET ET RELATIONNEL

TableHachage (R1,A, R2,B) {

Pour i = 1, H faire TableH[i] = null ; // nettoyer la table de hachage
Pour chaque page B1 de R1 faire // construire la table de hachage {
Lire (R1,B1) ;
Pour chaque tuple Tuple1 de B1 faire Build(TableH,Tuple1, A) ;
} ;
// Parcourir R2 et tester chaque tuple
Pour chaque page B2 de R2 faire {
Lire (R2,B2) ;
Pour chaque tuple Tuple2 de B2 faire {
Tant que PROBE(TableH,Tuple2, B) faire {
// Joindre si succs
ACCEDER (TableH, AdresseTuple1) ; // obtenir adr.
LIRE (AdresseTuple1, Tuple1) ; // Lire le tuple
ECRIRE(Rsultat,Tuple1||Tuple2) ; // Ecrire rsultat
}
}
}
}

Figure X.17 : Algorithme par table de hachage

4.3.2. Jointure avec index de type arbre-B

Lorsque lune des relations est indexe sur lattribut de jointure (par exemple R1 sur
A), il suffit de balayer la deuxime relation et daccder au fichier index pour chaque
tuple. En cas de succs, on procde la concatnation pour composer le tuple rsultat.
Lalgorithme est analogue la deuxime phase de lalgorithme par hachage en remplaant le fichier hach par le fichier index. Le cot est de lordre de 3*Tuple(R2),
en supposant trois accs en moyenne pour trouver un article dans le fichier index. Si
R2 est grande, le cot peut tre prohibitif et on peut avoir intrt crer un index sur
R2 pour se ramener au cas suivant.
Lorsque les deux relations sont indexes sur les attributs de jointure, il suffit de fusionner les deux index [Valduriez87]. Les couples dadresses de tuples joignant sont alors
directement obtenus. Lalgorithme est peu coteux en entres-sorties (lecture des index
et des tuples rsultats). Par contre, la mise jour de ces index peut tre pnalisante.

4.4. LE CALCUL DES AGRGATS

Les algorithmes permettant de calculer les agrgats sont bass soit sur le tri, soit sur une
combinaison du hachage et du tri. Un tri sur les attributs de groupement (argument du

Optimisation de questions 335

GROUP BY de SQL) permet de crer des monotonies correspondant chaque valeur de

ces attributs. Pour chaque monotonie, on applique les fonctions dagrgat (COUNT,
SUM, MIN, MAX, etc.) demandes. Un hachage pralable sur lattribut de groupement
permet de ramener le problme un calcul dagrgat dans chaque partition. Lapproche
est donc ici analogue celle de la jointure par partition et tri prsente ci-dessus.
La prsence dindex sur les attributs de groupement simplifie les calculs dagrgats en
permettant de crer les monotonies partir de lindex. La prsence dun index sur
lattribut cible argument de la fonction est intressante pour les cas minimum (MIN),
et maximum (MAX). La premire cl de lindex donne la valeur minimale et la dernire la valeur maximale. Il sagit alors de partitionner lindex en fonction des attributs de groupement, ce qui peut seffectuer en une passe de la relation si lindex tient
en mmoire. Les meilleures optimisations dagrgats, trs importantes dans les systmes dcisionnels, passent par la mmorisation des calculs, par exemple dans des
vues concrtes. Ces problmes sont tudis dans le chapitre consacr aux vues.

5. LESTIMATION DU COT DUN PLAN

DEXCUTION
La restructuration algbrique est insuffisante car elle nordonne pas les oprations
binaires. De plus, lapplication dune slection initiale peut faire perdre un index qui
serait utile pour excuter une jointure. Afin daller au-del, une solution pour choisir
le meilleur plan dexcution consiste les gnrer tous, estimer le cot dexcution
de chacun et choisir celui de moindre cot. Malheureusement, une telle stratgie se
heurte plusieurs difficults.

5.1. NOMBRE ET TYPES DE PLANS DEXCUTION

Tout dabord, le nombre de plans dexcution possible est trs grand. Cet inconvnient peut tre vit en liminant tous les plans qui font appel lopration de produit
cartsien comme dans le fameux systme R dIBM ; en effet, la commutation de jointures peut gnrer des produits cartsiens qui en gnral multiplient les tailles des
relations manipuler. On a donc tout intrt viter les plans dexcution contenant
des produits cartsiens. On peut aussi ne pas considrer les arbres ramifis, mais seulement ceux contenant des jointures dune relation de base avec une relation intermdiaire produite par les jointures successives. On parle alors darbre linaire droit ou
gauche (cf. figure X.18).

336 BASES DE DONNES : OBJET ET RELATIONNEL

Arbre linaire droit

Arbre linaire gauche

Arbre ramifi

Figure X.18 : Arbres ramifi ou linaires

Une autre possibilit encore plus restrictive est dliminer tous les plans qui neffectuent pas les slections ds que possible. Ces heuristiques liminant souvent des plans
intressants, on prfre aujourdhui mettre en uvre une stratgie dexploration de
lespace des plans plus sophistique pour trouver un plan proche de loptimal, comme
nous le verrons ci-dessous.
Le nombre de plans devient vite trs grand. En effet, considrons simplement le cas
dune requte portant sur n relations et effectuant donc (n-1) jointures. Soit P(n) le
nombre de plans. Si lon ajoute une relation, pour chaque jointure il existe deux positions possibles pour glisser la nouvelle jointure ( droite ou gauche), et ce de deux
manires possibles (nouvelle relation droite ou gauche) ; pour la jointure au sommet de larbre, il est aussi possible dajouter la nouvelle jointure au-dessus en positionnant la nouvelle relation droite ou gauche. Le nombre de jointures de n relations tant (n-1), il est possible de calculer :
P(n+1) = 4*(n-1) *P(n)+2*P(n) avec P(2) = 1.
Do lon dduit encore :
P(n+1) = 2*(2n-1)*P(n) avec P(2) = 1.
Il sensuit le nombre de plans possibles :
P(n+1) = (2n) ! / n !

Optimisation de questions 337

Un rapide calcul conduit au tableau suivant donnant le nombre de plans possibles P(n)
pour n relations :
n
2
3
4
5
6
7
8
9
10
11
12

P(n)
2
12
120
1680
30240
665280
17297280
518918400
1,7643E+10
6,7044E+11
2,8159E+13

On voit ainsi que le nombre de plans devient rapidement trs grand. Ce calcul ne
prend pas en compte le fait que plusieurs algorithmes sont possibles pour chaque oprateur de jointure. Si a algorithmes sont disponibles, le nombre de plans pour n relations doit tre multipli par an-1. Ceci devient rapidement un nombre considrable.
Le calcul du cot dun plan peut tre effectu rcursivement partir de la racine N de
larbre en appliquant la formule suivante, dans laquelle Filsi dsigne les fils du nud
N:
COUT (PT) = COUT(N) + COUT(FILSI).
Le problme est donc de calculer le cot dun nud qui reprsente une opration relationnelle. La difficult est que lestimation du cot dune opration ncessite, au-del
de lalgorithme appliqu, la connaissance de la taille des relations dentre et de sortie. Il faut donc estimer la taille des rsultats intermdiaires de toutes les oprations de
larbre considr. Le choix du meilleur algorithme pour un oprateur ncessite dautre
part la prise en compte des chemins daccs aux relations (index, placement, lien)
qui change directement ces cots. Nous allons ci-dessous examiner les rsultats
concernant ces deux problmes.

5.2. ESTIMATION DE LA TAILLE DES RSULTATS

INTERMDIAIRES
Lestimation de la taille des rsultats est base sur un modle de distribution des
valeurs des attributs dans chacune des relations, et ventuellement des corrlations
entre les valeurs dattributs. Le modle doit tre conservatif, cest--dire que pour
toute opration de lalgbre relationnelle, il faut tre capable, partir des paramtres
dcrivant les relations arguments, de calculer les mmes paramtres pour la relation

338 BASES DE DONNES : OBJET ET RELATIONNEL

rsultat. Le modle le plus simple est celui qui suppose luniformit de la distribution
des valeurs et lindpendance des attributs [Selinger79]. De telles hypothses sont utilises dans tous les optimiseurs de systmes en labsence dinformations plus prcises
sur la distribution des valeurs dattributs. Un tel modle ncessite de connatre au
minimum :
le nombre de valeurs dun attribut A not Tuple(A);
les valeurs minimale et maximale dun attribut A notes MIN(A) et MAX(A);
le nombre de valeurs distinctes de chaque attribut A not NDIST(A);
le nombre de tuples de chaque relation R not Tuple(R).
Le nombre de tuples dune restriction est alors calcul par la formule :
TUPLE ((R)) = P(CRITERE) * TUPLE(R)

o p(critre) dsigne la probabilit que le critre soit vrifi, appele facteur de slectivit du prdicat de restriction.
Notion X.13 : Facteur de slectivit (Selectivity factor)
Coefficient associ une opration sur une table reprsentant la proportion de tuples de la table
satisfaisant la condition de slection.

Avec une hypothse de distribution uniforme des valeurs dattributs, le facteur de

slectivit peut tre calcul comme suit :
p(A=valeur) = 1/NDIST(A)
p(A>valeur) = (MAX(A) valeur)/(MAX(A) MIN(A))
p(A<valeur) = (valeur MIN(A))/(MAX(A) MIN(A))
p(A IN liste) = (1/NDIST(A)) * Tuple(liste)
p(P et Q) = p(P) * p(Q)
p(P ou Q) = p(P) + p(Q) p(P) * p(Q)
p(not P) = 1 p(P)

Le nombre de tuples dune projection sur un groupe dattributs X est plus simplement
obtenu par la formule :
TUPLE((R)) = (1-d) * TUPLE(R)

avec d = probabilit de doubles. La probabilit de doubles peut tre estime en fonction du nombre de valeurs distinctes des attributs composant X ; une borne suprieure
peut tre obtenue par la formule :
d = (1-NDIST(A1)/Tuple(R))*(1-NDIST(A2)/Tuple(R))
* (1-NDIST(Ap)/Tuple(R)

o A1, A2, . An dsigne les attributs retenus dans la projection.

La taille dune jointure est plus difficile valuer en gnral. On pourra utiliser la formule :
Tuple(R1
R2) = p * Tuple(R1) * Tuple(R2)

Optimisation de questions 339

o p, compris entre 0 et 1, est appel facteur de slectivit de la jointure. En supposant

une qui-jointure sur un critre R1.A = R2.B et une indpendance des attributs A
et B, le nombre de tuples de R2 qui joignent avec un tuple de R1 donn est au plus
Tuple(R2)/NDIST(B). Pour tous les tuples de R1, on obtient donc
Tuple(R1)*Tuple(R2)/NDIST(B) tuples dans la jointure. On en dduit la formule p = 1/NDIST(B). Mais en renversant lordre des relations, on aurait dduit
la formule p = 1/NDIST(A). Ceci est d au fait que certains tuples de R1 (et de
R2) ne participent pas la jointure, alors quils ont t compts dans chacune des formules. Une estimation plus raisonnable demanderait dliminer les tuples ne participant pas la jointure. Il faudrait pour cela prendre en compte le nombre de valeurs
effectives du domaine commun de A et B, nombre en gnral inconnu. On utilisera
plutt une borne suprieure de p donne par la formule
p = 1/ MIN(NDIST(A),NDIST(B)).
Les estimations de tailles des relations et attributs doivent tre mmorises au niveau
de la mtabase. Elles devraient thoriquement tre mises jour chaque modification
de la base. La plupart des systmes ne mettent jour les statistiques que lors de lexcution dune commande spcifique (RUNSTAT) sur la base. Afin daffiner les estimations, il est possible de mmoriser des histogrammes de distribution des valeurs
dattributs dans la mtabase. Ces valeurs sont calcules par des requtes comportant
des agrgats. Les formules prcdentes sont alors appliques pour chaque fraction de
lhistogramme qui permet destimer le nombre de valeurs distinctes (NDIST) ou non
(Tuple) dans une plage donne.

5.3. PRISE EN COMPTE DES ALGORITHMES DACCS

Chaque oprateur est excut en appliquant si possible le meilleur algorithme daccs
aux donnes. Le cot dominant dun oprateur est le cot en entres-sorties. Celui-ci
dpend grandement des chemins daccs disponibles, comme nous lavons vu ci-dessus, lors de ltude des oprateurs daccs. Par exemple, en dsignant toujours par
Tuple(R) le nombre de tuple de la relation R, par Page(R) son nombre de pages, par
(B+1) le nombre de pages disponibles en mmoire cache, nous avons pour la jointure
par boucles imbriques (BI) dans le cas sans index :
Cot(BI(R1,R2)) = Page(R1) + [Page(R1)/B]*Page(R2).
S il existe un index sur lattribut de jointure de R2, le cot devient :
Cot(BI(R1,R2)) = Page(R1) + Tuple(R1)*I(R2)
o I(R2) dsigne le nombre moyen dentres-sorties pour accder au tuple de R2 via
lindex. I(R2) dpend du type dindex, de sa hauteur, de la mmoire centrale disponible pour lindex, et aussi du fait que R1 soit trie sur lattribut de jointure ou non.
En gnral, I(R2) varie entre 0.5 et la hauteur de lindex, 2 tant une valeur
moyenne classique.

340 BASES DE DONNES : OBJET ET RELATIONNEL

Au-del des cots en entres-sorties, il faut aussi estimer les cots de calcul, souvent
ngligs. Dans Systme R [Selinger79], la dtermination du plan dexcution est
effectue en affectant un cot chaque plan candidat calcul par la formule suivante :
COUT = NOMBRE DACCES PAGE + W*NOMBRE DAPPELS INTERNES.

Le nombre dappels internes donne une estimation du temps de calcul ncessaire

lexcution du plan, alors que le nombre daccs page value le nombre dentres-sorties ncessaires lexcution du plan. W est un facteur ajustable dimportance relative
du temps unit centrale et du temps entres-sorties. Le nombre daccs page est
estim par valuation dun facteur de slectivit F pour chacun des prdicats associs
une opration de lalgbre relationnelle. Le nombre daccs pour lopration est calcul en fonction de F et de la taille des relations oprandes. Le calcul de F tient
compte de la prsence ou non dindex ; ainsi, par exemple, le facteur de slectivit
dune slection du type Attribut = valeur est estim par :
F = 1/ Nombre dentres dans lindex
sil existe un index et 1/10 sinon.

6. LA RECHERCHE DU MEILLEUR PLAN

Loptimisation physique permet de prendre en compte le modle de cot afin de dterminer le meilleur plan, ou un plan proche de celui-l. Elle part dun arbre en forme
canonique, par exemple compos de slections dont les critres sont sous forme normale conjonctive, puis de jointures, unions, intersections et diffrences, et enfin
dagrgats suivis encore dventuelles slections/projections finales, certaines de ces
oprations pouvant tre absentes. Elle transforme cet arbre en un plan daccs en choisissant les algorithmes pour chaque oprateur, et en modifiant ventuellement larbre
afin de profiter de proprits physiques de la base (index par exemple).
Comme vu ci-dessus, le nombre de plans dexcution possible peut tre trs grand
pour des questions complexes. Lensemble des plans possible est appel espace des
plans. Afin dviter dexplorer exhaustivement cet espace de recherche, cest--dire
dexplorer tous les plans, les optimiseurs modernes sont construits comme des gnrateurs de plans coupls une stratgie de recherche dcoulant des techniques doptimisation de la recherche oprationnelle [Swami88].
Notion X.14 : Stratgie de recherche (Search strategy)
Tactique utilise par loptimiseur pour explorer lespace des plans dexcution afin de dterminer un
plan de cot proche du minimum possible.

Optimisation de questions 341

Un optimiseur est ferm lorsque tous les oprateurs et algorithmes daccs, ainsi que
toutes les rgles de permutation de ces oprateurs, sont connus la construction du systme. Les systmes relationnels purs ont gnralement des optimiseurs ferms. La stratgie de recherche dans les optimiseurs ferms est base sur un algorithme dterministe,
qui construit une solution pas pas soit en appliquant une heuristique ou une mthode
dvaluation progressive permettant dexhiber le meilleur plan, de type programmation
dynamique. Nous tudions dans cette section quelques algorithmes de cette classe.

6.1. ALGORITHME DE SLECTIVIT MINIMALE

Cet algorithme trs simple consiste complter les optimisations logiques prsentes cidessus, telles par exemple la descente des restrictions et projections, par un ordonnancement des jointures par ordre de slectivit croissante. Lalgorithme construit un arbre
linaire gauche en partant de la plus petite relation, et en joignant chaque niveau avec
la relation restante selon le plus petit facteur de slectivit de jointure. Ainsi, les relations intermdiaires sont globalement gardes prs du plus petit possible. Cet algorithme, reprsent figure X.19 gnralise la mthode de dcomposition dIngres tudie
ci-dessus. Une variante peut consister produire chaque fois la relation de plus petite
cardinalit. Pour chaque opration, lalgorithme de cot minimal est ensuite slectionn.
Ces algorithmes restent simples, mais sont loin de dterminer le meilleur plan.
Algorithme MinSel {
Rels = liste des relations joindre ;
p = plus petite relation ;
Tant que Rels non vide {
R = relation de selectivit minimum de Rels ;
p = join(R,p) ;
Rels = Rels R ;} ;
Retourner(p) ;}

Figure X.19 : Algorithme doptimisation par slectivit minimale

6.2. PROGRAMMATION DYNAMIQUE (DP)

La programmation dynamique est une mthode trs connue en recherche oprationnelle, dont le principe est que toute sous-politique dune politique optimale est optimale. Ainsi, si deux sous-plans quivalents du plan optimal cherch sont produits, il
suffit de garder le meilleur et de le complter pour atteindre le plan optimal. Cette
technique, employe dans le systme R [Selinger79] pour des plans sans produit cartsien, permet de construire progressivement le plan, par ajouts successifs doprateurs. Lalgorithme commence par crer tous les plans mono-relation, et construit des
plans de plus en plus larges tape par tape. A chaque tape, on tend les plans pro-

342 BASES DE DONNES : OBJET ET RELATIONNEL

duits ltape prcdente en ajoutant un oprateur. Quand un nouveau plan est

gnr, la collection de plans produits est consulte pour retrouver un plan quivalent.
Si un tel plan est trouv, alors les cots des deux plans sont compars et seul celui de
cot minimal est conserv. La figure X.20 dcrit de manire plus prcise lalgorithme
connu sous le nom DP (Dynamic Programming). Cet algorithme assez simple devient
trs coteux pour un nombre important de relations, si lon considre tous les arbres
possibles. La complexit est de lordre de 2N, o N est le nombre de relations. Il nest
donc que difficilement applicable au-del dune dizaine de relations [Swami88].
Algorithme DP {
PlanOuverts = liste de tous les plans mono-relation possible ;
Eliminer tous les plans quivalents excepts les moins coteux ;
Tant quil existe p PlanOuverts {
Enlever p de PlanOuverts ;
PlanOptimal = p ;
Pour chaque oprateur o permettant dtendre p {
Etendre le plan p en ajoutant cet oprateur o ;
Calculer le cot du nouveau plan ;
Insrer le nouveau plan dans PlanOuverts ;}
Eliminer tous les plans quivalents excepts les moins coteux ;}
Retourner(PlanOptimal) ;} ;

Figure X.20 : Algorithme doptimisation par programmation dynamique

6.3. PROGRAMMATION DYNAMIQUE INVERSE

Une variante de lalgorithme prcdent consiste calculer rcursivement la meilleure
jointure possible parmi N relations, et ce selon tous les ordres possibles. Bien que
rcursif, lalgorithme est analogue au prcdent mais procde en profondeur plutt
quen largeur. Il a lavantage de construire plus rapidement des rsultats et peut ainsi
tre arrt si le temps consacr loptimisation est dpass. La figure X.21 illustre cet
algorithme dans le cas des jointures.
Algorithme RDP (Rels) {
PlanOuverts = {} ;
Cot(MeilleurPlan) = ;
Pour chaque R in Rels{
RestRels = Rels R ;
si RestRels = {} alors p = R sinon
p = R
RDP(RestRels) ;
Insrer p dans PlanOuverts ;
si cot(p) cot(MeilleurPlan) alors MeilleurPlan = p ;
Eliminer tous les plans quivalents excepts les moins coteux ;}
Retourner (MeilleurPlan) ;};

Figure X.21 : Algorithme doptimisation par programmation dynamique inverse

Optimisation de questions 343

6.4. LES STRATGIES DE RECHERCHE ALATOIRES

Les diffrentes stratgies de recherche sont classes selon une hirarchie de spcialisation figure X.22. On distingue les stratgies numratives des stratgies alatoires. Les premires numrent systmatiquement des plans possibles. La stratgie
exhaustive les numre tous. La stratgie par augmentation les construit progressivement en partant par exemple de la projection finale et en introduisant progressivement les relations, par exemple par ordre de taille croissante. Elle vitera en gnral
les produits cartsiens et appliquera ds que possible restriction et projection.
Les stratgies alatoires [Lanzelotte91] explorent alatoirement lespace des plans.
Lamlioration itrative tire au hasard n plans (par exemple en permutant lordre des
relations) et essaie de trouver pour chacun deux le plan optimal le plus proche (par
exemple par descente des restrictions et projections, et choix des meilleurs index).
Loptimum des plans localement optimum est finalement slectionn. La stratgie du
recuit simul procde partir dun plan que lon tente doptimiser en appliquant des
transformations successives. Les transformations retenues amliorent ce plan exceptes quelques-unes introduites afin dexplorer un espace plus large avec une probabilit variant comme la temprature du systme (en e1/T, o T est la temprature). La
temprature est de fait une variable dont la valeur est trs leve au dpart et qui diminue au fur et mesure des transformations, de sorte ne plus accepter de transformation dtriorant le cot quand le systme est gel. Cette stratgie, bien connue en
recherche oprationnelle, permet de converger vers un plan proche de loptimum, en
vitant les minimums locaux. On citera enfin les stratgies gntiques qui visent
fusionner deux plans pour en obtenir un troisime.
Stratgie
de recherche

Enumrative

Exhaustive

Augmentation

Alatoire

Amlioration
itrative

Recuit
simul

Gntique

Figure X.22 : Principales stratgies de recherche

Toutes ces stratgies sont trs intressantes pour des systmes extensibles, objet ou
objet-relationnel. En effet, dans un tel contexte le nombre de plans dexcution

344 BASES DE DONNES : OBJET ET RELATIONNEL

devient trs grand. Les choix sont donc trs difficiles et les stratgies de type programmation dynamique deviennent dapplication difficile. Voil pourquoi nous tudierons les stratgies alatoires plus en dtail dans la partie III de cet ouvrage.

7. CONCLUSION
Dans ce chapitre, nous avons tudi les algorithmes et mthodes de base pour lvaluation efficace des requtes dans les SGBD relationnelles. Ltude a t ralise
partir de requtes exprimes en algbre relationnelle. Pour rduire la complexit, nous
avons dcompos le problme de loptimisation en une phase logique fonde sur les
techniques de rcriture et une phase physique base sur un modle de cot. De nos
jours, la ralisation dun optimiseur performant ncessite dintgrer ces deux phases.
Nous nous sommes plus concentrs sur loptimisation des requtes avec jointures car
celles-ci sont trs frquentes et souvent coteuses dans les bases de donnes relationnelles. Nous navons quesquiss loptimisation des agrgats. Nous reviendrons sur ce
problme dans les perspectives pour laide la dcision. Nous navons aussi quesquiss
ltude des stratgies de recherche alatoires, qui permettent de trouver rapidement un
plan satisfaisant dans des espaces de recherche trs vastes. Nous reviendrons sur cet
aspect dans le cadre des optimiseurs extensibles, mis en uvre dans les SGBD objet et
objet-relationnel, au moins en thorie. Dans ce contexte, les plans sont encore plus nombreux que dans les SGBD relationnels, et la stratgie devient un composant essentiel.
Les techniques abordes se gnralisent au contexte des bases de donnes rparties et
parallles. Les techniques de base de lapproche multiprocesseurs consistent diviser
pour rgner : les tables sont partitionnes sur plusieurs serveurs parallles ou rpartis,
les requtes sont divises en sous-requtes par lvaluateur de requtes. Le problme
supplmentaire est doptimiser les transferts entre serveurs. Ceux-ci seffectuent par le
biais dune mmoire commune, dun bus partag ou dun rseau, selon le contexte. Le
modle de cot doit prendre en compte ces transferts, et les algorithmes doivent tre
adapts. Les fondements restent cependant identiques ceux prsents dans ce chapitre.

8. BIBLIOGRAPHIE
[Aho79] Aho A.V., Sagiv Y., Ullman J.D., Equivalences among Relational
Expressions , SIAM Journal of Computing, vol. 8, n 2, p. 218-246, Juin 1979.

Optimisation de questions 345

Cet article dfinit formellement lquivalence dexpressions algbriques et

donne des conditions dquivalence.
[Astrahan76] Astrahan M.M. et al., System R : Relational Approach to Database
Management , ACM TODS, vol. 1, n 2, Juin 1976.
Cet article de synthse prsente le fameux systme R ralis San Jos, au
centre de recherche dIBM. Il dcrit tous les aspects, en particulier loptimiseur
de requtes, intressant pour ce chapitre.
[Babb79] Babb E., Implementing a Relational Database by Means of Specialized
Hadware , ACM TODS, vol. 4, n 1, Mars 1979.
Auteur de la machine bases de donnes CAFS ralise ICL en Angleterre, E.
Babb introduit en particulier les tableaux de bits afin dacclrer les jointures
par hachage.
[Bernstein81] Bernstein P.A., Chiu D.W., Using Semijoins to Solve Relational
Queries , Journal of the ACM, vol. 28, n 1, p. 25-40, Janvier 1981.
Cet article prsente une tude approfondie de lusage des semi-jointures pour
rsoudre les questions relationnelles. De multiples rsultats bass sur ltude
du graphe des relations pour dcomposer une requte en semi-jointures sont
tablis.
[Blasgen76] Blasgen M.W., Eswaran K.P., On the Evaluation of Queries in
Relational Systems , IBM Systems Journal, vol. 16, p. 363-377, 1976.
Se fondant sur le dveloppement et les expriences conduites autour de systme
R, les auteurs montrent que diffrents algorithmes de jointures doivent tre
considrs pour valuer efficacement les requtes dans les SGBD relationnels.
[Chakravarthy90] Chakravarthy U.S., Grant J., Minker J., Logic Based Approach to
Semantic Query Optimization , ACM Transactions on Database Systems,
vol. 15, n 2, p. 162-207, Juin 1990.
Cet article dmontre lapport de contraintes dintgrit exprimes en logique du
premier ordre pour loptimisation de requtes. Il propose un langage dexpression de contraintes et des algorithmes de base pour optimiser les requtes.
[DeWitt84] DeWitt D., Katz R., Olken F., Shapiro L., Stonebraker M., Wood D.,
Implementation Techniques for Main Memory Databases , Proc. ACM SIGMOD Int. Conf. on Management of data, Boston, Mass., p. 1-8, Juin 1984.
Les auteurs proposent diffrentes techniques pour la gestion de bases de donnes en mmoire. Lalgorithme de hachage Build and Probe consiste
construire une table hache en mmoire partir de la premire relation, puis
tester chaque tuple de la seconde relation contre cette table en appliquant la
mme fonction de hachage. Chaque entre de la table contient un pointeur vers
le tuple et la valeur de lattribut de jointure, ce qui permet de tester le prdicat
de jointure et de retrouver le tuple efficacement.

346 BASES DE DONNES : OBJET ET RELATIONNEL

[DeWitt86] DeWitt D., Gerber R., Graefe G., Heytens M., Kumar K., Mualikrishna
M., Gamma A high performance Dataflow Database Machine , Proc.
12th Intl. Conf. on Very Large Data Bases, Kyoto, Japan, Morgan Kaufman Ed.,
Septembre 1986.
La machine GAMMA ralise lUniversit de Madison explore les techniques
de flot de donnes pour parallliser les oprateurs de jointure. Les algorithmes
de type pipeline ont t expriments pour la premire fois sur un rseau local
en boucle.
[DeWitt92] DeWitt D., Naughton J., Schneider D., Seshadri S., Practical Skew
Handling in Parallel Joins Proc. 18th Intl. Conf. on Very Large Data Bases,
Sydney, Australia, Morgan Kaufman Ed., Septembre 1992.
Cet article tudie les effets des distributions biaises de valeurs dattributs de
jointure sur les algorithmes de jointure. Les algorithmes hybrides semblent les
plus rsistants.
[Finance94] Finance B., Gardarin G., A Rule-based Query Optimizer with
Adaptable Search Strategies , Data and Knowledge Engineering, NorthHolland Ed., vol. 3, n 2, 1994.
Les auteurs dcrivent loptimiseur extensible ralis dans le cadre du projet
Esprit EDS. Cet optimiseur est extensible grce un langage de rgles puissant
et dispose de diffrentes stratgies de recherche paramtrables.
[Fushimi86] Fushimi S., Kitsuregawa M., Tanaka H., An Overview of the System
Software of a Parallel Relational Database Machine : GRACE , Proc. 12th Int.
Conf. on Very Large Data Bases, Kyoto, Japan, Morgan Kaufman Ed.,
Septembre 1986.
Les auteurs prsentent la machine bases de donnes GRACE. Celle-ci se distingue par son algorithme de jointure parallle bas sur une approche mixte,
combinant hachage et tri.
[Gardarin84] Gardarin G., Jean-Nol M., Kerherv B., Mermet D., Pasquer F., Simon
E., Sabrina : un Systme de Gestion de Bases de Donnes Relationnelles issu
de la Recherche , Revue TSI, Dunod AFCET Ed., vol. 5, n 6, 1986.
Cet article dcrit le SGBD SABRE ralis lINRIA de 1980 1984, puis
industrialis et commercialis par la socit INFOSYS de 1984 1990. Ce
SGBD disposait dun optimiseur bas sur des heuristiques sophistiques.
[Graefe93] Graefe G., Query Evaluation Techniques for Large Databases , ACM
Computer Surveys, vol. 25, n 2, p. 73-170, Juin 1993.
Un des plus rcents articles de synthse sur loptimisation de requtes.
Lauteur prsente une vue densemble des techniques doptimisation de
requtes, en mettant en avant leur comportement vis--vis de grandes bases de
donnes.

Optimisation de questions 347

[Gray91] Gray J., The Benchmark Handbook for Database and Transaction
Processing Systems, 2nd edition, Morgan Kaufman, San Mateo, CA, 1991.
Le livre de rfrence du Transaction Processing Council (TPC). Il prsente les
benchmarks de base, notamment TPC/A, TPC/B, TPC/C, et les conditions
prcises dexcution de ces bancs dessais.
[Haas89] Haas M.L., Freytag J.C., Lohman G.M., Pirahesh H., Extensible Query
Processing in Starbust , Proc. ACM SIGMOD Intl. Conf. On Management of
Data, p. 377-388, 1989.
Cet article prsente loptimiseur de Starbust, un systme extensible ralis
IBM. Cet optimiseur se dcompose clairement en deux phases, la rcriture et
le planning. Il est la base des nouvelles versions de loptimiseur de DB2.
[Hevner79] Hevner A.R., Yao B., Query Processing in Distributed Database
Systems , IEEE Transactions on Software Engineering, vol. 5, n 3, p. 177187, Mai 1979.
Cet article prsente une synthse des techniques doptimisation de requtes
connues cette date dans les BD rparties. Il dveloppe un modle de cot
incluant le trafic rseau.
[Jarke84] Jarke M., Koch J., Query Optimization in Database Systems ACM
Computing Surveys, vol. 16, n 2, p. 111-152, Juin 1984.
Un des premiers articles de synthse sur loptimisation de requtes dans les
bases de donnes relationnelles. Larticle suppose les questions exprimes en
calcul relationnel de tuples. Il donne un cadre gnral pour lvaluation de
requtes et couvre les algorithmes de rcriture logique, les mthodes doptimisation physique, les modles de cot, et plus gnralement les principales techniques connues cette poque.
[Kim85] Kim Won, Reiner S., Batory D., Query Processing in Database Systems,
Springer-Verlag Ed., 1985.
Ce livre de synthse est compos dune collection darticles. partir dun chapitre de synthse introductif, les auteurs dveloppent diffrents aspects spcifiques : bases de donnes rparties, htrognes, objets complexes, optimisation multi-requtes, machines bases de donnes, modle de cot, etc.
[King81] King J.J., QUIST : A System for Semantic Query Optimization in
Relational Data Bases , Proc. 7th Intl. Conf. on Very Large Data Bases,
Cannes, France, IEEE Ed., p. 510-517, Sept. 1981.
Cet article dcrit lun des premiers systmes capables de prendre en compte les
contraintes dintgrit pour loptimisation de requtes.
[Knuth73] Knuth D.E., The Art of Computer Programming, Volume 3 : Sorting and
Searching, Addison-Wesley, Reading, Mass., 1973.

348 BASES DE DONNES : OBJET ET RELATIONNEL

Le fameux livre de Knuth consacr aux algorithmes et structures de donnes

pour les recherches et les tris.
[Rosenkrantz80] Rosenkrantz D.J., Hunt H.B., Processing Conjunctive Predicates
and Queries , Proc. 6th Intl. Conf. on Very Large Data Bases, Montral,
Canada, IEEE Ed., Septembre 1980.
Cet article prsente des techniques permettant de dterminer des questions
contradictoires, quivalentes, ou incluses lune dans lautre. Les mthodes sont
bases sur un graphe dattribut normalis o les arcs sont valus par des
constantes. Un arc allant dun nud x un nud y correspond lingalit x
y+c. Une galit est modlise par deux arcs. Par exemple, une question est
contradictoire sil existe un cycle dont la somme des valuations est ngative.
[Selinger79] Selinger P., Access Path Selection in a Relational Database
Management System , ACM SIGMOD Intl. Conf. On Management of Data,
Boston, Mai 1979.
Cet article dcrit les algorithmes de slection de chemin daccs dans le systme R. Il introduit le modle de cot bas sur des distributions uniformes
dcrit section 5, et la mthode de slection du meilleur plan base sur la programmation dynamique.
[Smith75] Smith J.M., Chang P.Y., Optimizing the performance of a Relational
Algebra Database Interface , Comm. ACM, vol. 18, n 10, p. 68-579, 1975.
Les auteurs introduisent lensemble des rgles de restructuration algbrique
permettant doptimiser logiquement les expressions de lalgbre relationnelle.
[Stonebraker76] Stonebraker M., Wong E., Kreps P., Held G., The Design and
Implementation of Ingres , ACM TODS, vol. 1, n 3, Septembre 1976.
Cet article de synthse prsente le fameux systme INGRES ralis luniversit de Berkeley. Il dcrit tous ses aspects, en particulier loptimiseur de
requtes bas sur la dcomposition de requtes.
[Stonebraker87] Stonebraker M., The Design of the Postgres Storage System , 13e
Intl. Conf. on Very Large Data Bases, Morgan Kaufman Ed., Brighton,
Angleterre, 1987.
Postgres signifie aprs Ingres . M. Stonebraker a construit ce systme
Berkeley aprs avoir ralis et commercialis le systme Ingres. Postgres est
original car fortement bas sur les concepts dvnements et dclencheurs,
mais aussi par ses capacits intgrer de nouveaux types de donnes pris en
compte par un optimiseur extensible. Postgres est devenu plus tard le SGBD
Illustra rachet par Informix en 1995.
[Swami88] Swami A., Gupta A., Optimization of Large Join Queries , ACM SIGMOD Intl. Conf., Chicago, 1988.

Optimisation de questions 349

Cet article tudie les stratgies de recherche du meilleur plan pour des requtes
comportant plus dune dizaine de jointures. Des stratgies alatoires telles que
lamlioration itrative et le recuit simul sont compares.
[TPC95] Transaction Processing Council, Benchmark TPC/D, San Fransisco, CA,
1995.
La dfinition du TPC/D telle que propose par le TPC.
[Ullman88] Ullman J.D., Principles of Database and Knowledge-base Systems,
volumes I (631 pages) et II (400 pages), Computer Science Press, 1988.
Deux volumes trs complets sur les bases de donnes, avec une approche plutt
fondamentale. Jeffrey Ullman dtaille tous les aspects des bases de donnes,
depuis les mthodes daccs aux modles objets en passant par le modle
logique. Ces ouvrages sont finalement trs centrs sur une approche par la
logique aux bases de donnes. Les principaux algorithmes daccs et doptimisation de requtes sont dtaills dans un chapitre plutt formel.
[Valduriez84] Valduriez P., Gardarin G., Join and Semi-Join Algorithms for a
Multiprocessor Database Machine , ACM TODS, vol. 9, n 1, 1984.
Cet article introduit et compare diffrents algorithmes de jointure et semi-jointure pour machines multiprocesseurs. Il montre quaucune dentre-elles nest
dominante, mais que chacune a son domaine dapplication selon la taille des
relations et la slectivit des jointures.
[Valduriez87] Valduriez P., Join Indices , ACM TODS, vol. 12, n 2, Juin 1987.
Lauteur introduit les index de jointure, des index qui mmorisent la jointure
pr-calcule entre deux tables. Chaque entre de lindex est un couple de pointeurs rfrenant deux tuples participant la jointure, lun appartenant la
premire table, lautre la seconde. De tels index sont trs efficaces en interrogation. Le problme de ce type dindex est la mise jour.
[Wong76] Wong E., Youssefi K., Decomposition A Strategy for Query
Processing , ACM TODS, vol. 1, n 3, Septembre 1976.
Cet article prsente la mthode de dcomposition telle quimplmente dans le
systme Ingres. On a compris plus tard que la mthode permettait de dtacher
les semi-jointures en plus des slections.

Partie 3

LOBJET
ET LOBJETRELATIONNEL

XI Le modle objet (The object model)

XII Le standard de lODMG
(OQL, ODL and OML languages)
XIII Lobjet-relationnel et SQL3
(Object-relational DB and SQL3)
XIV Loptimisation de requtes objet
(Object query optiomization)

Chapitre XI

LE MODLE OBJET
1. INTRODUCTION
Les modles objets, encore appels modles orients objets ou simplement modles
objet, sont issus des rseaux smantiques et des langages de programmation orients
objets. Ils regroupent les concepts essentiels pour modliser de manire progressive
des objets complexes encapsuls par des oprations de manipulation associes. Ils
visent permettre la rutilisation de structures et doprations pour construire des
entits plus complexes. Ci-dessous, nous dfinissons les concepts qui nous semblent
importants dans les modles de donnes objets. Ces concepts sont ceux retenus par
lOMG lorganisme de normalisation de lobjet en gnral , dans son modle objet
de rfrence [OMG91]. Certains sont obligatoires, dautres optionnels. Ce modle est
proche du modle de classe de C++ [Stroustrup86, Lippman91], qui peut tre vu
comme une implmentation des types abstraits de donnes. Il est aussi trs proche du
modle objet du langage Java [Arnold96].
Bien que C++ et Java soient aujourdhui les langages de programmation dapplications sur lesquels sappuient la plupart des bases de donnes objets, il existe dautres
langages orients objet. Historiquement, Simula a t le premier langage orient
objet ; il est toujours un peu utilis. Simula a introduit le concept de classe qui
regroupe au sein dune mme entit la structure de donnes et les fonctions de services qui la grent. Simula avait t dvelopp pour la simulation et disposait notamment doutils gnriques dont un chancier intressants. Smalltalk [Goldeberg83] est

354 BASES DE DONNES : OBJET ET RELATIONNEL

n la fin des annes 70, en reprenant des concepts de Simula. Cest un langage
orient objet populaire, souvent interprt et disposant denvironnements interactifs
intressants. Dans le monde des bases de donnes, il a t utilis par les concepteurs
de GemStone [Maier86] comme langage de base pour dfinir les structures dobjets et
programmer les applications.
Divers dialectes Lisp sont orients objet, si bien que lapproche bases de donnes
objets est ne partir de Lisp. Orion [WonKim88] fut historiquement le premier
SGBD objets construit partir dun Lisp objet. Aujourdhui, et malgr quelques
dtours vers des langages spcifiques [Lcluse89], la plupart des SGBD objets sont
bass sur C++ et sorientent de plus en plus vers Java. Ils permettent de grer des
classes dobjets persistants. Ce choix est effectu essentiellement pour des raisons de
performance et de popularit du langage C++, qui est une extension du langage C ;
C++ est dailleurs traduit en C par un pr-compilateur. Quelques SGBDO supportent
Smalltalk. Java est le langage objet davenir, support par la plupart des SGBDO. La
trs grande portabilit et la scurit du code intermdiaire gnr le fameux bytecode facile a distribuer , en font un langage de choix pour les applications client-serveur et web plusieurs niveaux de code applicatif.
Ce chapitre se propose dintroduire les concepts de la modlisation objet et les oprations de base pour manipuler des objets persistants. Aprs cette introduction, la section 2 introduit les principes des modles objets en les illustrant par un modle de
rfrence proche de celui de lOMG. La section 3 dfinit plus prcisment ce quest
un SGBDO et discute des principales techniques de gestion de la persistance proposes dans les systmes. La section 4 propose une algbre pour objets complexes dfinie sous forme de classes et permettant de manipuler des collections dobjets un
niveau intermdiaire entre un langage SQL tendu et un langage de programmation
navigationnel de type C++ persistant. La conclusion rsume les points abords et
introduit les problmes essentiels rsoudre pour raliser un SGBDO.

2. LE MODLE OBJET DE RFRENCE

2.1. MODLISATION DES OBJETS
Les modles de donnes objets ont t crs pour modliser directement les entits
du monde rel avec un comportement et un tat. Le concept essentiel est bien sr celui
dobjet. Il nest pas simple dfinir car composite, cest--dire intgrant plusieurs
aspects. Dans un modle objet, toute entit du monde rel est un objet, et rciproquement, tout objet reprsente une entit du monde rel.

Le modle objet 355

Notion XI.1 : Objet (Object)

Abstraction informatique dune entit du monde rel caractrise par une identit, un tat et un
comportement.

Un objet est donc une instance dentit. Il possde une identit qui permet de le reprer. Par exemple, un vhicule particulier V1 est un objet. Un tel vhicule est caractris par un tat constitu dun numro, une marque, un type, un moteur, un nombre de
kilomtres parcourus, etc. Il a aussi un comportement compos dun ensemble doprations permettant dagir dessus, par exemple crer(), dmarrer(), rouler(), stopper(),
dtruire(). Chaque opration a bien sr des paramtres que nous ne prcisons pas pour
linstant.
Lobjet de type vhicule didentit V1 peut tre reprsent comme un groupe de
valeurs nommes avec un comportement associ, par exemple :
V1 {
Numro: 812 RH 94, Marque: Renault, Type: Clio, Moteur: M1 ;
crer(), dmarrer(), rouler(), stopper(), dtruire() }.
Une personne est aussi un objet caractris par un nom, un prnom, un ge, une voiture habituellement utilise, etc. Elle a un comportement compos dun ensemble
doprations { natre(), vieillir() , conduire(), mourir() }. Lobjet de type personne
didentit P1 peut tre dcrit comme suit :
P1 {
Nom: Dupont, Prnom: Jules, Age: 24, Voiture: V1 ;
natre(), vieillir(), conduire(), mourir() }.
Un objet peut tre trs simple et compos seulement dune identit et dune valeur
(par exemple, un entier E1 {Valeur: 212}). Il peut aussi tre trs complexe et luimme compos dautres objets. Par exemple, un avion est compos de deux moteurs,
de deux ailes et dune carlingue, qui sont eux-mmes des objets complexes.
travers ces exemples, deux concepts importants apparaissent associs la notion
dobjet. Tout dabord, un objet possde un identifiant qui matrialise son identit.
Ainsi, deux objets ayant les mmes valeurs, mais un identifiant diffrent, sont considrs comme diffrents. Un objet peut changer de valeur, mais pas didentifiant
(sinon, on change dobjet).
Notion XI.2 : Identifiant dobjet (Object Identifier)
Rfrence systme unique et invariante attribue un objet lors de sa cration permettant de le
dsigner et de le retrouver tout au long de sa vie.

Lidentit dobjet [Khoshafian86] est un concept important : cest la proprit dun

objet qui le distingue logiquement et physiquement des autres objets. Un identifiant
dobjet est en gnral une adresse logique invariante. Lattribution didentifiants

356 BASES DE DONNES : OBJET ET RELATIONNEL

internes invariants dans les bases de donnes objets soppose aux bases de donnes
relationnelles dans lesquelles les donnes (tuples) ne sont identifis que par des
valeurs (cls). Deux objets O1 et O2 sont identiques (on note O1 == O2) sils ont le
mme identifiant ; il ny a alors en fait quun objet dsign par deux pointeurs O1 et
O2. Lidentit dobjet est donc lgalit de pointeurs. Au contraire, deux objets sont
gaux (on note O1 = O2) sils ont mme valeur. O1 == O2 implique O1 = O2,
linverse tant faux.
Lidentit dobjet apporte une plus grande facilit pour modliser des objets complexes ; en particulier, un objet peut rfrencer un autre objet. Ainsi, le vhicule V1
rfrence le moteur M1 et la personne P1 rfrence le vhicule V1. Les graphes peuvent tre directement modliss (voir figure XI.1). Le partage rfrentiel dun sousobjet commun par deux objets devient possible sans duplication de donnes. Par
exemple, une personne P2 { Nom: Dupont; Prnom: Juliette; Age: 22; Voiture: V1 }
peut rfrencer le mme vhicule que la personne P1.
Objet P1
Objet P2

Objet V1

Figure XI.1 : Partage rfrentiel dun objet par deux autres objets

Comme le montre ces exemples, en plus dun identifiant, un objet possde des attributs aussi appels variables dinstance. Un attribut mmorise une valeur ou une
rfrence prcisant une caractristique dun objet. La valeur peut tre lmentaire (un
entier, un rel ou un texte) ou complexe (une structure valeurs multiples). La rfrence correspond un identifiant dun autre objet. Elle permet de pointer vers un autre
objet avec des pointeurs invariants.
Notion XI.3 : Attribut (Attribute)
Caractristique dun objet dsigne par un nom permettant de mmoriser une ou plusieurs valeurs,
ou un ou plusieurs identifiants dobjets.

Le modle objet 357

2.2. ENCAPSULATION DES OBJETS

Au-del dune structure statique permettant de modliser des objets et des liens entre
objets, les modles objets permettent dencapsuler les structures des objets par des
oprations, parfois appeles mthodes (en Smalltalk) ou fonctions membres (en
C++).
Notion XI.4 : Opration (Operation)
Modlisation dune action applicable sur un objet, caractrise par un en-tte appel signature dfinissant son nom, ses paramtres dappel et ses paramtres de retour.

Le terme mthode sera aussi employ pour dsigner une opration. Issu de Smalltalk,
ce concept a cependant une connotation plus proche de limplmentation, cest--dire
que lorsquon dit mthode, on pense aussi au code constituant limplmentation. Quoi
quil en soit, un objet est manipul par les mthodes qui lencapsulent et accd via
celles-ci : le principe dencapsulation hrit des types abstraits cache les structures
de donnes (les attributs) et le code des mthodes en ne laissant visible que les oprations exportes, appeles oprations publiques. Par opposition, les oprations non
exportes sont qualifies de prives. Elles ne sont accessibles que par des mthodes
associes lobjet. Lencapsulation est un concept fondamental qui permet de cacher
un groupe de donnes et un groupe de procdures associes en les fusionnant et en ne
laissant visible que linterface compose des attributs et des oprations publics.
Notion XI.5 : Interface dobjet (Object Interface)
Ensemble des signatures des oprations, y compris les lectures et critures dattributs publics, qui
sont applicables depuis lextrieur sur un objet.

Linterface dun objet contient donc toutes les oprations publiques que peuvent utiliser les clients de lobjet. Pour viter de modifier les clients, une interface ne doit pas
tre change frquemment : elle peut tre enrichie par de nouvelles oprations, mais il
faut viter de changer les signatures des oprations existantes. En consquence, un
objet exporte une interface qui constitue un vritable contrat avec les utilisateurs. Les
attributs privs (non visibles lextrieur) et le code des oprations peuvent tre
modifis, mais changer des oprations de linterface ncessite une reprise des clients.
Ce principe facilite la programmation modulaire et lindpendance des programmes
limplmentation des objets. Par exemple, il est possible de dvelopper une structure
de donnes sous la forme dun tableau, permettant de mmoriser le contenu dun
cran. Cette structure peut tre encapsule dans des oprations de signatures fixes
permettant dafficher, de redimensionner, de saisir des caractres. Le changement du
tableau en liste ncessitera de changer le code des oprations, mais pas linterface, et
donc pas les clients.

358 BASES DE DONNES : OBJET ET RELATIONNEL

En rsum, les oprations et attributs publics constituent linterface dun objet. Ceuxci sont les seuls accessibles lextrieur de limplmentation de lobjet. Le code qui
constitue cette implmentation peut tre structur. Certaines oprations sont alors
invisibles lextrieur de lobjet : elles sont appeles oprations prives. Par
exemple, la saisie dun texte peut seffectuer par plusieurs appels dune mthode saisissant une ligne : la mthode SaisirLigne restera invisible au monde extrieur et seule
la mthode SaisirTexte pourra tre invoque. Dans la suite et afin de simplifier, nous
supposerons que toutes les mthodes dun objet sont publiques. Si nous ne le prcisons pas, les attributs sont publiques. Mettre des attributs publics ne respecte pas trs
bien le principe dencapsulation qui consiste cacher les proprits servant limplmentation. Briser ainsi lencapsulation conduit des difficults si lon veut changer
par exemple le type dun attribut : il faut alors prvenir les clients qui doivent tre
modifis !
Notez quun attribut dun objet peut tre lu par une fonction applique lobjet dlivrant
la valeur de lattribut. Nous noterons cette fonction GetAttribut, o Attribut est le nom
de lattribut considr. Ainsi, lattribut Nom dfinit une fonction GetNom qui, applique
une personne P, dlivre un texte (son nom). La proprit Voiture peut aussi tre lue par
une fonction GetVoiture qui, applique une personne, dlivre lidentifiant de lobjet
constituant son vhicule habituel. Un attribut peut aussi tre crit par une fonction particulire que nous noterons PutAttribut. En rsum, tout attribut dfinit implicitement
deux mthodes (criture : Put, et lecture : Get) qui peuvent tre prives ou publiques,
selon que lattribut est visible ou non lextrieur. Le formalisme unificateur des fonctions est trs puissant, car il permet de raccrocher une mme thorie (les types abstraits) les proprits mmorises (attributs) et calcules (fonctions) dun objet.

2.3. DFINITION DES TYPES DOBJETS

Le concept de type de donnes abstrait est bien connu dans les langages de programmation [Guttag77]. Un type de donnes abstrait peut tre vu comme un ensemble de
fonctions qui cache la reprsentation dun objet et contraint les interactions de lobjet
avec les autres objets. Ainsi, un type de donnes abstrait englobe une reprsentation
cache dun objet et une collection de fonctions abstraites visibles lextrieur. La
dfinition dun type de donnes abstrait correspond la dfinition dune ou plusieurs
interfaces, comme vu ci-dessus. Lemploi de types abstraits favorise la modularit des
programmes car la modification de la structure dun objet naffecte pas les objets
extrieurs qui le manipulent.
Dans les systmes objets, les types abstraits (et donc les interfaces) doivent tre
implments. En gnral, un type abstrait est implment sous la forme dun moule
permettant de dfinir les attributs et les oprations communs associs aux objets crs
selon ce moule. Un tel moule est appel classe.

Le modle objet 359

Notion XI.6 : Classe (Class)

Implmentation dune ou plusieurs interfaces sous la forme dun moule permettant de spcifier un
ensemble de proprits dobjets (attributs et oprations) et de crer des objets possdant ces proprits.

Notez que certains systmes objets sparent la fonction de cration des objets de la
classe : on obtient alors des classes qui sont simplement des implmentations de types
abstraits et lon ajoute des usines objets (Object factory) pour crer les objets.
Chaque classe doit alors avoir son usine, ce qui complique le modle.
Une classe spcifie donc la structure et le comportement communs des objets quelle
permet de crer. Au-del du nouveau type de donnes abstrait ajout lenvironnement par une dfinition de classe, une classe supporte une implmentation : cest le
code des oprations. Elle donne aussi naissance une famille dobjets : on parle alors
de lextension de la classe. Cette extension est une collection dobjets ayant mmes
structure et comportement. La classe est donc un peu lanalogue de la table dans les
bases de donnes relationnelles, bien quune table ne permette que de modliser la
structure commune des tuples qui la composent.
En rsum, le concept de classe est plutt complexe. Par abus de langage, le mot
classe dsigne gnralement une intention (le type abstrait), mais aussi parfois une
extension (la collection des objets membres de la classe), dautre fois une implmentation (la structure des objets et le code des oprations). La spcification progressive
des classes dobjets composant une base de donnes objets permet de modliser le
comportement commun des objets de manire modulaire et extensible. Elle permet
aussi de spcifier les collections contenant les objets ou extensions de classes. La plupart des systmes distinguent lintention de lextension, une classe (ou un type selon
le vocabulaire) pouvant avoir plusieurs extensions.
Du point de vue de la reprsentation dune dfinition de classe, nous utiliserons la
notation prconise par UML [Rational97] et illustre figure XI.2. Nous avons
gauche le cadre gnrique servant reprsenter une classe, droite le cas de la classe
Vin. Chaque attribut a un nom, de mme que chaque opration. Un attribut est typ.
Les oprations peuvent avoir des paramtres, et un type dans le cas de fonctions. Un
attribut ou une opration publics sont prcds de + ; de mme pour une opration.
Nous pouvons maintenant illustrer la notion de classes par quelques exemples. La
syntaxe choisie pour les dfinitions de classe est proche de C++, chaque attribut ou
mthode ayant un type suivi dun nom et dventuels paramtres. Notre premier
exemple (voir Figure XI.3) vise modliser le plan gomtrique sous forme de points.
Pour crer et rassembler les points crs, nous dfinissons une classe comportant deux
attributs, X et Y, de type flottant. Une mthode sans paramtre Distance permet de calculer la distance du point lorigine ; cette mthode retourne un flottant. Une
mthode Translater permet de translater un point dun vecteur fourni en para-

360 BASES DE DONNES : OBJET ET RELATIONNEL

mtre et ne retourne aucun paramtre (void en C++). Une autre mthode Afficher
permet de gnrer un point lumineux sur un cran ; elle ne retourne aucun paramtre.
Classe

Nom

attributs
oprations

Vins
+ Cru : char[20]
+ Millsime : int
- Degr : fixed 5.2
- Quantit: int
+ Produire()
+ Livrer()
+ Int Get_Degr()
+ Set_Degr(degr int)

Illustrations
non
UML

Figure XI.2 : Reprsentation dune classe en UML

Class Point {
Float X;
Float Y;
Float Distance();
Void Translater(Float DX, Float DY);
Void Afficher(); };

Figure XI.3 : La classe point

La figure XI.4 permet de dfinir les classes Vin, Personne et Vhicule dont
quelques objets ont t vus ci-dessus. Les mots cls Public et Private permettent
de prciser si les proprits sont exportes ou non. Par dfaut, il restent cachs dans la
classe, donc privs. Notez que comme en C++, nous dfinissons une rfrence par le
type de lobjet point suivi dune toile (par exemple Vhicule*). Deux mthodes
sont attaches la classe Personne : Vieillir qui permet dincrmenter de 1 lge
dune personne et rend le nouvel ge, Conduire qui permet de changer le vhicule
associ et ne retourne aucun paramtre. Notez que la classe Vhicule rfrence
dautres classes (Constructeur, Propulseur) non dfinies ici.

Le modle objet 361

Class Vin {
Fixed 5.2 degr ;
Int quantit ;
Public :
Char cru [20] ;
Int millsime ;
void Produire()
void Livrer()
Int Get_Degr()
void Set_Degr(Int degr) } ;
Class Personne {
String Nom;
String Prnom;
Int Age;
Vhicule* Voiture;
Public :
Int Vieillir();
Void Conduire(Vhicule V); };
Class Vhicule {
Public :
String Numro;
Constructeur* Marque;
String Type;
Propulseur* Moteur; };

Figure XI.4 : Les classes Vin, Personne et Vhicule

Une opration dfinie dans le corps dune classe sapplique un objet particulier de la
classe. Par exemple, pour translater un point rfrenc par P dun vecteur unit, on
crira PTranslater(1,1). Pour calculer la distance de P lorigine dans une
variable d, on peut crire d = PDistance(). Certaines mthodes peuvent
sappliquer plusieurs objets de classes diffrentes : une telle mthode est dite multiclasse. Elle est en gnral affecte une classe particulire, lautre tant un paramtre.
La possibilit de supporter des mthodes multiclasses est essentielle pour modliser
des associations entre classes sans introduire de classes intermdiaires artificielles.

2.4. LIENS DHRITAGE ENTRE CLASSES

Afin dviter la rptition de toutes les proprits pour chaque classe dobjets et de
modliser la relation est-un entre objets, il est possible de dfinir de nouvelles
classes par affinage de classes plus gnrales. Cette possibilit est importante pour
faciliter la dfinition des classes dobjets. Le principe est daffiner une classe plus

362 BASES DE DONNES : OBJET ET RELATIONNEL

gnrale pour obtenir une classe plus spcifique. On peut aussi procder par mise en
facteur des proprits communes diffrentes classes afin de dfinir une classe plus
gnrale. La notion de gnralisation ainsi introduite est emprunte aux modles
smantiques de donnes [Hammer81, Bouzeghoub85].
Notion XI.7 : Gnralisation (Generalization)
Lien hirarchique entre deux classes spcifiant que les objets de la classe suprieure sont plus gnraux que ceux de la classe infrieure.

La classe infrieure est appele sous-classe ou classe drive. La classe suprieure

est appele super-classe ou classe de base. Le parcours du lien de la super-classe vers
la sous-classe correspond une spcialisation, qui est donc linverse de la gnralisation. Une sous-classe reprend les proprits (attributs et mthodes) des classes plus
gnrales. Cette facult est appele hritage.
Notion XI.8 : Hritage (Inheritance)
Transmission automatique des proprits dune classe de base vers une sous-classe.

Il existe diffrentes smantiques de la gnralisation et de lhritage, qui sont deux

concepts associs [Cardelli84, Lcluse89]. La plus courante consiste dire que tout
lment dune sous-classe est lment de la classe plus gnrale : il hrite ce titre
des proprits de la classe suprieure. La relation de gnralisation est alors une relation dinclusion. Bien que reprenant les proprits de la classe suprieure, la classe
infrieure possde en gnral des proprits supplmentaires : des mthodes ou attributs sont ajouts.
Le concept de gnralisation permet de dfinir un graphe de gnralisation entre
classes. Les nuds du graphe sont les classes et un arc relie une classe C2 une classe
C1 si C1 est une gnralisation de C2. Le graphe dont les arcs sont orients en sens
inverse est appel graphe dhritage. La figure XI.5 illustre un graphe de gnralisation entre les classes Personne, Employ, Cadre, NonCadre et Buveur. Les
dfinitions de classes correspondantes dans un langage proche de C++ apparaissent
figure XI.6. Les super-classes dune classe sont dfinies aprs la dclaration de la
classe suivie de : . chaque classe est associ un groupe de proprits dfini au
niveau de la classe. Les classes de niveaux infrieurs hritent donc des proprits des
classes de niveaux suprieurs.

Le modle objet 363

Personne
- nss
- nom
- prnom
- ge
- photo*
+ vieillir()

Employ

Buveur

- profession
- lieu de travail
- salaire
- primes

- tat
- abus
+ boire()
+ dormir()

+ travailler()

Cadre
+ travailler()

Non cadre

Figure XI.5 : Exemple de graphe de gnralisation

Class Personne {
Int nss ;
String nom ;
String prenom ;
Int age ;
Image* photo ;
Public :
Int vieillir() ; }
Class Employ : Personne {
String profession ;
String lieudetravail ;
Double salaire ;
Double primes ;
Public :
void travailler() ; }
Class Buveur : Personne {
Enum etat (Normal, Ivre) ;
List <consommation> abus ;
Public :
Int boire() ;
void dormir() ; }

364 MATRISER LES BASES DE DONNES

Class Cadre : Employ {

Public :
void travailler() ; }
Class NonCadre : Employ {
}

Figure XI.6 : Dfinition des classes de la figure prcdente

Afin daugmenter la puissance de modlisation du modle, il est souhaitable quune

classe puisse hriter des proprits de plusieurs autres classes. Lhritage multiple
permet une classe de possder plusieurs super-classes immdiates.
Notion XI.9 : Hritage multiple (Multiple Inheritance)
Type dhritage dans lequel une classe drive hrite de plusieurs classes de niveau immdiatement
suprieur.

Dans ce cas, la sous-classe hrite des proprits et oprations de toutes ses superclasses. Lhritage multiple permet de dfinir des classes intersection comme dans la
figure XI.7, o les EmploysBuveurs hritent la fois des Buveurs et des Employs.
Ils hritent certes dun seul nom provenant de la racine Personne.

Employ

Buveur

- profession
- lieu de travail
- salaire
- primes

- tat
- abus
+ boire
+ dormir

+ travailler()

EmployBuveur
+BoireTravailler()

Figure XI.7 : Exemple dhritage multiple

Des conflits de noms dattributs ou doprations peuvent survenir en cas dhritage

multiple. Plusieurs solutions sont possibles. En particulier, un choix peut tre effectu
par lutilisateur de manire statique la dfinition, ou de manire dynamique pour
chaque objet. Il est aussi possible de prfixer les noms de proprits ou mthodes
hrites par le nom de la classe o elles ont t dfinies, cela bien sr dans le seul cas

Le modle objet 365

dambigut de noms. Enfin, un choix automatique peut tre fait par le systme, par
exemple le premier gauche. Dans lexemple de la figure XI.8, les triangles rectangles isocles vont hriter de trois fonctions de calcul de surface. Deux dentres
elles sont identiques et proviennent de lopration surface associe aux triangles. Il
faut pouvoir choisir parmi les deux restantes, soit en conservant les deux en les
renommant polygone_surface et triangle_surface, soit en en slectionnant une, par exemple la premire gauche, donc celle des polygones droits.
Triangle
+Surface

PolygoneDroit
+Surface()

TriangleIsocle

TriangleRectangle

TriangleRectangleIsocle

Figure XI.8 : Exemple de conflit de noms

Dire quune classe C1 est plus gnrale quune classe C2 permet de dfinir une relation dordre C2 C1, qui reprsente le fait que les instances de C2 sont incluses dans
celles de C1. Cette relation dordre correspond donc une inclusion au niveau des
ensembles dobjets. La relation dordre ainsi dfinie permet de considrer le treillis
des classes. Ce treillis possde en gnral un plus grand lment qui est la classe
dnomme Objet (Object) ; cette classe apparat alors comme la racine de la hirarchie dhritage qui fournit toutes les mthodes de base de manipulation des objets,
mthodes hrites par toutes les autres classes. La hirarchie des types et lhritage de
proprits ont t formellement tudis dans le contexte des types abstraits sous forme
de sigma-algbres [Guogen78], et plus rcemment dans le contexte de la programmation objet [Castagna96].

2.5. POLYMORPHISME, REDFINITION ET SURCHARGE

Lors de la dfinition dune hirarchie de classes, certaines proprits peuvent tre spcifies diffremment pour chaque sous-classe. Lide est de modliser dans une sous-

366 BASES DE DONNES : OBJET ET RELATIONNEL

classe une fonctionnalit similaire de mme signature dopration, mais avec un code
diffrent. On parle alors de redfinition.
Notion XI.10 : Redfinition (Overriding)
Spcification dune mthode existante dans une super-classe au niveau dune sous-classe, avec une
implmentation diffrente.

Par exemple, une mthode globale telle que Travailler peut tre spcifie au
niveau de la classe Employ, puis redfinie de manire spcifique au niveau de la
classe Cadre. En effet, la mthode Travailler de la classe Employ pourra tre
redfinie par un code correspondant un travail de direction au niveau de la classe
Cadre. Il est mme possible de ne pas dfinir le code de lopration au niveau dune
classe et dimposer de le dfinir au niveau des sous-classes : on parle alors de
mthode virtuelle au niveau de la super-classe.
Pour une mme classe, il est aussi possible de dfinir plusieurs implmentations pour
une mme opration. Chacune delle sera alors distingue par des paramtres diffrents. Ceci correspond la notion de surcharge.
Notion XI.11 : Surchage (Overloading)
Possibilit de dfinir plusieurs codes pour une mme opration dune classe, le code appropri
tant slectionn selon le type des paramtres fournis lors dun appel.

La possibilit de surcharge rend ncessaire le choix du code dune mthode en fonction de ses arguments. Cette possibilit est dailleurs gnralise : une opration dun
nom donn peut avoir diffrentes signatures; un code est alors attach chaque signature. Par exemple, au niveau de la classe Personne, il est possible de dfinir plusieurs mthodes Vieillir, lune sans paramtre ajoutant un lge, lautre avec un
paramtre indiquant le nombre dannes ajouter. Chaque signature aura alors un
code spcifique. Cette possibilit est souvent utilise pour grer des valeurs par dfaut
de paramtres.
Redfinition et surcharge sont deux formes de polymorphisme. Cette fonctionnalit
importante peut tre dfinie comme suit :
Notion XI.12 : Polymorphisme (Polymorphism)
Facult pour une opration davoir diffrentes signatures avec un code spcifique attach chaque
signature.

Le polymorphisme permet donc une mme opration de sappliquer des objets de

diffrentes classes ou des objets dune mme classe. Dans ce dernier cas, les paramtres de lopration doivent tre de types diffrents. En particulier, certains peuvent
ne pas exister.

Le modle objet 367

Par exemple, la mthode Travailler() peut tre applique un objet de type

Cadre ou NonCadre sans argument. Une mthode Travailler(Int Dure)
pourra tre dfinie au niveau des NonCadre. Lors dun appel de la mthode
Travailler du type PTravailler() ou PTravailler(10) (P rfrence une personne particulire), un code diffrent sera excut, selon que P est un
cadre ou non, et selon quun paramtre est pass ou non pour un non cadre.
Le polymorphisme (tymologiquement, la facult de possder plusieurs formes) est
une fonctionnalit volue qui implique en gnral le choix du code de la mthode
lexcution (lorsque le type des paramtres est connu). Ce mcanisme est appel liaison dynamique (en anglais, dynamic binding).

2.6. DFINITION DES COLLECTIONS DOBJETS

Certains attributs peuvent tre multivalus. Par exemple, un livre peut avoir plusieurs
auteurs. Un texte est compos de plusieurs paragraphes. Il est donc souhaitable de
pouvoir regrouper plusieurs objets pour former un seul attribut. Ceci seffectue gnralement au moyen de classes gnriques permettant de supporter des collections
dobjets.
Notion XI.13 : Collection (Collection)
Container typ dsign par un nom, contenant des lments multiples organiss selon une structure
particulire, auxquels on accde par des oprations spcifiques au type du container.

Les principales collections sont :

lensemble (Set) qui permet de dfinir des collections non ordonnes sans double ;
le sac (Bag) qui permet de dfinir des collections non ordonnes avec doubles;
la liste (List) qui permet de dfinir des collections ordonnes avec doubles ;
le tableau (Array) qui permet de dfinir des collections ordonnes et indexes.
Dautres sont utilises, par exemple la pile, le tableau insrable o il est possible
dinsrer un lment une position donne, etc. Les lments rangs dans les collections sont en gnral des objets ou des valeurs. Par exemple {10, 20, 30, 75} est un
ensemble dentiers ; <O1, O5, O9> o les Oi reprsentent des objets est une liste
dobjets.
Dans les systmes objet, la notion de collection est souvent ralise par des classes
paramtres, encore appeles classes gnriques ou patterns de classes.
Notion XI.14 : Classe paramtre (Template)
Classe avec paramtres typs et ayant diffrentes implmentations selon le type de ces paramtres.

368 BASES DE DONNES : OBJET ET RELATIONNEL

La gnration des implmentations selon le type des paramtres est gnralement la

charge du compilateur du langage objet de dfinition de classe paramtre. Lintrt
dutiliser des classes paramtres est la facilit de rutilisation, dans des contextes diffrents selon les paramtres. Linconvnient est souvent laccroissement de la taille du
code gnr.
Une classe paramtre est donc une classe possdant un ou plusieurs paramtres ;
dans le cas des collections, le paramtre sera souvent le type des objets de la collection. La collection doit donc tre homogne. Elle apparat son tour comme une
classe. Par exemple List<X> et Set<X> sont des collections, respectivement des
listes et des ensembles dobjets de type X. Set<Int> est un ensemble dentiers alors
que List<Vin> est une liste de vins. List<X> et Set<X> sont des classes paramtres. List<Vin> tant une classe, Set<List<Vin>> est un type de collection
valide. Les collections permettent donc de construire des objets complexes par imbrications successives de classes. Par exemple, { <V1, V5, V7>, <V3, V2, V1>, <V4,
V7>, <>} est une collection de type Set<List<Vin>>.
Dans la plupart des modles objets, les collections sont des classes dobjets gnriques qui offrent des mthodes daccs spcifiques (par exemple, le parcours dune
liste ou dun ensemble). Elles peuvent tre organises en hirarchie de gnralisation. La figure XI.9 illustre une bibliothque de classes gnriques de type collections avec, pour chacune, des mthodes caractristiques [Gardarin94]. Outre les
mthodes dinsertion, suppression et obtention dun lment, la classe Collection
offre des mthodes de second ordre travaillant sur plusieurs objets dune collection ;
Count compte le nombre dobjets, Apply applique une fonction passe en paramtre chaque objet et Aggregate calcule une fonction dagrgat passe en paramtre (par exemple, somme ou moyenne). Search recherche un lment donn, par
exemple par une cl. Les oprations des sous-classes sont classiques. Par exemple,
First et Next permettent le parcours de liste, Tail extrait la sous-liste aprs
llment courant et Append ajoute un lment. Dautres fonctions peuvent tre
envisages.
On crira par exemple Array<Vhicule> pour spcifier un tableau de Vhicules
de dimension variable. Notez que la plupart des langages orients objets supportent
des tableaux de dimension fixe par la notation C[N], o C est une classe et N un
entier. Par exemple, Vhicule[4] dfinit un tableau de 4 vhicules. Comme cela a
dj t dit, il est possible dimbriquer des collections. Lexemple de la figure XI.10
montre comment on peut grer des listes de tableau afin de structurer intelligemment
un texte. Celui-ci est compos dune liste de paragraphes, chacun ayant un thme, des
dtails structurs sous forme dune liste de phrases, et une conclusion. Thme et
conclusion sont des phrases. Une phrase est une liste de mots modliss par des
tableaux de caractres.

Le modle objet 369

Collection
Insert
Delete
Get
IsEmpty
Count
Apply
Aggregate
Search

Set
Include
Choice
All
Exist
Union
Intersection

List

Array

First
Next
Last
Tail
Append

Put[i]
Get[i]
Extract[i,j]

Figure XI.9 : Exemple de bibliothque de collections avec oprations

class Phrase {
List <Array <char>> Squence; };
class Paragraphe {
Phrase Thme;
List <Phrase> Dtails;
Phrase Conclusion; };
class Texte {
List <Paragraphe*> Contenu; };

Figure XI.10 : Utilisation de collections imbriques

Lexistence de collections imbriques traduit le fait que certains objets sont inclus
dans dautres. Il sagit en fait dune reprsentation de la relation dagrgation entre
classes.
Notion XI.15 : Agrgation (Aggregation)
Association entre deux classes exprimant que les objets de la classe cible sont des composants de
ceux de la classe source.

Lagrgation traduit la relation fait partie de ; par exemple, les caractres font partie de la phrase. Les collections permettent dimplmenter les agrgations multiva-

370 BASES DE DONNES : OBJET ET RELATIONNEL

lues. Lagrgation peut tre implmente par une rfrence (par exemple
List<Paragraphe*>) ou par une imbrication, selon que lon dsire ou non partager
les objets inclus. La reprsentation des agrgations par un graphe permet de visualiser le
processus de construction des objets complexes. La figure XI.11 reprsente le graphe
dagrgation, encore appel graphe de composition, de la classe Texte. Les cardinalits
multiples sont mentionnes par des toiles (*), conformment la notation UML
[Rational97].
Texte

Contenu

*
Paragraphe

Thme

*
Dtails

Conclusion

Phrase

Squence

*
Char

Figure XI.11 : Graphe dagrgation de la classe Texte

2.7. PRISE EN COMPTE DE LA DYNAMIQUE

Dans les environnements objets, les objets communiquent entre eux par des messages comportant le nom dune mthode et ses paramtres. Un objet reoit un message et ragit un message. Lenvoi de messages est en fait une implmentation
flexible et contrle de lappel de procdure par valeur classique des langages de programmation. Cest un lment important des langages objet qui permet de raliser le
polymorphisme lors de linterprtation du message.
Notion XI.16 : Message (Message)
Bloc de paramtres compos dun objet rcepteur, dun nom doprations et de paramtres, permettant par envoi linvocation de lopration publique de lobjet rcepteur.

Le modle objet 371

Ainsi, un objet ragit un message en slectionnant le code de la mthode associe

selon le nom de la mthode et le type des paramtres, ralisant ainsi le polymorphisme. Il retourne les paramtres rsultats de lopration. Une base de donnes
objets ou un programme structur en objets apparat donc comme un ensemble
dobjets vivants qui communiquent par des messages. Un dispatcher de messages fait
transiter les messages entre les objets et assure leur bonne dlivrance. Un nouveau
graphe peut tre construit dynamiquement, le graphe des appels de mthodes, qui
permet de visualiser quelle mthode a appel quelle autre mthode.
Un message peut tre envoy un objet dsign par son identifiant en utilisant le
slecteur de proprit dnot , dj vu ci-dessus. Par exemple, un point dfini
comme figure XI.3, rfrenc par P, pourra recevoir les messages :
PDistance();
PTranslater(10,10);
PAfficher().
Le dispatcher du message activera le code de lopration slectionne en effectuant le
passage de paramtre par valeur.

2.8. SCHMA DE BASES DE DONNES OBJETS

partir des outils et concepts introduits ci-dessus, une base de donnes objets peut
tre dcrite. La description seffectue par spcification dun schma de classes compos de dfinitions de classes, chacune delles comportant des attributs (ventuellement organiss en collections) et des oprations. Parmi les classes, certaines sont plus
gnrales que dautres, comme spcifi par le graphe de gnralisation. La
figure XI.12 reprsente le schma partiel dune base de donnes objets dont dautres
lments ont t introduits ci-dessus. Le graphe de rfrence entre classes correspondant est reprsent figure XI.14
Notion XI.17 : Schma de BD objet (Object DB Schema)
Description dune base de donnes objets particulire incluant les dfinitions de classes, dattributs et doprations ainsi que les liens entre classes.

Les agrgations, cas particuliers dassociations, sont bien sr reprsentes. Un schma

de BD objet est donc un schma objet gnral. Il pourra en plus inclure les directions
de traverse des associations, afin de faciliter le passage des rfrences entre objets
au niveau de limplmentation. La figure XI.12 reprsente un schma de BD objet
sous une forme proche de la notation UML ; la figure XI.13 en donne une vue selon
une syntaxe proche de C++.

372 BASES DE DONNES : OBJET ET RELATIONNEL

Personne

Employ

Buveur

Boire
Abus

Vin

BuPar
Date
Quantit

Reprsentation
Figure

Caricature
sourire()
pleurer()

Reprsente

Tte

ilD

Nez
Bouche

Forme

ilG

*
Point

Cercle
Centre
- Rayon

-x
-y

Figure XI.12 : Schma graphique partiel de la base exemple

Class Vin {
public:
Char Cru[20] ;
Int Mill ;
Double Degr ; }
Class Buveur {
private:
Enum Etat (Normal, Ivre) ;
public:
Char Nom[15] ;
Char Prnom[15] ;
List <Date Jour, Vin* Boisson, Int Quantit> Abus ;
Caricature* Reprsentation ;
// opration sur buveur
void Boire (Date d, Vin* v, Int q) ;
void Dormir (Int dure); }
Class Caricature {
Cercle* Tte ;
Cercle* OeilD ;
Cercle* OeillG ;
Figure* Nez ;

Le modle objet 373

Figure* Bouche ;
// operations sur personnage
void Sourire () ;
void Pleurer () ;
Graphic Dessiner (Int Echelle) ; }
Class Cercle {
Point Centre ;
Double Rayon ; }
Class Figure {
List <Point> Forme ; }

Figure XI.13 : Dfinition C++ dune partie de la base exemple

Soulignons quun schma de classes modlise la fois la structure (les attributs des
classes) et le comportement (les mthodes) des objets. La dfinition complte dune
base de donnes objets ncessite donc un langage de programmation afin de spcifier le code des programmes. Ce langage est un langage orient objet, du type
Smalltalk, ou de plus en plus souvent C++ ou Java.

3. LA PERSISTANCE DES OBJETS

Aprs avoir prcis le concept de base de donnes objets, cette section tudie les
diverses techniques utilises pour raliser la persistance des objets ncessaire
lapproche base de donnes. La dernire partie montre comment on navigue dans une
base de donnes objets depuis un langage orient objet tel C++.

3.1. QUEST-CE-QUUNE BD OBJETS ?

La notion de bases de donnes objets sest prcise au dbut des annes 90. Nous
avons introduit ci-dessus les concepts essentiels de la modlisation oriente objet, tels
quils sont implments dans des langages objet Smalltalk, C++ ou Java. partir de
l, le concept de base de donnes objets slabore en ajoutant la persistance. La
notion de systme de base de donnes objets tant au dpart trs confuse, Atkinson,
Bancilhon, Dewitt, Ditrich, Maier et Zdonick ont propos de la clarifier dans une
publication la confrence DOOD (Deductive and Object-Oriented Databases) en
1989, intitule The Object-Oriented Manifesto [Atkinson89].
Pour mriter le nom de SGBD objet (SGBDO), un systme doit dabord supporter les
fonctionnalits dun SGBD. Pour ce faire, il doit obligatoirement assurer :

374 BASES DE DONNES : OBJET ET RELATIONNEL

La persistance des objets. Tout objet doit pouvoir persister sur disque au-del du
programme qui le cre. Un objet peut tre persistant ou transient. Dans le
deuxime cas, sa dure de vie est au plus gale celle du programme qui le cre ; il
sagit dun objet temporaire qui reste en mmoire.
Notion XI.18 : Objet persistant (Persistent object)
Objet stock dans la base de donnes dont la dure de vie est suprieure au programme qui le
cre.
Notion XI.19 : Objet transient (Transient object)
Objet restant en mmoire, dont la dure de vie ne dpasse pas celle du programme qui le cre.

La concurrence daccs. La base dobjets doit pouvoir tre partage simultanment

par les transactions qui la consultent et la modifient ; les blocages doivent tre minimaux afin dassurer la cohrence de la base.
La fiabilit des objets. Les objets doivent tre restaurs en cas de panne dun programme dans ltat o ils taient avant la panne. Les transactions doivent tre atomiques, cest--dire totalement excutes ou pas du tout.
La facilit dinterrogation. Il doit tre possible de retrouver un objet partir de
valeurs de ses proprits, quil sagisse de valeurs dattributs, de rsultats de
mthodes appliques lobjet ou de liens avec les objets rfrencs ou rfrenants.
Le manifesto propose en outre des fonctionnalits bases de donnes optionnelles :
La distribution des objets. Cette facilit permet de grer des objets sur diffrents
sites, en particulier sur un serveur et des clients.
Les modles de transaction volus. Il sagit de supporter des transactions imbriques, cest--dire elles-mmes dcomposes en sous-transactions qui peuvent tre
totalement reprises.
Les versions dobjets. La gestion de versions permet de revenir un tat antrieur
de lobjet avant modification. partir dun objet, plusieurs versions peuvent tre
cres par des modifications successives ou parallles. On aboutit ainsi un graphe
des versions dun objet qui peut tre gr par le systme. Il est alors possible de
remonter aux versions prcdentes partir des dernires versions et vice versa. Si
plusieurs versions sont cres en parallle, une fusion avec possibilit de choisir
certaines modifications est ultrieurement ncessaire. Un objet pouvant possder
des versions est appel objet versionnable.
Notion XI.20 : Objet versions (Versionnable object)
Objet dont lhistorique des instances cres (successivement ou simultanment) est gard dans la
base sous forme de versions consultables et modifiables.

Le modle objet 375

Outre les fonctionnalits orientes bases de donnes dfinies ci-dessus, le

manifesto prescrit les fonctionnalits orientes objets que doit supporter un SGBDO.
Sont obligatoires :
Le support dobjets atomiques et complexes. Il sagit de supporter des objets
avec des attributs rfrences et des collections imbriques.
Lidentit dobjets. Tout objet doit avoir un identifiant systme invariant, permettant de le retrouver sur disque et en mmoire.
Lhritage simple. Une classe doit pouvoir tre une spcialisation dune autre
classe et hriter de celle-ci.
Le polymorphisme. Le code dune mthode doit tre choisi en fonction de ses
paramtres instancis.
Deux fonctionnalits sont optionnelles :
Lhritage multiple. Il permet quune sous-classe soit la spcialisation directe de
deux sur-classes ou plus. Elle hrite alors de toutes ses sur-classes.
Les messages dexception. Il sagit dun mcanisme de traitement derreur analogue celui introduit en C++ ou en Java. Lorsquune erreur survient dans une
mthode, un message dexception est lev. Il peut tre repris par un traitement
derreur insr par exemple dans un bloc de reprise, par une syntaxe du type : try
<traitement normal> catch <exception : traitement
derreur>.
En rsum, le manifesto essaie de dfinir prcisment ce quest une base de donnes
objets. Sil a apport en son temps une clarification, il manque aujourdhui de prcision, si bien quun SGBD objet-relationnel, cest--dire un SGBD relationnel tendu
avec des types abstraits, peut souvent tre class comme un SGBDO. Il prsente aussi
un peu darbitraire dans la slection de fonctionnalits, notamment au niveau des
options.

3.2. GESTION DE LA PERSISTANCE

Un modle de donnes orient objet permet de dfinir les types des objets. Dans les
environnements de programmation, les objets doivent tre construits et dtruits en
mmoire par deux fonctions spcifiques, appeles constructeur et destructeur.
Notion XI.21 : Constructeur dobjet (Object constructor)
Fonction associe une classe permettant la cration et linitialisation dun objet en mmoire.
Notion XI.22 : Destructeur dobjet (Object destructor)
Fonction associe une classe permettant la destruction dun objet en mmoire.

376 BASES DE DONNES : OBJET ET RELATIONNEL

En C++ ou en Java, le constructeur dun objet est une fonction membre de la classe. Il
fait en gnral appel une fonction de rservation de mmoire et des fonctions
dinitialisation. Les constructeurs sont normalement dfinis par le programmeur, mais
C++ et Java insrent un constructeur minimal dans les classes qui nen possdent pas.
Le nom du constructeur est le nom de la classe. Par exemple, un point origine pourra
tre dfini comme suit :
Point Origine(0,0).

Le compilateur gnre alors automatiquement lappel au constructeur Point(0,0) lors

de la rencontre de cette dclaration.
En C++, le destructeur est une fonction membre note par le nom de la classe prcd
de ~ ou appel explicitement par delete. Par exemple, la destruction de lorigine
seffectue par:
~Point(0,0).

Le destructeur libre la place mmoire associe lobjet. Il peut tre fourni par le programmeur. Certains langages orients objet tels Java et Smalltalk sont munis dun
ramasse-miettes dtruisant automatiquement les objets non rfrencs, si bien que le
programmeur na pas se soucier dappeler le destructeur dobjets.
Le problme qui se pose dans les SGBDO est dassurer la persistance des objets sur
disques pour pouvoir les retrouver ultrieurement. En effet, constructeur et destructeur
dobjets ne font que construire et dtruire les objets en mmoire. Une solution couramment retenue pour sauvegarder les objets sur disques consiste donner un nom
chaque objet persistant et fournir une fonction permettant de faire persister un objet
pralablement construit en mmoire. Cette fonction peut tre intgre ou non au
constructeur dobjet. Sa signature pourra tre la suivante :
// Rendre persistant et nommer un objet point.
Oid = Persist(<Nom>, <Ref>);

Nom est le nom attribu lobjet qui permettra ultrieurement de le retrouver (dans le
mme programme ou dans un autre programme). Ref est la rfrence en mmoire de
lobjet. Oid est lidentifiant attribu lobjet dans la base par le SGBDO.
Un objet persistant pourra ensuite tre retrouv partir de son nom, puis mont en
mmoire partir de son identifiant dobjet (adresse invariante sur disque). On trouvera
donc deux fonctions plus ou moins caches au programmeur dans les SGBD objets :
// Retrouver loid dun objet persistant partir du nom.
Oid = Lookup(<Nom>);

// Activer un objet persistant dsign par son oid.

Ref = Activate(<Oid>);

Un objet actif en mmoire pourra tre dsactiv (rcriture sur disque et libration de
la mmoire) par une fonction du style:

Le modle objet 377

// Dsactiver un objet persistant actif.

Oid = DesActivate(<Ref>);

Finalement, il sera aussi possible de rendre non persistant (dtruire) dans la base un
objet persistant partir de son identifiant dobjet ou de son nom, en utilisant lune des
fonctions suivantes :
// Supprimer un objet persistant dsign par son nom
Void UnPersist(<Nom>);

// Supprimer un objet persistant dsign par son identifiant

Void UnPersist(<Oid>);

Une telle bibliothque de fonction peut tre utilise directement par le programmeur
dans un langage orient objet comme C++ ou Java pour grer manuellement la persistance des objets. De plus, des fonctions de gestion de transactions devront tre intgres afin dassurer les critures disques, la gestion de concurrence et de fiabilit. Les
critures peuvent tre explicites par une fonction Put ou implicites lors de la validation, en fin de transaction. Un tel systme est voisin de celui offert par Objective-C
pour la persistance des objets dans des fichiers. Il constitue un niveau minimal de
fonctionnalits ncessaire la gestion de la persistance que nous qualifierons de persistance manuelle. Ce niveau de fonctions peut tre cach au programmeur du
SGBDO par lune des techniques tudies ci-dessous.
Dans tous les cas, un problme qui se pose lors de lcriture dun objet dans la base
est la sauvegarde des pointeurs vers les autres objets persistants. Comme lors de
lactivation dun objet persistant, il faut restaurer les pointeurs en mmoire vers les
autres objets actifs. Des solutions sont proposes par chacune des techniques de persistance dcrites ci-dessous. Notez que les systmes implmentent parfois des techniques de persistance mixtes, qui empruntent un peu aux deux dcrites ci-dessous.

3.3. PERSISTANCE PAR HRITAGE

La persistance par hritage permet de cacher plus ou moins compltement au programmeur les mouvements dobjets entre la base et la mmoire. Lide est de profiter
de lhritage pour assurer la persistance automatiquement. Le systme offre alors une
classe racine des objets persistants, nomme par exemple PObject (voir
figure XI.14). Cette classe intgre au constructeur et destructeur dobjets des appels
aux fonctions Persist et Unpersist vues ci-dessus. Ainsi, tout objet appartenant une classe qui hrite de PObject est persistant. En effet, il hrite du
constructeur dobjet qui le rend persistant. Il sera dtruit sur disque par le destructeur,
qui fait appel la fonction Unpersist. La qualit dtre persistant ou non dpend
alors du type de lobjet : un objet est persistant si et seulement sil est du type dune
sous-classe de PObject. On dit alors que la persistance nest pas orthogonale au
type.

378 BASES DE DONNES : OBJET ET RELATIONNEL

Objet
New
Delete

Pobjet
New {Persist}
Delete {Unpersist}
operator

Classes dobjets
transients

Classesdobjets
persistants

Figure XI.14 : Persistance par hritage

Outre les constructeurs et destructeurs destins grer lobjet sur disque, la technique
de persistance par hritage surcharge en gnral le parcours de rfrence (oprateur
en C++). Cela permet dactiver automatiquement un objet point par un objet dj
actif lors du premier parcours de la rfrence, en utilisant une technique de mutation
de pointeur, comme nous le verrons ci-dessous.
En rsum, nous dfinirons la persistance par hritage comme suit :
Notion XI.23 : Persistance par hritage (Persistance by inheritance)
Technique permettant de dfinir la qualit dun objet tre persistant par hritage dune classe
racine de persistance, rendant invisible lactivation et la dsactivation des objets.

Cette technique prsente lavantage dtre simple raliser. Cependant, elle nassure
pas lorthogonalit de la persistance aux types de donnes, si bien que tout type ne
peut pas persister. Si lon veut avoir dans une mme classe des objets persistants et
transients (par exemple des personnes persistantes et des personnes transientes), on est
conduit dupliquer les classes. Ceci peut tre vit en marquant les objets non persistants dune classe persistante simplement par un boolen. La performance de la technique de persistance par hritage est discute, la surcharge des oprateurs (constructeurs et parcours de rfrences) pouvant tre coteuse.

3.4. PERSISTANCE PAR RFRENCE

Une autre technique possible pour cacher les mouvements dobjets est la persistance
par rfrence. Lide est que tout objet ou variable peut tre une racine de persistance

Le modle objet 379

condition dtre dclar comme tel, puis que tout objet point par un objet persistant
est persistant (voir figure XI.15). En gnral, les objets persistants sont les objets
nomms, nom et persistance tant dclars dans la mme commande de cration
dobjet persistant. Cela conduit ajouter un mot cl persistant ou db au langage de programmation (par exemple C++) et donc ncessite un prcompilateur qui
gnre les appels aux fonctions Persist, Unpersist, Activate, etc. Par
exemple, un employ pourra tre cr persistant par la dclaration :
Employe* emp = new persistant Employe(Toto);
De mme, une simple variable x pourra tre rendue persistante par la dclaration :
persistant int x;
Au vu de ces dclarations, le prcompilateur gnrera les commandes de persistance
et de recherche ncessaires. Tout objet racine de persistance (donc dclar persistant)
sera rpertori dans un catalogue o lon retrouvera son nom et son oid.
Catalogue
toto
lulu
x 7
adresse

.
.
.

voiture

moteur

garage

Figure XI.15 : Persistance par rfrence

Tout objet rfrenc par un objet persistant sera persistant. L encore, le pr-compilateur devra assurer la gnration des appels aux fonctions de persistance lors des assignations ou des parcours de rfrences. Les rfrences devront aussi tre rendues persistantes par lune des techniques que nous allons tudier ci-dessous.
En rsum, nous dfinirons la persistance par rfrence comme suit :

380 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XI.24 : Persistance par rfrence (Persistence by reference)

Technique permettant de dfinir la qualit dun objet tre persistant par attribution dun nom (pour
les racines de persistance) ou par le fait quil soit rfrenc par un objet persistant.

Cette technique prsente lavantage de lorthogonalit de la persistance au type de

donnes, si bien que toute donne peut tre rendue persistante. Elle permet de grer
des graphes dobjets persistants. Ainsi, un arbre dobjet est rendu persistant simplement en nommant la racine. Il est rendu transient en supprimant ce nom.

3.5. NAVIGATION DANS UNE BASE DOBJETS

Quelle que soit la technique de persistance, les objets persistants se rfrencent, et il
faut pouvoir retrouver un objet puis naviguer vers les objets rfrencs.
Notion XI.25 : Navigation entre objets (Object navigation)
Parcours dans une base dobjets par suivi de pointeurs entre objets.

Dans les langages objet comme C++, la navigation seffectue en mmoire par simple
dcodage de pointeurs. Dans une base dobjets, les choses ne sont pas aussi simples :
un objet pointant sur un autre objet est en effet crit dans la base, puis relu par un
autre programme plus tard. Lobjet point nest alors plus prsent en mmoire (voir
figure XI.16). Le problme soulev est donc de mmoriser de manire persistante les
chanages dobjets sur disques, puis de les dcoder en mmoire de manire efficace.
Toto

VoitureToto

Vhicule*

Peugeot

Toto

Mmoire

Pointeur invalide
Disque

Vhicule*

Figure XI.16 : Ncessit de mettre jour les pointeurs en mmoire

En rsum, il faut pouvoir utiliser des identifiants dobjets comme des pointeurs sur
disques et des adresses en mmoire. Le passage dun type de pointeur lautre est
appel mutation de pointeurs.
Notion XI.26 : Mutation de pointeurs (Pointer swizzling)
Transformation consistant passer de pointeurs disques des pointeurs mmoire lors de la premire navigation en mmoire via un objet et inversement lors de la dernire.

Le modle objet 381

La mutation de pointeurs disques sous forme didentifiants pointeurs en mmoire

peut seffectuer par diffrentes techniques : utilisation de doubles pointeurs ou utilisation de mmoire virtuelle.
Lutilisation de doubles pointeurs consiste remplacer les rfrences mmoire par
des couples <oid-ref> (voir figure XI.17). Lors du chargement dun objet, toutes les
parties ref des couples sont mises 0. Lors du parcours dune rfrence (oprateur ),
si la partie ref est 0, lobjet rfrenc est activ partir de son oid et la rfrence
est ensuite charge avec ladresse de lobjet en mmoire. Lors des accs suivants,
ladresse mmoire est directement utilise. Ainsi, un objet rfrenc par un objet actif
(par exemple retrouv par lookup) est activ automatiquement lors de la premire
traverse du pointeur rfrenant.
Objet
Mmoire

PREF

REF
OID

Disques
En criture
si OID = NUL ALORS {OID = AllouerBD(Objet) ; Ecrire (REF, OID) } ;
En lecture
si REF = NUL ALORS {REF = AllouerMC(Objet) ; Lire (OID, REF) } ;

Figure XI.17 : Lutilisation de doubles pointeurs

La technique de mmoire virtuelle consiste avoir les mmes adresses en mmoire

centrale et sur disques. Elle a t propose et brevete par Object Design, le fabricant
du SGBDO ObjectStore. Une rfrence est une adresse mmoire virtuelle, cette dernire contenant une image exacte de la base de donnes (ou dune partition de la
base). Lors de la lecture dun objet, ladresse mmoire virtuelle composant toute rfrence est force sur une page manquante si lobjet rfrenc nest pas en mmoire. La
page manquante est rserve en mmoire et marque inaccessible en lecture et en
criture. Ainsi, lors de la traverse du pointeur, une violation mmoire virtuelle en
lecture est dclenche et rcupre par le SGBDO (voir figure XI.18). Celui-ci
retrouve alors la page de lobjet sur disques dans ces tables, lit cette page dans la page
manquante, et rend la page accessible en lecture. Celle-ci peut alors tre accde
comme une page normale et lobjet peut tre lu. En cas de mise jour, la violation de
page est aussi rcupre pour mmoriser la ncessit dcrire la page en fin de transaction la validation, puis la page est rendue accessible en criture.

382 BASES DE DONNES : OBJET ET RELATIONNEL

Page Manquante

0
Mmoire Virtuelle Client

2**32

1 Accs

2 Violation

4 Retour Page

O.S.
3 Accs Serveur

Image Disque

Figure XI.18 : La technique de mmoire virtuelle

Cette technique est parfois appele mmoire un seul niveau (Single Level Store) ;
en effet, lutilisateur travaille directement sur limage de la base en mmoire. Elle est
trs efficace lorsquun mme objet est travers plusieurs fois et que les objets parcourus sont groups dans une mme page. Cependant, la dpendance du programme la
structure de la mmoire virtuelle peut constituer un inconvnient encore mal mesur
aujourdhui.

4. ALGBRE POUR OBJETS COMPLEXES

Les algbres pour objets complexes rsultent dextensions de lalgbre relationnelle
aux objets complexes. Elles permettent dexprimer les questions sur une bases de donnes objet comme des expressions doprations lmentaires. Afin dillustrer la
conception oriente objet, nous proposons une structuration de lalgbre en graphe
dobjets, chaque opration tant un objet dune classe.

4.1. EXPRESSIONS DE CHEMINS ET DE MTHODES

Lalgbre relationnelle permet normalement de rfrencer les attributs des relations
dans les expressions rsultats et les expressions de slection. Ces valeurs de rsultats
ou de slections sont extraites des tuples par des expressions valuables qui figurent

Le modle objet 383

en arguments des oprations de lalgbre. La notion dexpression valuable recouvre

traditionnellement les rfrences aux attributs, les constantes et les fonctions arithmtiques en relationnel. Par exemple, dans une table Produits, il est possible de slectionner le prix toutes taxes comprises des produits par lexpression valuable
PRIX*(1+TVA).
Dans un environnement objet, il est ncessaire de pouvoir appliquer des oprations
sur les objets et aussi de pouvoir rfrencer les identifiants, par exemple afin de parcourir les associations. On arrive ainsi naturellement gnraliser la notion dexpression valuable. Une premire gnralisation telle que propose ici a t effectue par
[Zaniolo85]. Deux types dexpressions valuables nouvelles sont ncessaires : les
expressions de chemins et les expressions de mthodes.
Notion XI.27 : Expression de chemin (Path Expression)
Squence dattributs de la forme A1.A2An telle que chaque attribut Ai de la classe Ci rfrence
un objet de la classe Ci+1 dont le suivant est membre, lexception du dernier.

Une expression de chemin permet deffectuer un parcours dans le graphe des associations de classes. Sur la base de la figure XI.12, Reprsente.Tte.Centre.x est une
expression de chemins : partant dun buveur B, elle permet datteindre un rel reprsentant labscisse du cente de la tte, en traversant les classes Caricature Cercle et
Point. De telles expressions sont la fois utilisables en algbre dobjets complexes et
en SQL tendu, comme nous le verrons dans les chapitres suivants. Ds que lon rencontre un chemin multivalu, la traverse devient ambigu ; par suite, la plupart des
langages interdisent les expressions de chemins multivalues du style Abus.cru sur
la base de la figure XI.12, car bien sr un buveur boit plusieurs vins.
Notion XI.28 : Expression de mthodes (Method Expression)
Squence dappels de mthodes de la forme M1.M2Mn, avec dventuels paramtres pour certaines mthodes Mi de la forme Mi(P1, P2Pj).

Une expression de mthodes permet en principe dappliquer des mthodes un objet,

lobjet slectionn tant largument distingu permettant lenvoi du message correspondant la mthode. Le polymorphisme doit tre mis en uvre pour slectionner le
bon code de la mthode. Par exemple, Travailler(10) est une expression de
mthode dont le code sera diffrent selon que lemploy est un cadre ou non (voir
figure XI.12).
Il est possible de gnraliser les expressions de mthodes afin de les appliquer aussi
des valeurs : on obtient alors des expressions fonctionnelles de la forme Fi(P1,
P2Pj) sappliquant sur des lments (objets ou valeurs) de type Ti et retournant des
lments de type Ti+1 sur lesquels on peut nouveau appliquer des oprations dfinies sur le type Ti+1. Une expression de chemins est alors un cas particulier o la

384 BASES DE DONNES : OBJET ET RELATIONNEL

fonction consiste traverser le pointeur. Il est aussi possible de gnraliser aux

expressions fonctionnelles multivalues, en tolrant en rsultat dune fonction une
collection. En rsum, la figure XI.19 prsente les diffrents types dexpressions
valuables dans un environnement objet.
Expression
Valuable

Nom
dattribut

Constante

Numrique

Entier

Expression
arithmtique

Chane de
caractres

Expression
fonctionnelle

Expression
de mthode

Expression
de chemin

Rel

Figure XI.19 : Diffrents types dexpressions valuables

partir des expressions valuables gnralises, il est possible de spcifier une qualification de restriction ou jointure gnralise, capable de traiter des objets complexes.
Une telle qualification peut tre vue comme un arbre ET-OU de prdicats lmentaires (voir figure XI.20). Un prdicat lmentaire est de la forme :
<Prdicat lmentaire> ::= <Expression valuable>
[<Comparateur> <Expression valuable>].

Un comparateur est choisi parmi {=, <, >, , , }. Le comparateur et la deuxime

expression valuable ne sont pas ncessaires si la premire expression valuable est de
type boolen (par exemple, une mthode boolenne telle Contains).
AND

AND

P1

OR

P2

P3

P4

((P3 OU P4) AND P2) AND P1

Figure XI.20 : Graphe ET-OU de prdicats lmentaires

Le modle objet 385

4.2. GROUPAGE ET DGROUPAGE DE RELATIONS

Outre les oprations classiques de lalgbre relationnelle, les algbres dobjets complexes gnralisent les oprations issues des agrgats et introduites dans les modles
non en premire forme normale, cest--dire avec des attributs multivalus ensemblistes. Les oprations de groupement comportent le groupage (nest en anglais) et le
dgroupage (unnest). Ces deux oprations ont lorigine t dfinies pour des relations comme suit (nous les tendrons aux objets plus loin) :
Notion XI.29 : Groupage (Nest)
Opration transformant une relation en crant pour chaque valeur des attributs de groupement un
ensemble de valeurs des attributs groups.

Cette opration, note dans certaines extensions de lalgbre relationnelle, fait donc
apparatre des attributs valeur dans des ensembles. Elle est illustre figure XI.21.
Une dfinition plus gnrale pourrait consister grouper la relation selon un schma
hirarchique des attributs : on pourrait ainsi faire plusieurs groupages en une seule
opration. Dans le monde objet, cette opration peut tre applique une collection
pour gnrer une nouvelle collection, avec pour chaque objet obtenu par groupage,
attribution dun nouvel identifiant.
Lopration de dgroupage est lopration inverse (voir figure XI.21).
Pice

Type

Numro

Grouper(Type,{Numro})

Pice

Dgrouper(Type,{Numro})

Type

{Numro}

{ 1,7 }

{ 3,8 }

{2}

Figure XI.21 : Exemple doprations de groupage et dgroupage

386 BASES DE DONNES : OBJET ET RELATIONNEL

Attention il nest pas toujours vrai quun dgroupage aprs un groupage donne la relation initiale, en particulier si cette dernire a des doubles.
Notion XI.30 : Dgroupage (Unnest)
Opration transformant une relation attributs groups en relation plate, crant pour cela un tuple
pour chaque valeur du groupe en dupliquant les valeurs des autres attributs.

4.3. LALGBRE DENCORE

Cette algbre a t introduite dans le cadre du projet de SGBDO Encore par Shaw et
Zdonik [Shaw90]. Elle apporte les concepts objets au sein dune algbre proche de
lalgbre relationnelle. Cette algbre supporte les types abstraits et les identifiants
dobjets. Les oprations accdent des collections types dobjets en invoquant linterface publique du type. Pour cela, lalgbre utilise des expressions doprations notes
fi et des prdicats construits partir de ces expressions nots p.
Les oprations sont les suivantes :
La slection dobjets dans une collection dentre par un prdicat p est dfinie
comme suit : Select(Collection, p) = {s(s Collection) p(s)}. Le rsultat est
donc un ensemble didentifiants dobjets indiquant ceux qui satisfont au prdicat p.
Limage dune collection par une expression fonctionnelle f de type T est dfinie
par : Image(Collection, f : T) = {f(s)s Collection}. Il sagit donc de lensemble
des objets rsultants de lapplication de f ceux de la collection.
La projection dune collection par une famille dexpressions fonctionnelles f1,
f2fn sur un tuple <A1, A2An> est dfinie par : Project(Collection,<(A1,
f1)...,(An, fn)>) = {<A1 : f1(s)...,An : fn(s)>(s Collection)}. Chaque objet
donne donc naissance un tuple, alors que chaque objet donnait naissance lment simple dans le cas de limage.
Le groupage dune collection de tuples sur un attribut Ai est dfini par
Nest(Collection,Ai) = {<A1 : s.A1..., Ai : t...,An : s.An> r s (r t s
Collection s.Ai = r)}. Lopration remplace la collection dentre par un ensemble
de tuples similaires pour les attributs autres que Ai, mais groupant dans un
ensemble les valeurs de Ai correspondant aux tuples identiques pour les autres attributs. Cette opration introduit dans le monde objet le groupage relationnel.
Le dgroupage dune collection de tuples sur un attribut Ai est dfini par :
UnNest(Collection,Ai) = {<A1 : s.A1...,Ai : t...,An : s.An> s InputCollection
t Ai}. Cest lopration inverse du groupage.

Le modle objet 387

Laplatissage dune collection est utilis pour restructurer des collections de collections. Il est dfini par : Flatten(Collection) = {r t Collection r t}.
La jointure de collections sur un prdicat p est une transposition simple de la jointure par valeur du relationnel : OJoin(Collection1, Collection2,A1,A2,p) = {<A1 :
s, A2 : r> s Collection1 r Collection2 p(s,r)}.
Afin dliminer les doubles, une opration dlimination de duplicata est introduite.
Elle est note DupEliminate (Collection, e). e est un paramtre permettant de dfinir
lgalit dobjets dans la collection. Ce peut tre par exemple lgalit didentifiants
ou de valeurs. Coallesce (Collection, Ai, e) est une variante permettant dliminer les
doubles dans un attribut Ai dun tuple avec attribut multivalu.
Les oprations ensemblistes classiques dunion, intersection et diffrence de collections sont considrer. Elles ncessitent la dfinition du type dgalit dobjets considr, sur identifiant ou sur valeur.

4.4. UNE ALGBRE SOUS FORME DE CLASSES

Examinons maintenant lalgbre LORA drive de celle utilise dans un SGBD objetrelationnel construit lINRIA la fin des annes 80 [Gardarin89]. Cette algbre
sappuie aussi sur des expressions valuables permettant de construire des qualifications et prdicats spcifis figure XI.22.
Class Qualification { // Connexion logique de prdicats ET de OU
Connecteur Node; // Connecteur logique AND, OR, NIL
Predicat* Primaire; // Prdicat lmentaire
Qualification* QualifDroite; // Reste de la qualification
};
Class Predicat
Expression*
Comparateur
Expression*
};

{ // Critre de comparaison lmentaire

Droite; // Expression droite
Comp; // Comparateur =, <, , >, ,
Gauche; // Expression gauche

Figure XI.22 : Spcifications en C++ des qualifications

Lalgbre distingue les oprations par valeur et par rfrence, dont largument est en
gnral un ou plusieurs identifiants. Les oprations sont classes en oprations de
recherche, oprations ensemblistes, oprations de groupement et enfin oprations de
mise jour. La figure XI.23 reprsente la hirarchie de gnralisation des oprations
de lalgbre propose.

388 BASES DE DONNES : OBJET ET RELATIONNEL

Opration
Algbrique

Recherche

Jointure

VJoindre

Slection

Ensemble

Groupe

MiseAJour

Union

Grouper

InsrerCol

Intersection

Dgrouper

InsrerObj

Diffrence

Aplatir

Changer

RJoindre

Supprimer

Figure XI.23 : Les diffrentes oprations de lalgbre

4.4.1. Les oprations de recherche

Nous distinguons les oprations lmentaires de recherche suivantes :
Slection (Filter) correspond lapplication dune qualification aux objets
dune collection et la projection laide dexpressions construites partir des
attributs en rsultat ; elle quivaut Project ou Image de lalgbre Encore, qui
sont ici regroupes en une seule opration.
Jointure par valeur (VJoindre) permet de filtrer le produit cartsien de deux
collections laide dune expression de qualification classique. Elle est ralise par
lOjoin de lalgbre Encore.
Jointure par rfrence (RJoindre), o le critre est une expression de chemin
mono ou multivalue, aussi ralisable par Ojoin avec Encore.
Lopration gnrique de recherche permet deffectuer plusieurs oprations lmentaires partir dune qualification gnrale et dune expression de rsultats (liste
dexpressions). La figure XI.24 donne une spcification indicative en C++ de la classe
Opration et des sous-classes dfinissant les oprations de recherche. Chaque sousclasse doprations de recherche correspond un type particulier de qualification.
class Opration {
// Options de tri et ddoublement des rsultats:
LIST(Field*) SortInfo; // Champs de tri.
Boolean Ascendant; // Ascendant si Vrai.
Boolean Duplicata; // Garder les doubles si vrai.
};

Le modle objet 389

class Recherche : public Opration {

// *** output = SEARCH (input-list, qualif, resul [,sort-dup])
Qualification* Critre; // Qualification gnrale.
LIST(Expression) Rsultat; // Expressions slectionnes.
};
class Selection : public Recherche {
// *** output = FILTER (input-list, qualif, resul [,sort-dup])
// Le critre est une qualification simple ou de mthodes};
class Jointure : public recherche { } ;
class RJoindre : public Jointure {
// *** result = RJOINDRE (input-list, qualif-ref, resul [, sort-dup])
// Le critre est une expression de chemins rfrence.
};
class VJoindre : public Jointure {
// *** result = VJOINDRE(input, input, qualif-join, resul [,sort-dup])
// Le critre est un prdicat de jointure.
};

Figure XI.24 : La classe des oprations de recherche

4.4.2. Les oprations ensemblistes

Les oprations ensemblistes permettent de raliser lunion, lintersection et la diffrence de
deux ensembles dobjets (en principe des instances de classes). Les objets peuvent tre
reprs par leurs identifiants (identit dobjets) ou par leurs valeurs (galit dobjets).
Selon que les oprations comparent les identifiants ou les valeurs, on obtient deux rsultats
en gnral diffrents. Il faut donc spcifier lgalit dobjets utilise en paramtre des oprations ensemblistes, ce qui est fait au niveau de la classe Assembler (voir Figure XI.25).
class Ensemble : public Operation {
Egalit Enum {identifiant; valeur}; // Type dgalit
Field* Identifiant; // Rfrence au champ identifiant.
};
class
//
};
class
//
};
class
//
};

Union : public Ensemble{

*** output = UNION (input-list, [,sort-dup])
Intersect : public Ensemble{
*** output = INTERSECT (input-list [,sort-dup])
Difference : public Ensemble{
*** output = DIFFERENCE (input-list [,sort-dup])

Figure XI.25 : Les classes des oprations ensemblistes

390 BASES DE DONNES : OBJET ET RELATIONNEL

4.4.3. Les oprations de mise jour

Les oprations de mise jour comportent les insertions, les suppressions et les modifications. Nous distinguons deux types dinsertion : insertion partir dune collection
temporaire (InsrerCol) et insertion dune liste dobjets fournis par valeurs
(InsrerObj). Ces deux oprations sont dfinies figure XI.26.
class
//
//
//
//
};

InsertCol : public MiseAJour{

*** input1 = INSERT_OBJ (input1, input2 [, sort-dup])
La 2e collection contient les objets insrer dans la premire.
La 1e collection est une collection de base.
La 2e est une collection calcule.

class InsertObj : public MiseJour{

// *** input = INSERT_VAL (input, Object_list [,sort-dup])
LIST(Expression) Objet[MaxObj]; // Objets insrer.
};

Figure XI.26 : Les classes des oprations dinsertion

Les suppressions seffectuent partir dune collection calcule qui contient les identifiants des tuples supprimer dans lautre collection. La suppression est quivalente
une diffrence sur identifiant dobjets. Elle est dfinie figure XI.27.

class Supprimer : public MiseJour{

// *** input1 = SUPPRIMER (input1, input2, identifiant [, sort-dup])
// La 2e collection contient les objets supprimer de la premire.
// La 1e collection est une collection de base.
// La 2e collection est une collection calcule.
Field* identifiant; // Rfrence au champ identifiant.
};

Figure XI.27 : La classe des oprations de suppression

Les modifications seffectuent aussi partir dune extension de classe calcule qui
contient les identifiants de tuples modifier dans une classe de base et les lments
pour calculer les nouvelles valeurs des champs modifis. Ces lments sont exprims,
pour chaque attribut, sous la forme dune expression de calcul (par exemple
A = A *1,1 pour une augmentation de 10 % de A). La figure XI.28 dfinit plus prcisment lopration Changer.

Le modle objet 391

class Changer : public MiseAJour{

// *** input1 = UPDATE (input1, input2 [, sort-dup])
// La 2e collection contient les objets changer dans la premire.
// La 1e collection est une collection de base.
// La 2e collection est une collection calcule.
Field* identifiant; // Rfrence au champ identifiant.
LIST(Field*) Achanger; // Champs modifier.
LIST(Expression) Calcul; // Mode de calcul des modifs.
};

Figure XI.28 : La classe des oprations de modification

4.4.4. Les oprations de groupe

Les oprations restant spcifier sont celles de groupage correspondant aux Nest,
Unest et Flatten de lalgbre Encore. La figure XI.29 spcifie plus prcisment les
oprations de groupage, dgroupage et aplatissage en termes de classes C++.

class Grouper : public Groupe {

// *** output = NEST (input, nest_exp, result-expression)
// Le groupage est effectu sur un seul groupe dattributs.
// Une expression rsultat est applicable aux champs groups.
// Lexpression rsultat doit sappliquer une collection.
LIST(Field*) Base; // Attributs pour le partitionnement.
LIST(Field*) Group; // Attributs grouper.
LIST(Expression) Rsultat; // Rsultats fournir.
};
class Degrouper : public Groupe {
// *** output = UNNEST (input, unnest_exp, result-expression)
// Le dgroupage est effectu sur un seul groupe dattributs.
// Une expression rsultat est applicable aux champs dgroups.
LIST(Field*) Base; // Attributs dupliquer.
LIST(Field*) Dgroup; // Attributs dgrouper.
LIST(Expression) Rsultat; // Rsultats fournir.
};
class Aplatir : public Groupe {
// *** output = FLATTEN (input, flatten_exp)
// La restructuration est faite sur un seul attribut
Field* Aplatit; // Attributs dsimbriquer de 1 niveau.
} ;

Figure XI.29 : Les classes doprations de groupage et dgroupage

392 BASES DE DONNES : OBJET ET RELATIONNEL

4.4.5. Arbres doprations algbriques

Finalement, comme avec le modle relationnel, une question peut tre reprsente par
une expression doprations de lalgbre dobjets complexes. Lexpression peut tre
visualise sous la forme dun arbre. Pour tre plus gnral, en particulier pour permettre le partage de sous-arbre et le support de boucles, il est souvent permis chaque
opration davoir plusieurs flots dentres et surtout plusieurs flots de sorties. Un flot
correspond une collection temporaire qui peut tre matrialise ou non, selon la stratgie dvaluation du systme.
Un exemple simple de graphe doprations est illustr figure XI.31. Il reprsente une
question portant sur une base de donnes qui dcrit des vhicules rfrenant des
constructeurs automobiles rfrenant eux-mmes leurs employs directeurs de divisions (voir figure XI.30). Soit la question rechercher les numros des vhicules de
couleur rouge dont le fabriquant est de Paris et a un directeur au moins de moins de
50 ans . Le graphe associ est un graphe possible parmi les nombreux graphes doprations permettant dexcuter cette question. Il est trs proche dun graphe relationnel.
Nous tudierons son optimisation au chapitre sur loptimisation de requtes objet.
Vhicule
+ numro
+ couleur
+ fabriquant

Constructeur
+ nom
+ ville
+ directeurs

Employ
+ nss
+ nom
- date naissance
+ age()

Figure XI.30 : Schma de la base Vhicule, Constructeur, Employ

Pour terminer la modlisation de lalgbre en C++, il faut maintenant spcifier la

classe dont les graphes dexpressions algbriques sont les instances. La figure XI.32
modlise un graphe doprations par deux classes en C++, lune correspondant aux
nuds (Nud) et lautre aux arcs (Flot). Nous avons choisi de reprsenter chaque arc
par un objet de la classe Flot, cela afin de pouvoir tiqueter les arcs, par exemple par
un volume de donnes estimes circulant sur larc. Cela permettrait dapprocher les
volumes de donnes traits et les cots doprations, comme nous le verrons au chapitre sur loptimisation de requtes.

Le modle objet 393

Project
[numro]
RefJoin

[directeurs]

Select[age()

Select[ville

<

50]

"Paris"]
Employ

RefJoin

[Fabriquant]

Constructeur
Select[couleur

"Rouge"]

Vhicule

Figure XI.31 : Exemple de graphe doprations

Class Nud {
Operation* Oper; // Operation effectuer en ce nud.
Flot* Input[MaxIn]; // collections dentre (fils).
Flot* Output[MaxOut]; // collections de sortie (parents).
};
Class Flot {
Int TailleEst; // Taille du flux estime.
} ;

Figure XI.32 : Classes modlisant un graphe doprations

394 BASES DE DONNES : OBJET ET RELATIONNEL

5. CONCLUSION
Dans ce chapitre, nous avons prsent les concepts de modlisation introduits par
lorientation objet, les techniques de gestion de la persistance des objets et une algbre
dobjets complexes. Ces concepts et techniques constituent lessentiel des fonctionnalits aujourdhui offertes par les SGBDO par le biais du langage de dfinition dobjets, du
langage de requtes et du langage de manipulation dobjets. Au-del, il est important de
mentionner que les SGBDO offrent pour la plupart des environnements de dveloppements visuels labors. Ceux-ci permettent de parcourir les graphes de gnralisation et
de composition (agrgation et association) de classes, mais aussi de visualiser les objets,
voire de crer de nouvelles classes et de programmer des mthodes. Ces diteurs volus (en anglais, browsers) sont un des attraits importants des SGBDO : en exploitation
par exemple, ils autorisent la vision des classes dobjets sous forme dicnes clicables
pour dclencher les mthodes associes. Ces mthodes peuvent dailleurs tre des oprations de recherche ou de mise jour proches de celles de lalgbre dobjets.
Outre ceux tudis dans ce chapitre, les bases de donnes objets soulvent de nombreux problmes difficiles. Les plus cruciaux sont sans doute ceux darchitecture et de
performance. Quelle architecture client-serveur retenir ? Faut-il plutt des serveurs
dobjets ou de pages [Dewitt90] ? Comment optimiser les performances, en grant des
caches dobjets, en utilisant des techniques de type mmoire virtuelle dobjets, en dveloppant des mthodes de regroupement des objets souvent accds ensemble, etc. ? Du
point de vue du langage de requtes tendu aux objets, nous allons voir que deux propositions de standards sopposent quelque peu. Les techniques doptimisation sont encore
mal matrises en pratique. Un autre problme important est celui pos par les modifications de schmas : comment viter de dcharger la base et recompiler les mthodes, par
exemple lors dajout de super-classes ou de suppression de sous-classes ? Une solution
est sans doute la gestion de versions dobjets et de schmas [WonKim90]. Les problmes de concurrence en prsence de transactions longues (une transaction de conception peut durer plusieurs heures) sont eux aussi cruciaux. Tous ces problmes (notre liste
nest malheureusement pas exhaustive) seront tudis dans les chapitres qui suivent.
Sous sa forme pure ou sous forme intgre au relationnel, lobjet constitue sans doute
la voie davenir pour les bases de donnes, comme pour bien dautres domaines. Des
standards de reprsentation se dveloppent au niveau des applications selon les techniques de modlisation oriente objet, en particulier les standards XML, SGML,
EXPRESS et CMIS/CMIP respectivement pour le WEB, la gestion de donnes techniques, la CAO et ladministration de rseaux. Ces langages de modlisation de documents ou de composants semblent bien adapts aux bases de donnes objets.
Lapproche objet reste cependant limite, car elle ncessite de bien connatre les
objets pour en dfinir le type. Fond sur un typage fort, lobjet est peu adapt pour
aborder les applications donnes faiblement structures, comme le Web. Des extensions sont ncessaires.

Le modle objet 395

6. BIBLIOGRAPHIE
[Abiteboul95] Abiteboul S., Foundations of databases, Addison-Wesley, Reading,
Mass., 1995.
Ce livre prsente les fondements thoriques des bases de donnes en faisant le
lien avec des domaines de recherche connexes, tels que la logique et la complexit. Il fait le point sur les problmes avancs des bases de donnes, notamment sur le couplage des modles dductifs et objets.
[Abiteboul87] Abiteboul S., Beeri C., On the Power of Languages for the
Manipulation of Complex Objects , International Workshop on Theory and
Applications of Nested Relations and Complex Objects, 1987, aussi rapport
INRIA n 846, Paris, mai 1988.
Cet article prsente une vue densemble thorique mais progressive des algbres
pour objets complexes. Il discute de la puissance des langages rsultants.
[Arnold96] Arnold K., Gosling J., Le Langage Java, International Thomson
Publishing France, Traduction de The Java Programming Language par S.
Chaumette et A. Miniussi, Addison Wesley Pub., 1996.
Ce livre est la rfrence sur le langage Java, par les inventeurs. Il inclut une
brve introduction au langage et une prsentation dtaille des commandes,
constructions et bibliothques. Sont couverts les aspects dfinition de classes et
dinterfaces, traitement des exceptions, multitche, package, classes systmes
et bibliothques.
[Atkinson89] Atkinson M., Bancilhon F., DeWitt D., Dittrich K., Maier D.,
Zdonick S., The Object-Oriented Database System Manifesto , Deductive
and Object-Oriented Databases Int. Conf., Kyoto, Japan, 1989.
Le fameux manifesto pour les bases de donnes pures objet. Les caractristiques
obligatoires et optionnelles des SGBDO sont prcises comme vu ci-dessus.
[Banerjee87] Banerjee J., Kim W., Kim H.J., Korth. H.F., Semantics and
Implementation of Schema Evolution in Object-Oriented Databases , ACM
SIGMOD Int. Conf., San Fransisco, Cal., 1987.
Cet article pose les problmes de modification de schmas dans les bases de
donnes objets: suppression ou addition dattributs, de mthodes, de surclasses, etc. Les solutions retenues dans ORION, qui permettent une grande
souplesse condition de respecter des rgles prcises (par exemple, pas de
cycle de gnralisation), sont prsentes.
[Bouzeghoub85] Bouzeghoub M., Gardarin G., Mtais E., SECSI: An Expert
System for Database Design , 11 th Very Large Data Base International
Conference, Morgan Kaufman Pub., Stockolm, Sude, 1985.
Cet article dcrit le systme SECSI bas sur un modle smantique appel
MORSE. MORSE supporte lagrgation, la gnralisation, lassociation et

396 BASES DE DONNES : OBJET ET RELATIONNEL

linstanciation. SECSI est construit selon une architecture systme expert. Cest
un outil daide la conception de bases de donnes relationnelles qui transforme le modle smantique en relations normalises. Le modle smantique
est labor partir de langages quasi naturels, graphiques ou de commande.
[Bouzeghoub91] Bouzeghoub M., Mtais E., Semantic Modelling of Object
Oriented Databases , 17th Very Large Database International Conference,
Morgan Kaufman Pub., Barcelone, Espagne, aot 1991.
Cet article propose une mthodologie de conception de bases de donnes
objets, fonde sur un rseau smantique. Lapplication est spcifie par un langage de haut niveau bti autour dun modle smantique et permet de dfinir
des contraintes dintgrit et des rgles de comportements. Cette approche est
intgre dans la version objet du systme daide la conception SECSI.
[CACM91] Communication of the ACM, Special Issue on Next-Generation
Database Systems , Communication of the ACM, vol. 34, n 10, octobre 1991.
Ce numro spcial des CACM prsente une synthse des volutions des SGBD
vers une nouvelle gnration. Les produits O2 commercialis par O2 Technology,
ObjectStore commercialis par Object Design, GemStone commercialis par
Servio, et les prototypes Postgres de luniverst de Californie Berkeley et
Starbust du centre de recherche dIBM Alamaden sont dcrits en dtail.
[Cardelli84] Cardelli L., Wegner P., On Understanding Types, Data, Abstraction,
and Polymorphism , ACM Computing Surveys, vol. 17, n 4, dcembre 1985.
Vaste article de synthse sur le typage, les abstractions de type et le polymorphisme. Les conditions de typage sr, cest--dire vrifiable la compilation,
sont tudies.
[Castagna96] Castagna G., Object-Oriented Programming A Unified Foundation,
366p., Birkhauser, Boston, 1997.
Ce livre dveloppe une thorie de lorientation objet, plus spcialement du polymorphisme, qui couvre les mthodes multiclasses. Il apporte un nouvel clairage
au problme du typage des paramtres des mthodes dans les cas de surcharge et
redfinition. En clair, la nouvelle thorie en vogue dans le monde objet.
[Cattell91] Cattell R.G., The Engineering Database Benchmark , in [Gray91].
Article prsentant les rsultats du premier benchmark comparant bases de donnes objets et relationnelles. Les rsultats dmontrent la supriorit des
SGBD objets pour les parcours de graphes.
[Cluet90] Cluet S., Delobel C., Lcluse C., Richard P., RELOOP, an Algebra Based
Query Language for an Object-Oriented Database System , Data &
Knowledge Engineering, vol. 5, n 4, octobre 90.
Une prsentation du langage dinterrogation du systme O2. La smantique du
langage est base sur une algbre tendue. Bien que possdant une syntaxe

Le modle objet 397

particulire, le langage est dun point de vue smantique proche dun SQL
tendu supportant des objets complexes.
[Delobel91] Delobel C., Lcluse Ch., Richard Ph., Bases de donnes : des systmes
relationnels aux systmes objets, 460 pages, Interditions, Paris, 1991.
Une tude trs complte de lvolution des SGBD, des systmes relationnels
aux systmes objets, en passant par les systmes extensibles. Une attention
particulire est porte sur les langages de programmation de bases de donnes.
Le livre dcrit galement en dtail le systme O2, son langage CO2 et les techniques dimplmentation sous-jacentes. Un livre en franais.
[Dewitt90] DeWitt D., Futtersack P., Maier D., Velez F., A Study of Three
Alternative Workstation-Server Architectures for Object-Oriented Database
Systems , 16 th Very Large Database International Conference, Morgan
Kaufman Pub., Brisbane, Australie, aot 1990.
Une tude comparative de trois architectures (serveur dobjets, de pages et de
fichiers) client-serveur pour les SGBDO. Lanalyse dmontre sommairement
que lapproche serveur de pages est plus performante sous certaines conditions
dans un contexte mono-utilisateur.
[Gardarin89] Gardarin G., Kiernan J., Cheiney J.P., Pastre D., Managing Complex
Objects in an Extensible Relational DBMS , 15th Very Large Databases International Conference, Morgan & Kaufman Ed., Amsterdam, p. 55-65, Aot 1989.
Cet article prsente le SGBD Sabrina ralis lINRIA de 1988 1990, qui fut
un des premiers SGBD relationnels intgrer lobjet. Les objets taient dfinis
comme des types abstraits dont les oprations taient programmes en LeLisp ou
en C. Ils taient intgrs au relationnel comme valeurs de domaines des tables.
Ce SGBD fut commercialis par une start-up qui fut malheureusement plus soutenue aprs 1988, les pouvoirs publics prfrant une dmarche objet pure.
[Gardarin94] Gardarin G., Nowak M., Valduriez P., Flora : A Functional-Style
Language for Object and Relational Algebra , 5th DEXA (Database and Expert
System Application) Intl. Conf., Athens, in LNCS n 856, p. 37-46, Sept. 1994.
FLORA est un langage fonctionnel permettant dcrire des plans dexcution
rsultant de la compilation de requtes objet. Il est du mme niveau quune
algbre dobjets complexes, mais bas sur une approche fonctionnelle. FLORA
manipule une riche bibliothque de collections.
[Goldberg83] Goldberg A., Robson D., Smalltalk-80: The Language and its
Implementation, Addison-Wesley, Reading, Mass., 1983.
Le livre de rfrence de Smalltalk, par les inventeurs du langage.
[Gray91] Gray J. Ed., The Benchmark Handbook, Morgan & Kaufman Pub., San
Mateo, 1991.
Le livre de base sur les mesures de performances des SGBD. Compos de diffrents articles, il prsente les principaux benchmarks de SGBD, en particulier le

398 BASES DE DONNES : OBJET ET RELATIONNEL

fameux benchmark TPC qui permet dchantillonner les performances des

SGBD en transactions par seconde. Les conditions exactes du benchmark dfinies par le Transaction Processing Council sont prcises. Les benchmarks
de luniversit du Madisson, AS3AP et Catell pour les bases de donnes
objets, sont aussi prsents.
[Guogen78] Guogen J., An Intial Algebra Approach to the Specification,
Correctness, and Implementation of Abstract Data Types , Current Trends in
Programming Methodology, vol. 4, Prentice-Hall 1978, L. Yeh Ed., 1978.
Cet article propose une formalisation des types abstraits de donnes comme
des sigma-algbres multisortes. Toutes les fonctions sont modlises comme des
transformations de sortes. Cela permet de spcifier chaque fonction par des
axiomes. Par exemple, une pile p munie des fonctions PUSH et POP doit obir
laxiome PUSH(POP(p)) = p. Un ensemble daxiomes permet de spcifier
compltement un type abstrait. Un des articles de base sur la thorie des types
abstraits de donnes.
[Guttag77] Guttag J., Abstract Data Types and the Development of Data
Structures , Comm. of ACM, Vol.20, n 6, juin 1977.
Cet article montre comment on peut spcifier limplmentation de types abstraits en fonction dautres types abstraits et comment ces implmentations peuvent tre caches lutilisateur (principe dencapsulation). Des ides sur le
contrle des spcifications et des implmentations sont aussi proposes. Cet
article plutt pratique dveloppe les principes des types abstraits.
[Hammer81] Hammer M., McLeod D., Database Description with SDM: A
Semantic Database Model , ACM TODS, Vol.6, n 3, septembre 1981.
Un des premiers modles smantiques proposs en bases de donnes ; les
notions dagrgation, gnralisation, abstraction sont notamment introduites
dans un modle base de graphe. Ce modle a t implment sur les systmes
UNISYS, mais le SGBD rsultant na malheureusement pas eu un grand succs,
bien quil ft un prcurseur des SGBD objets.
[Hose91] Hose D., Fitch J., Using C++ and Operator Overloading to Interface with
SQL Databases , The C++ Journal, vol. 1, n 4, 1991.
Cet article prsente une intgration de SQL C++. Des classes Base, Table,
Colonne et Curseur sont dfinies. Les requtes sont formules dans une syntaxe
proche de C++, mais aussi conforme SQL. Elles sont traduites en requtes
soumises au SGBD interfac. Le produit rsultant nomm CommonBase
sinterface avec SYBASE, ORACLE, INGRES, etc.
[Khoshafian86] Khoshafian S., Copeland G., Object Identity , OOPSLA Intl. Conf.,
Portland, Oregon, 1986, also in [Zdonik90].
Une discussion de lidentit dobjets : un identifiant est un repre qui distingue
un objet dun autre objet, indpendamment de son tat. Les diffrents types
dgalit et le partage de sous-objets sont introduits dans cet article de rfrence.

Le modle objet 399

[Lcluse89] Lcluse C., Richard Ph., The O2 Database Programming Language ,

15th Very Large Data Bases International Conference, Morgan Kaufman Pub.,
Amsterdam, Pays-Bas, aot 1989.
La description du langage du systme O2 ralis lINRIA au sein du GIP
Altar. Ce langage est une extension oriente objet de C distinguant objets et
des valeurs. Le langage permet dintroduire des classes avec mthodes, des
constructeurs dobjets complexes (tuples et ensembles), de la gnralisation et
des facilits de filtrage itratif de donnes. Le systme O2 est aujourdhui commercialis par O2 Technology.
[Lippman91] Lippman B. S., C++ Primer, 2e dition, 614 pages, Addison-Wesley,
1991.
Un excellent livre sur C++. Le langage est prsent sous tous ses aspects.
[Maier86] Maier D. et. al., Development of an object-Oriented DBMS , 1st Int.
Conf. on Object-Oriented Programming Systems, Languages and Applications,
Portland, Oregon, Oct. 1986.
Un des premiers articles dcrivant limplmentation dun SGBDO, le SGBD
GemStone. Celui-ci est construit partir dune interface Smalltalk (Gem)
connecte un serveur dobjets (Stone).
[OMG91] Object Management Group & X Open Group, The Common Object
Request Broker: Architecture and Specification , OMG Document n 91, 12.1,
Revision 1.1, octobre 1991.
Prsentation de larchitecture CORBA de lOMG. Cette architecture distribue
permet denvoyer des requtes des objets distants et de recevoir les rponses
avec des interfaces et un modle dobjets en voie de standardisation, en sabstrayant de limplmentation des objets. CORBA vise assurer linteroprabilit
entre les environnements orients objet. Les plus grandes compagnies industrielles soutiennent CORBA. Aujourdhui, plus de 800 fournisseurs de logiciels
et utilisateurs adhrent lOMG.
[Rational97] Rational Software, The Unified Modeling Language UML 1.1, Reference
Manual, Release 1.1, Boston, aussi disponible auprs de lOMG, 1997.
Le document de rfrence dUML. Les spcifications dUML, le langage graphique universel de modlisation de lobjet, sont disponibles ladresse Internet
www.rational.com/uml/ sous forme de plusieurs documents HTML ou PDF. Nous
en donnons un rsum dans le chapitre sur la conception des bases de donnes.
[Shaw90] Shaw G., Zdonik B.S., A Query Algebra for Object-Oriented Databases ,
Proc. of the 6th International Conf. On Data Engineering, IEEE Ed., p. 154162, 1990.
Cet article propose une algbre dobjet pour interroger les bases de donnes
objet. Cette algbre a t implmente dans le projet ENCORE, et est reste
connue sous ce nom. Nous lavons dcrite ci-dessus.

400 BASES DE DONNES : OBJET ET RELATIONNEL

[Stoustrup86] Stoustrup B., The C++ Programming Language, New York, AddisonWesley, 1986.
Le livre de rfrence de C++ par son inventeur. Stoustrup a cr C++ pour
modliser des problmes de rseaux de tlcommunications.
[WonKim88] Won Kim et. al., Features of the ORION Object-Oriented Database
System , dans le livre Object-Oriented Concepts, Applications and
Databases , W. Kim et Lochovsjy Ed., Addison-Wesley, 1988.
Une description du systme ORION, le SGBDO qui a popularis lapproche
bases de donnes objets. Dvelopp MCC ds 1985, ORION est un SGBDO
trs complet. Initialement bas sur Lisp, le produit, commercialis aujourdhui
par Itasca Systems, a volu vers C et C++.
[WonKim89] Won Kim, A Model of Queries for Object-Oriented Database , Very
Large Database International Conference, Morgan Kaufman Pub., Amsterdam,
Pays-Bas, aot 1989.
Cet article prsente les mthodes doptimisation utilises dans le systme
ORION pour le langage dinterrogation. La technique retenue est trs proche
de la restructuration darbre, considrant en plus les jointures par rfrences et
les parcours de chemins.
[WonKim90] Won Kim, Introduction to Object-Oriented Databases, 235 pages, The
MIT Press, 1990.
Ce livre dcrit les diffrentes techniques des SGBD objets. Il sinspire fortement du systme ORION. Plus particulirement, les problmes de modle
orient objet, de modification de schma, de langage SQL tendu aux objets, de
structures de stockage, de gestion de transactions, doptimisation de requtes et
darchitecture sont abords. Une bonne rfrence sur les bases de donnes
objets.
[Zaniolo85] Zaniolo C., The Representation and Deductive Retrieval of Complex
Objects , 11th Very Large Data Bases International Conference, Morgan
Kaufman Pub., Stockholm, Sude, aot 1985.
Cet article prsente une extension de lalgbre relationnelle aux fonctions permettant de retrouver des objets complexes. Des oprateurs dductifs de type
point fixe sont aussi intgrs.
[Zdonik90] Zdonik S., Maier D., Readings in Object-Oriented Database Systems,
Morgan Kaufman Pub., San Mateo, California, 1990.
Une slection darticles sur les bases de donnes objets.

Chapitre XII

LE STANDARD DE LODMG :
ODL, OQL ET OML
1. INTRODUCTION
Depuis 1988, une dizaine de petites socits commercialisent des SGBDO, avec un
succs encore limit. Elles se heurtent au problme de la portabilit des applications.
Il existe maintenant des langages de programmation objet ayant une bonne portabilit
comme C++, ou vraiment portables comme Java, qui a t conu pour tre port. Mais
porter des applications accdant des bases de donnes exige la portabilit des interfaces daccs. Ceci est possible en relationnel, avec SQL et des middlewares universels comme ODBC ou JDBC pour Java. Ceci tait trs difficile en objet devant
labsence de standards.
Ainsi, afin de dfinir des interfaces portables, sest constitu lObject Database
Management Group (ODMG), form au dpart par cinq vendeurs de SGBDO.
LODMG vise raliser pour les bases de donnes objets lquivalent de la norme
SQL, ou au moins dun projet de norme. Deux versions du standard propos ont t
publies assez rapidement : lune en 1993 [Odmg93], lautre prsente dans ce chapitre, en 1997 [Odmg97]. Un des buts des SGBDO, et donc de lODMG, est dviter
le problme soulev par les SGBD classiques o deux systmes cohabitent lors de
linterfaage avec un langage : celui du SGBD et celui du langage. Pour permettre une

402 BASES DE DONNES : OBJET ET RELATIONNEL

utilisation directe des types des langages objet, lODMG a choisi de dfinir un modle
abstrait de dfinition de bases de donnes objet, mis en uvre par un langage appel
ODL (Object Definition Language). Ce modle est ensuite adapt un langage
objet particulier : lODMG propose un standard dintgration en C++, Smalltalk, et
Java. Un langage dinterrogation pour ce modle est propos : il sagit dOQL (Object
Query Language), pour beaucoup issu du langage de requte du systme O2 ralis
lINRIA [Bancilhon92, Adiba93]. OQL est aussi intgrable dans un langage de programmation objet.
Ce chapitre prsente le standard de lODMG, en lillustrant par des exemples. Aprs
cette introduction, la section 2 prcise le contexte et larchitecture dun SGBDO
conforme lODMG. La section 3 dveloppe le modle abstrait et le langage ODL.
La section 4 prsente un exemple de base et de schma en ODL. La section 5 aborde
le langage OQL travers des exemples et des syntaxes types de requtes constituant
des exemples gnriques, appels profils. La section 6 se consacre lintgration dans
un langage de programmation ; le cas de Java est dtaill. La section 7 conclut ce chapitre en montrant les limites du standard de lODMG.

2. CONTEXTE
Dans cette section, nous prsentons le contexte gnral du standard : les auteurs,
le contenu de la proposition et larchitecture dun systme conforme lODMG.

2.1. L ODMG (OBJECT DATABASE MANAGEMENT

GROUP)
Apparus vers 1986, les SGBD objet navaient pas connu le succs escompt cinq ans
aprs leur naissance. Une des difficults majeures provenait de labsence de standards.
Alors que les applications des bases de donnes relationnelles pouvaient prtendre
une trs bonne portabilit assure par le standard SQL, du poste de travail au calculateur central sur toute machine et tout systme dexploitation, les SGBD objet prsentaient chacun une interface spcifique, avec des langages parfois exotiques. Un
groupe de travail fut donc fond en septembre 1991 linitiative 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 prsident neutre chez SUN en la personne de Rick Cattell, auteur
de diffrent bancs dessai sur les bases de donnes objet. Le groupe publia un premier
livre intitul The Object Database Management Standard, connu sous le nom

Le standard de lODMG : ODL, OQL et OML 403

ODMG93. En fait, il ne sagit pas dun standard avalis par les organismes de normalisation, mais plutt dune proposition dun groupe de pression reprsentant des
vendeurs de SGBDO.
Le groupe a continu travailler et sest enrichi de reprsentants de POET Software,
UniSQL, IBEX et Gemstone Systems, ainsi que de multiples gourous et observateurs
externes. Une nouvelle version du livre a t publie en 1997, sous le titre
ODMG 2.0 ; elle comporte dix auteurs. Le groupe est maintenant bien tabli et collabore avec lOMG et lANSI, notamment sur lintgration CORBA et SQL3. Les
constructeurs participants sengagent suivre les spcifications de lODMG, malheureusement sans dates prcises. Un des checs majeurs du groupe est sans doute
labsence de systmes conformes aux nouvelles spcifications. O2, qui est le systme
le plus proche, ne rpond pas exactement aux fonctionnalits requises [Chaudhri98].

2.2. CONTENU DE LA PROPOSITION

La proposition dcrit les interfaces externes dun SGBDO utilises pour raliser des
applications. Le SGBDO se fonde sur une adaptation du modle objet de lOMG,
modle de rfrence tudi au chapitre prcdent. Il comporte un langage de dfinition des interfaces des objets persistants drivs de lIDL de lOMG et appel ODL
(Object Definition Language).
Notion XII.1 : ODL (Object Definition Language)
Langage de dfinition de schma des bases de donnes objet propos par lODMG.

Une dfinition peut aussi tre effectue directement dans lun des langages supports.
La partie la plus intressante de la proposition est le langage OQL (Object Query
Language).
Notion XII.2 : OQL (Object Query Language)
Langage dinterrogation de bases de donnes objets propos par lODMG, bas sur des requtes
SELECT proches de celles de SQL.

Une intgration est propose avec les langages objets C++, Smalltalk et Java. Celle-ci
prcise les conversions de types effectues et permet la manipulation des objets grs par
le SGBD depuis le langage. Elle est appele OML (Object Manipulation Language).
Notion XII.3 : OML (Object Manipulation Language)
Langage de manipulation intgr un langage de programmation objet permettant la navigation,
linterrogation et la mise jour de collections dobjets persistants, dont lOMG propose trois
variantes : OML C++, OML Smalltalk et OML Java.

404 BASES DE DONNES : OBJET ET RELATIONNEL

La figure XII.1 illustre les diffrentes interfaces proposes par le standard ODMG. Ce
sont celles permettant de raliser des applications autour dun SGBDO. Sont-elles suffisantes pour assurer la portabilit ? Probablement non, car les interfaces graphiques sont
aussi importantes et souvent spcifiques du SGBDO. Quoi quil en soit, le respect de
ces interfaces par les produits amliorerait de beaucoup la portabilit des applications.
OQL
ODL

OML Java
OML C++

OML Smalltalk

SGBDO

Figure XII.1 : Interfaces daccs un SGBDO

2.3. ARCHITECTURE
La figure XII.2 illustre larchitecture typique dun SGBDO conforme lODMG.
Autour dun noyau grant la persistance des objets, lattribution des identifiants, les
mthodes daccs, et les aspects transactionnels, gravitent trois composants : le prprocesseur ODL permet de compiler les dfinitions dobjets et de gnrer les donnes
de la mtabase ; le composant langage OML spcifique chaque langage de programmation permet de manipuler les objets conformes aux dfinitions depuis un langage
de programmation tel C++, Smalltalk ou Java ; le composant OQL comporte un analyseur et un optimiseur du langage OQL capables de gnrer des plans dexcution
excutables par le noyau. Au-dessus de ces trois composants, diffrents outils interactifs permettent une utilisation facile des bases ; ce sont par exemple un diteur de
classes pour diter les schmas ODL, un manipulateur dobjets pour naviguer dans la
base (les deux runis constituent souvent le browser), une bibliothque dobjets graphiques, des dbogueurs et diteurs pour les langages de programmation, etc.
Du ct interface avec les langages de programmation, le schma prconis est bas
sur un systme de type unique entre le langage et le SGBDO, chaque type du modle
objet du SGBDO (en principe celui de lODMG) tant traduit directement dans un
type correspondant du langage. Un principe de base est aussi de ne ncessiter aucune
modification du compilateur du langage. Les dclarations de classes persistantes peuvent tre crites en ODL, ou directement dans le langage de programmation (PL
ODL). Un prcompilateur permet de charger la mtabase du SGBDO et de gnrer la
dfinition pour le langage de programmation. Les programmes enrichis avec les dfinitions de classes dobjets persistants sont compils normalement. Le binaire rsultant

Le standard de lODMG : ODL, OQL et OML 405

est li la bibliothque daccs au SGBD lors de ldition de liens, ce qui permet la

gnration dun excutable capable daccder la base. La figure XII.3 illustre le processus dobtention dun excutable.
diteur de classes
Manipulateur dobjets
Bibliothques graphiques
Dbogueur, diteur

Outils interactifs

OML

OQL

OQL = Object Query Language

ODL = Object Defintion Language
OML = Object Manipulation Language

ODL

Persistance
Identification
Accs

Grant d'objets

Concurrence
Fiabilit
Scurit

Figure XII.2 : Architecture type dun SGBDO conforme lODMG

Dclaration en
ODL ou PL ODL

Application
Source en PL

Pr-compilateur
de dclarations

Compilateur
de PL

ODBMS
Runtime

Application
Binaire

diteur
de liens

Excutable

Figure XII.3 : Lien avec les langages de programmation

406 BASES DE DONNES : OBJET ET RELATIONNEL

3. LE MODLE DE LODMG
Nous dcrivons maintenant le modle abstrait propos pour la dfinition des schmas
des bases de donnes objet.

3.1. VUE GNRALE ET CONCEPTS DE BASE

LOMG organisme de normalisation de lobjet compos de plus de 800 membres,
ne pas confondre avec lODMG a propos un modle standard pour les objets permettant de dfinir les interfaces visibles par les clients. Le modle de lODMG est une
extension du modle de lOMG et un candidat pour un profil BD de ce dernier. Il est
mis en uvre laide du langage ODL qui permet de spcifier les schmas de bases
de donnes, alors que le modle de lOMG est support par le langage IDL (Interface
Definition Language). Les bases de donnes objets ncessitent des adaptations ou
extensions ; ODL se veut ladaptation dIDL aux bases de donnes.
Une extension principale est tout dabord la ncessit de considrer un niveau dabstraction permettant de manipuler des tats abstraits pour les objets. Ce sont ces tats qui sont
mmoriss plus ou moins directement dans la base pour les objets persistants. En outre,
les objets peuvent tre groups en collections beaucoup plus varies que les seules
squences de lOMG. Ils peuvent aussi tre associs par des associations. Tout cela
conduit un modle et un langage de dfinition associ (ODL) beaucoup plus complexe que celui de lOMG. ODL reste cependant un langage de niveau conceptuel, supportant un modle objet abstrait, qui peut tre implment dans diffrents langages, en
particulier C++, Smalltalk ou Java. Chaque construction ODL a donc une implmentation correspondante pour chacun de ces langages. Au contraire dODL, OML sappuie
sur une implmentation et est donc spcifique un langage de programmation objet.
Le modle de lOMG comporte des types dobjets avec identifiants et des types de
valeurs, ou littraux. Outre les interfaces qui permettent de spcifier des comportements abstraits, ODL permet de spcifier des classes qui dfinissent, en plus dun
comportement abstrait, un tat abstrait pour des objets dun mme type. On aboutit
donc trois types de dfinitions dobjets ou valeurs, prciss ci-dessous ; cest un peu
complexe, voire confus, mais ncessaire pour permettre limplmentation des spcifications de comportement ou dtat en C++, Smalltalk ou Java.
Notion XII.4 : Dfinition dinterface (Interface definiton)
Spcification du comportement observable par les utilisateurs (ou dune partie de celui-l) pour un
type dobjets.

Nous dfinissons par exemple figure XII.4 une interface calculateur modlisant une
machine calculer.

Le standard de lODMG : ODL, OQL et OML 407

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();}

Figure XII.4 : Dfinition de linterface dun calculateur

Notion XII.5 : Dfinition de classe (Class definition)
Spcification du comportement et dun tat observables par les utilisateurs pour un type dobjets.

Une classe implmente ainsi une ou plusieurs interfaces. En plus dun comportement,
une classe dfinit un tat abstrait. Pour mmoriser les tats abstraits de ses instances,
une classe possde aussi une extension de classe.
Notion XII.6 : Extension de classe (class extent)
Collection caractrise par un nom contenant les objets crs dans la classe.

Le comportement abstrait pourra tre hrit dune interface. On voit donc quune
classe donne une spcification dune ou plusieurs interfaces en prcisant quelques lments dimplmentation, en particulier ltat des objets (abstrait car indpendant de
tout langage) et lextension qui va les contenir. Dans certains cas complexes, une
classe peut dailleurs avoir plusieurs extensions. Il est aussi possible de prciser une
cl au niveau dune extension de classe : comme en relationnel, il sagit dun attribut
dont la valeur dtermine un objet unique dans lextension. La figure XII.5 illustre une
dfinition de classe incorporant linterface calculateur.
CLASS ORDINATEUR (EXTENT ORDINATEURS KEY ID) : CALCULATEUR {
ATTRIBUTE SHORT ID ;
ATTRIBUTE FLOAT ACCUMULATEUR;
VOID START();
VOID STOP(); }.

Figure XII.5 : Un exemple de classe

Notez quune interface peut aussi comporter des attributs abstraits, mais ceux-ci sont
vus comme des raccourcis doprations, une pour lire lattribut, lautre pour lcrire.
Une interface na en principe pas dextension.
Interfaces et classes sont des spcifications de types. Il est aussi possible de spcifier
des types de valeurs : ceux-ci sont appels des littraux.

408 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XII.7 : Dfinition de littral (Literal dfinition)

Spcification dun type de valeur correspondant un tat abstrait, sans comportement.

Les littraux correspondent aux types de base tels entier, rel, chane de caractres,
mais aussi aux structures. Un exemple de littral est un nombre complexe : struct
complex {float re; float im}. Les littraux sont directement implments comme des
types de valeurs en C++. Dans les autres langages purs objets (Smalltalk ou Java), ce
seront des objets.
En rsum, lODMG propose donc un systme de types sophistiqu, capable dtre
facilement mapp en C++, Smalltalk ou Java. Il y a donc des types, des interfaces, des
classes et des littraux. Lensemble forme la hirarchie de spcialisation reprsente
figure XII.6.
Type

Littral

Interface

Classe

Figure XII.6 : Classification des dfinitions de type

3.2. HRITAGE DE COMPORTEMENT

ET DE STRUCTURE
Comme vu ci-dessus, une classe peut hriter dune interface : il sagit dun hritage de
comportement. Toutes les oprations de linterface seront alors dfinies pour les
objets de la classe. Au niveau de limplmentation, la classe fournira le code des oprations.
En plus de cette relation dhritage de comportement dinterface vers une classe,
lODMG propose un hritage de structure abstraite, cest--dire de ltat des objets,
cette fois de classe classe. Cette relation dhritage dtat est note EXTENDS ( ne
pas confondre avec EXTENT !). Par exemple, nous tendrons la classe ORDINATEUR
comme indiqu figure XII.7.

Le standard de lODMG : ODL, OQL et OML 409

Soulignons que lhritage de comportement (not :) peut tre multiple : une classe
peut implmenter plusieurs interfaces, mais elle ne peut driver que dune seule autre
classe. En cas de conflits de noms, cest lutilisateur quil incombe de distinguer les
noms.
CLASS ORDINATEURAREGISTRE EXTENDS ORDINATEUR: CALCULATEUR {
ATTRIBUTE FLOAT REGISTRE;
VOID RTOA();
VOID ATOR (); }.

Figure XII.7 : Exemple dhritage de structure et de comportement

3.3. LES OBJETS INSTANCES DE CLASSES

Les objets sont donc regroups selon des types. Comme dans tout modle objet, ils
sont identifis par des OID. Ceux-ci sont des chanes binaires de format spcifique de
chaque implmentation, grs par le SGBD OO pour distinguer les objets. Un OID
permet de retrouver lobjet quil identifie pendant toute sa dure de vie. Il reste donc
invariant pendant la vie de lobjet.
Classiquement, les objets sont persistants ou transients : les objets persistants sont les
objets de la base, les autres restant en mmoire. Les objets persistants peuvent tre
nomms : les noms sont donns par les utilisateurs et sont uniques dans une base de
donnes.
Les objets peuvent tre atomiques, structurs, ou collections, cest--dire composs de
collections dobjets ou de littraux. Les objets atomiques sont spcifis par lutilisateur par des dfinitions de classes comportant des attributs, des associations et des
oprations. Les objets structurs sont prdfinis et obissent des interfaces spcifiques.

3.4. PROPRITS COMMUNES DES OBJETS

Les objets sont crs par une opration new() dfinie au niveau dune interface
ObjectFactory implmente par le SGBDO (voir figure XII.8). Ils hritent dun
ensemble doprations implmentes par le SGBDO pour le verrouillage qui peut
tre bloquant si lobjet est occup (opration LOCK) ou non (opration TRY_LOCK) ,
la comparaison didentifiants, la copie dobjet avec gnration dun nouvel objet et la
suppression (voir figure XII.8).

410 BASES DE DONNES : OBJET ET RELATIONNEL

INTERFACE OBJECTFACTORY {
OBJECT NEW(); // CRATION DUN 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 DIDENTIFIANTS
DOBJETS
OBJECT COPY(); // COPIE AVEC GENERATION DUN NOUVEL OBJET
VOID DELETE()}; // SUPPRESSION DUN OBJET

Figure XII.8 : Interface commune des objets

3.5. LES OBJETS STRUCTURS

Les objets structurs sinspirent des types SQL2 utiliss pour la gestion du temps.
Lintrt de dfinir ces types comme des objets est de permettre de spcifier leur comportement sous forme dinterfaces. Des structures correspondantes sont aussi fournies
dans les types de base proposs par lODMG. Les objets seuls offrent des oprations
standard. Voici les types dobjets structurs supports :
Date reprsente un objet date par une structure (mois, jour, an) munie de toutes les
oprations de manipulation classique des dates.
Interval reprsente un objet dure par une structure (jour, heure, minute,
seconde) munie de toutes les oprations de manipulation ncessaires, telles que
laddition, la soustraction, le produit, la division, les tests dgalit, etc.
Time reprsente les heures avec zones de temps, en diffrentiel par rapport au
mridien de Greenwich ; lunit est la milliseconde.
Timestamp encapsule la fois une date et un temps. Un objet timestamp permet
donc une rfrence temporelle absolue en millisecondes.

3.6. LES COLLECTIONS

LODMG prconise le support de collections homognes classiques de type SET<t>,
B AG <t>, L IST <t> et A RRAY <t>. Une collection un peu moins classique est
DICTIONARY<t,v>, qui est une collection de doublets <cl-valeur>. Toutes les collections hritent dune interface commune COLLECTION, rsume figure XII.9. Celle-ci
permet de crer des collections dune taille initiale donne par le biais dune
ObjectFactory , puis de manipuler directement les collections pour rcuprer leurs

Le standard de lODMG : ODL, OQL et OML 411

proprits (taille, vide ou non, ordre ou non, doubles permis ou non, appartenance
dun lment), pour insrer ou supprimer un lment, pour parcourir la collection par
le biais dun itrateur 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(INVALID
COLLECTIONTYPE);
};

Figure XII.9 : Interface commune aux collections

Comme son nom lindique, un itrateur permet ditrer sur les lments. Pour cela, il
fournit une interface rsume figure XII.10. Un itrateur bidirectionnel permet daller
en avant, mais aussi en arrire.
INTERFACE ITERATOR {
VOID RESET() ; // INITIALISATION AU DBUT
ANY GET_ELEMENT() RAISES(NOMOREELEMENTS); // OBTENTION LMENT
VOID NEXT_POSITION RAISES(NOMOREELEMENTS); // AVANCE POSITION
REPLACE_ELEMENT (IN ANY ELEMENT) RAISES(INVALIDCOLLECTIONTYPE) ;
...
};

Figure XII.10 : lments dinterface pour les itrateurs

Chaque collection possde en plus des interfaces spcifiques classiques. La

figure XII.11 prsente les oprations spcifiques aux dictionnaires. Il sagit de la gestion de doublets <cl-valeur>, la cl tant en principe unique. Elle correspond un
mot dentre dans le dictionnaire, la valeur tant sa dfinition (ou son synonyme).
Lutilisateur peut lier une cl une valeur (ce qui revient insrer ce doublet), dlier
la cl (la supprimer), rechercher la valeur associe une cl, et tester si une cl
figure dans le dictionnaire. Les dictionnaires peuvent permettre par exemple de grer
des rpertoires de noms dobjets, etc.

412 BASES DE DONNES : OBJET ET RELATIONNEL

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) ;
};

Figure XII.11 : Interface spcifique aux dictionnaires

Type

Object

Atomic Obj

Literal

Collection Obj Structured Obj

Set <>
Bag <>
List <>
Array <>
Dictionary <>

Date
Time
Timestamp
Interval

Atomic Lit.
Long
Short
Ulong
Ushort
Float
Double
Character
Boolean
string
octet
enum <>

Collection Lit.

Structured Lit.

Set <>
Bag <>
List <>
Array <>
Dictionary <>

Structure<>
Date
Time
Timestamp
Interval

Figure XII.12 : La hirarchie des types ODMG

3.7. LES ATTRIBUTS

Les attributs permettent de modliser les tats abstraits des objets. Un attribut est une
proprit permettant de mmoriser un littral ou un objet. Il peut tre vu comme une
dfinition abrge de deux oprations : Set_value et Get_value. Un attribut possde
un nom et un type qui prcise ses valeurs lgales. Il nest pas forcment implment,
mais peut tre calcul.

3.8. LES ASSOCIATIONS (RELATIONSHIPS)

Les associations permettent de complter la modlisation des tats des objets.
LODMG prconise le support dassociations binaires, bidirectionnelles de cardinalit

Le standard de lODMG : ODL, OQL et OML 413

(1:1), (1:N), ou (N:M), sans donnes. Une association de A vers B dfinit deux chemins de traverse inverses, A->B et B->A. Chaque chemin doit tre dfini en ODL au
niveau du type dobjet source par une clause RELATIONSHIP. Lassociation pointe vers
un seul objet cible ou vers une collection. Elle porte un nom et son inverse doit tre
dclar. Pour la gestion, le SGBDO doit fournir des oprations sur associations telles
que Add_member, Remove_member, Traverse et Create_iterator_for.
De fait, les associations sont simplement des dclarations abstraites dattributs coupls, valus par une valeur simple ou une collection, contenant des identifiants
dobjets rciproques. La figure XII.13 illustre lassociation classique entre VINS et
BUVEURS, mais sans donnes.
INTERFACE BUVEURS {
...
RELATIONSHIP LIST<VINS> BOIRE INVERSE VINS::EST_BU_PAR;
...
};
INTERFACE VINS {
...
RELATIONSHIP SET<BUVEURS> EST_BU_PAR INVERSE BUVEURS::BOIRE;
...
};

Figure XII.13 : Exemple de dfinition dassociation

Lorsquune association est mise jour, le SGBDO est responsable du maintien de

lintgrit : il doit insrer ou supprimer les rfrences dans les deux sens si loption
inverse a t dclare. Il ne doit pas y avoir de rfrence pointant sur des objets
inexistants. Ce nest pas le cas pour un attribut valu par un objet, do lintrt dutiliser des associations plutt que de dfinir directement les attributs supports. Par
exemple, la dclaration au niveau des buveurs dun attribut par la clause ATTRIBUT
BOIRE LIST<VINS> nimplique pas lexistence dun chemin inverse ni la gestion de
lintgrit rfrentielle par le SGBDO. Cependant, les associations de lODMG restent assez pauvres puisquelles ne peuvent avoir de donnes associes.

3.9. LES OPRATIONS

Classiquement, les oprations permettent de dfinir le comportement abstrait dun
type dobjets. Elles possdent les proprits habituelles des oprations sur objet : le
nom de lopration, le nom des conditions derreurs (aprs le mot cl RAISES), le nom
et le type des arguments (aprs le mot cl IN), le nom et le type des paramtres retourns (aprs le mot cl OUT ). Lensemble constitue la signature de lopration. La
figure XII.14 illustre la dfinition de lopration boire dans linterface buveurs.

414 BASES DE DONNES : OBJET ET RELATIONNEL

INTERFACE BUVEURS {
...
INT BOIRE(IN VINS V, IN INT QTE) RAISES(NOVINS); //SIGNATURE DE
LOPRATION
...
};

Figure XII.14 : Un exemple de dfinition dopration

3.10. MTA-MODLE DU MODELE ODMG

Dans sa nouvelle version 2.0, lODMG spcifie un mta-modle objet, cest--dire un
modle objet dcrivant son modle. Ce modle, plutt complexe, permet de dfinir le
schma dun rfrentiel objet capable de grer des schmas de bases de donnes objet
conformes lODMG. Nous en donnons une vue trs simplifie figure XII.15. Il faudrait tout dabord ajouter les concepts de littraux, type et interface dont classe hrite.
Dautres concepts sont ncessaires, comme MetaObject, Scope, Module, Exceptions.
Tout cela est dfini dans [ODMG97].
Support

Class
Instantiate

key_list
extent_name
super_class

*
1

*
OID
has_name
names
class
create
delete
exits
same_has?

Property

Attribute
attr_name
attr_type
set_value
get_value

Operation
signature
invoke
return
return_abnormally

Has
Object

Extends

Traversal path
path_name
to_cardinality
to_type
traverse
creator_iterator
2

Relationship
Define
1

add_member
remove_member

Figure XII.15 : Vue simplifie du mta-modle de lODMG

Le standard de lODMG : ODL, OQL et OML 415

4. EXEMPLE DE SCHMA ODL

titre dillustration, la figure XII.17 dfinit le schma dune base de donnes objet
dont le modle est reprsent figure XII.16. La base dcrit simplement des situations
du monde rel : des personnes possdent des voitures, et habitent dans des appartements. Parmi elles, certaines sont employes, dautres sont buveurs. Parmi les
employs il y a des buveurs. Les buveurs boivent des vins.
Appartient

Habite

Voiture
nveh
couleur
marque
km
rouler()

Possde

Appart.

Personne
nss
nom
prenom
datenais
vieillir()
dormir()

Loge

Infrieur

Boire
Employ

*
Suprieur

tage
no
rue
code
ville

fonction
salaire
primes
travailler()

Buveur
type
tat
boire()

Vin
*
Bu_par cru
millsime
degr
qualit

EmployBuveur

Figure XII.16 : Schma graphique de la base exemple (en UML)

Class Voiture (extent voitures key nveh) { // classe avec extension
attribute string nveh;
attribute string couleur;
attribute string marque;
attribute short km;
relationship Personne Appartient inverse Personne::Possede;
short rouler(in short distance); };
Interface Personne { // interface abstraite pour implmentation dans classe
attribute string nss ;
attribute string nom ;
attribute string prenom ;
attribute date datenaissance;
relationship Appart habite inverse Appart::loge; // relationship
avec inverse
relationship Voiture Possede inverse Voiture::Appartient;

416 MATRISER LES BASES DE DONNES

short vieillir();
void dormir()
short age(); };
class Employ : Personne(extent Employs key nss) { //classe avec extension
attribute enum fonct{ingnieur, secrtaire, analyste, programmeur}
fonction;
attribute float salaire ;
attribute list<float> primes ; //attribut multi-valu
relationship Set<Employ> inferieur inverse suprieur;
relationship Employ suprieur inverse infrieur;
void travailler(); };
class Buveur : Personne(extent buveurs key nss) { // classe avec extension
attribute typebuv{petit,moyen,gros} type;
attribute etabuv{normal,ivre} etat;
relationship list<Vin> boire inverse vin::bu_par;
void boire(in Vin v); // paramtre dentre v };
class Appart (extent Apparts) { // classe avec extension
attribute struct adresse (short etage, unsigned short numero, string rue,
unsigned short code, string ville);
relationship Set<personne> loge inverse Personne::habite; };
class Vin (extent Vins) { // classe avec extension
attribute string cru;
attribute string millesime;
attribute string degre;
attribute string qualite;
relationship list<Buveur> bu_par inverse Vin::boire; };
class EmployBuveur extends Employ { // classe sans extension hrite
de employ
attribute typebuv{petit,moyen,gros} type;
attribute etabuv{normal,ivre} etat;
relationship list<Vin> boire inverse vin::bu_par;
void boire(in Vin v); // paramtre dentre v
};

Figure XII.17 : Schma en ODL de la base exemple

Une dcision prendre lors de la dfinition est de choisir entre interfaces et classes.
Certaines classes peuvent avoir des extensions. Nous avons choisi dimplmenter les
extensions de Voiture, Vin, Appartement, Buveur et Employ. Personne
devient une interface. Lhritage multiple ntant pas possible au niveau des classes,
les employs buveurs sont des employs avec les proprits de buveurs rptes. On
aurait pu viter cette rptition en dfinissant une interface Buveurs, puis une classe
CBuveurs implmentant cette interface. Nous ne lavons pas fait pour ne pas perturber
le lecteur. Le bon choix est probablement de dfinir des interfaces pour tout ce qui est
visible lextrieur, puis de raliser ces interfaces par des classes.

Le standard de lODMG : ODL, OQL et OML 417

5. LE LANGAGE OQL
Cette section dtaille le langage de requtes OQL et introduit des profils de requtes
typiques.

5.1. VUE GNRALE

Le langage OQL a t dfini partir dune premire proposition issue du systme O2
dvelopp lINRIA. Les objectifs des auteurs taient les suivants :
permettre un accs facile une base objet via un langage interactif autonome, mais
aussi depuis un langage objet par intgration dans C++, Smalltalk, et plus tard
Java ;
offrir un accs non procdural pour permetttre des optimisations automatiques
(ordonnancement, index) ;
garder une syntaxe proche de SQL au moins pour les questions exprimables en
SQL ;
rester conforme au modle de lODMG, en permettant linterrogation de toutes les
collections dobjets extensions de classes ou autres collections imbriques ou non ,
le parcours dassociation, linvocation doprations, la manipulation didentifiants,
le support de lhritage et du polymorphisme, etc.
permettre de crer des rsultats littraux, objets, collections
supporter des mises jour limites via les oprations sur objets, ce qui garantit le
respect de lencapsulation.
Ces objectifs sont-ils atteints ? Beaucoup le sont, mais il nest pas sr que le langage
soit simple, au moins pour les habitus de SQL. La compatibilit avec SQL reste
faible, la smantique tant gnralement diffrente, 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 exprims. Pour le reste, le langage est
trs riche, plutt lgant, et il existe une dfinition formelle, certes assez difficile
lire. La syntaxe est compacte.
Le langage est construit de manire fonctionnelle. Une question est une expression
fonctionnelle qui sapplique sur un littral, un objet ou une collection dobjets, et
retourne un littral, un objet ou une collection dobjets. Les expressions fonctionnelles
peuvent tre composes afin de constituer des requtes plus complexes. Le langage
est aussi fortement typ, chaque expression ayant un type qui peut tre driv de la
structure de lexpression et du schma de la base. La correction de la composition des
types doit tre vrifie par le compilateur OQL. Du point de vue du typage, OQL est
peu permissif, et ne fait gure de conversions automatiques de types, la diffrence
de SQL. Syntaxiquement, beaucoup de questions sont correctes, mais errones du

418 BASES DE DONNES : OBJET ET RELATIONNEL

point de vue typage. OQL nest pas seulement un langage dinterrogation, mais bien
un langage de requtes avec mises jour. En effet, il est possible de crer des objets et
dinvoquer des mthodes mettant jour la base.
OQL permet aussi la navigation via les objets lis de la base, mais seulement avec des
expressions de chemins monovalues.
Il est possible de naviguer par des expressions de chemins un peu particulire,
rduites des chemins simples, que lon dfinira comme suit :
Notion XII.8 : Expression de chemin monovalu (Monovalued path expression)
Squence dattributs ou dassociations monovalues de la forme X1.X2Xn telle que chaque Xi
lexception du dernier contient une rfrence un objet ou un littral unique sur lequel le suivant
sapplique.

Par exemple, voiture.appartient.personne.habite.adresse.ville est une expression de

chemin valide sur la base de donnes exemple.
Pour parcourir les associations multivalues, OQL utilise la notion de collection
dpendante.
Notion XII.9 : Collection dpendante (Depending collection)
Collection obtenue partir dun objet, soit parce quelle est imbrique dans lobjet, soit parce
quelle est pointe par lobjet.

Par exemple, chaque buveur rfrence par lassociation Boire une liste de Vins. Si B
est un buveur, B.Boire est une collection dpendante, ici une collection de Vins. Par
des variables ainsi lies du style B in Buveurs, V in B.Boire, OQL va permettre de
parcourir les associations multivalues. Ceci est puissant pour naviguer, mais plutt
procdural.
Pour prsenter un peu plus prcisment ce langage somme toute remarquable, nous
procdons par des exemples un peu gnraliss. Avant de les lire, il est bon de se rappeler que dans toute syntaxe une collection peut tre remplace par une requte produisant une collection. Rciproquement, il est possible de crer des collections intermdiaires et de remplacer chaque sous-requte par une collection intermdiaire. Cela
peut permettre de simplifier des requtes nombreuses sous-requtes imbriques.

5.2. EXEMPLES ET SYNTAXES DE REQUTES

Nous prsentons OQL travers des exemples sur la base dfinie en ODL ci-dessus.
Pour chaque exemple ou groupe dexemples, nous abstrayons une syntaxe type dans
un langage intuitif proche de la spcification de syntaxe en SQL : [a] signifie que a est

Le standard de lODMG : ODL, OQL et OML 419

optionnel, [a]* signifie une liste de 0 N a spars par des virgules, [a]+ de 1 N a
spars par des virgules, {a|b} signifie un choix entre a ou b, et... indique une syntaxe
libre compatible avec celles dj introduites. Cette syntaxe peut servir de profil (les
patterns sont la mode) pour formuler un type de requte. Nous appelons aussi
lexpression syntaxique un profil, ou plus simplement un format. Chaque profil est
prcd dun nom de trois lettres suivi de : servant de rfrence pour un usage
ultrieur ventuel. Nous donnons aussi le type du rsultat infr par le compilateur
(aprs la requte, sous forme ===> type). Le langage tant complexe, nous ne donnons pas une dfinition, celle-ci pouvant tre trouve dans [ODMG97]. Il y en a
dailleurs deux, une formelle, une autre en BNF, et elles ne semblent pas totalement
cohrentes !

5.2.1. Calcul dexpressions

OQL permet de calculer des expressions arithmtiques de base, qui sont donc comme
des questions.
(Q0) ((STRING) 10*5/2) || TOTO
===> string

Ceci donne en principe la chane 25TOTO . Cette requte montre la fois le calcul
dexpressions et les conversions de type. Son profil syntaxique est :
PEX: (<TYPE>) <EXPRESSION>

o lexpression peut tre calcule avec tous les oprateurs classiques (+, *, , /, mod,
abs, concatnation). Plus gnralement, lexpression peut aussi tre une collection
dobjets, et donc une requte produisant une telle collection, comme nous en verrons
beaucoup ci-dessous.

5.2.2. Accs partir dobjets nomms

OQL permet de formuler des questions sous forme dexpressions simples, en particulier construites partir du nom dun objet. Si MAVOITURE est le nom de lobjet
dsignant ma voiture, il est possible de demander :
(Q1) MAVOITURE.COULEUR
===> LITTRAL STRING

Plus gnralement, OQL permet de naviguer dans la base en parcourant des chemins
monovalus, comme vu ci-dessus. Par exemple, la question (Q2) retourne le nom du
propritaire de ma voiture (en principe, Gardarin !) :
(Q2) MAVOITURE.APPARTIENT.NOM
===> LITTRAL STRING

Nous appellerons de telles requtes des extractions dobjets. Un profil correspondant

de telles questions est :

420 BASES DE DONNES : OBJET ET RELATIONNEL

PEO: <NOM OBJET>.<CHEMIN>

o <CHEMIN> dsigne une expression de chemins.

5.2.3. Slection avec qualification

Nous retrouvons l les expressions de slection du SQL de base. La notation de SQL
pour la dfinition de variable derrire le FROM (du style BUVEURS AS B, ou
BUVEURS B) peut dailleurs tre utilise. La requte suivante retrouve les noms et
prnoms des gros buveurs :
(Q3) SELECT B.NOM, B.PRENOM
FROM B IN BUVEURS
WHERE B.TYPE = GROS
==> LITTRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>>

La syntaxe gnrale de slections simples est:

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

5.2.4. Expression de jointures

OQL permet les jointures, tout comme SQL, avec une syntaxe similaire. Par exemple,
la requte suivante liste les noms et prnoms des employs gros buveurs :
(Q4) SELECT B.NOM, B.PRENOM
FROM B IN BUVEURS, E IN EMPLOYS
WHERE B.NSS = E.NSS AND B.TYPE = GROS
==> LITTRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>>

Le profil syntaxique dune requte de slection avec un ou plusieurs critres de slection et une ou plusieurs jointures est :
(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>]]*

De manire gnrale, les qualifications peuvent faire intervenir, comme en SQL, des
AND et des OR, et des expressions parenthses contenant ces connecteurs logiques.
Une question quivalente peut utiliser le type EMPLOYEBUVEUR comme suit :
(Q5) SELECT ((EMPLOYBUVEUR)B).NOM, ((EMPLOYBUVEUR)B).PRENOM
FROM B IN BUVEURS
WHERE B.TYPE = GROS
==> LITTRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>

Le standard de lODMG : ODL, OQL et OML 421

Lvaluateur doit alors vrifier lexcution lappartenance des gros buveurs trouvs
la classe des EMPLOYEBUVEUR.
Le profil de telles questions avec indicateurs de classe est :
PIC: SELECT [((<CLASSE>)<VARIABLE>).<ATTRIBUT>]+
FROM...
[WHERE...]

5.2.5. Parcours dassociations multivalues

par des collections dpendantes
Les collections dpendantes se parcourent par des variables imbriques derrire le
FROM. Ceci permet de traverser des chemins multivalus correspondant des associations [1:N] ou [M:N]. Par exemple, la requte suivante retrouve le nom et le prnom des buveurs qui ont bu du Volnay :
(Q6) SELECT B.NOM, B.PRENOM
FROM B IN BUVEURS, V IN B.BOIRE
WHERE V.CRU = VOLNAY
==> LITTRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>

Le profil syntaxique gnral dune requte de parcours de collections dpendantes est :

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

Bien sr, la clause WHERE peut tre compose de slections, de jointures, etc.

5.2.6. Slection dune structure en rsultat

Il est possible de slectionner une structure en rsultat ; cest dailleurs loption par
dfaut que nous avions utilise jusque l, les noms des attributs tant directement ceux
des attributs sources. La requte suivante permet de retrouver des doublets (Name,
City) pour chaque gros buveur :
(Q7) SELECT STRUCT (NAME: B.NOM, CITY: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.TYPE = GROS
===> LITTRAL BAG <STRUCT(NAME,CITY)>

Par similarit avec SQL, la collection rsultat est un BAG. Il est aussi possible dobtenir une collection de type SET en rsultat ; on utilise alors le mot cl DISTINCT,
comme en SQL :
(Q8) SELECT DISTINCT (NAME: B.NOM, CITY: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.NOM = DUPONT
===> LITTRAL SET <STRUCT(NAME, CITY)>

422 BASES DE DONNES : OBJET ET RELATIONNEL

Le mot cl STRUCT tant implicite, le profil correspondant ce type de requtes est :

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

5.2.7. Calcul de collections en rsultat

Plus gnralement, le rsultat dune requte peut tre une collection quelconque de littraux ou dobjets. Par exemple, la requte suivante fournit une liste de structures :
(Q9) LIST(SELECT STRUCT(NOM: B.NOM, VILLE: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.NOM = DUPONT)
===> LITTRAL LIST <STRUCT(NOM, VILLE)>

Le profil syntaxique plus gnral est :

PCS: <COLLECTION>

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

5.2.8. Manipulation des identifiants dobjets

Les identifiants sont accessibles lutilisateur. Il est par exemple possible de retrouver
des collections didentifiants dobjets par des requtes du type :
(Q10) ARRAY(SELECT V
FROM V IN VOITURES
WHERE B.MARQUE = RENAULT)
===> LITTRAL ARRAY(<OID>)

dont le profil est :

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

5.2.9. Application de mthodes en qualification et en rsultat

La question suivante slectionne les employs ainsi que leur ville dhabitation et leur
ge, dont le salaire est suprieur 10 000 et lge infrieur 30 ans (age() est une
mthode) :
(Q11) SELECT DISTINCT E.NOM, E.HABITE.ADRESSE.VILLE, E.AGE()
FROM E IN EMPLOYS
WHERE E.SALAIRE > 10000 AND E.AGE() < 30
===> LITTRAL DE TYPE SET <STRUCT>

Le standard de lODMG : ODL, OQL et OML 423

Elle peut tre gnralise au profil suivant :

PME: SELECT

[DISTINCT]...,
[<VARIABLE>.<CHEMIN>.<OPERATION>([<ARGUMENT>]*)]*

FROM...
[WHERE....
[AND<VARIABLE>.<CHEMIN>.<OPERATION>([<ARGUMENT>]*) <COMPARATEUR>
<CONSTANTE>]*]

5.2.10. Imbrication de SELECT en rsultat

Afin de construire des structures imbriques, OQL permet dutiliser des SELECT imbriqus en rsultat de SELECT. Par exemple, la question suivante calcule pour chaque
employ une structure comportant son nom et la liste de ses infrieurs mieux pays :
DISTINCT STRUCT (NOM : E.NOM, INF_MIEUX_PAYES :
LIST (SELECT I
FROM I IN E.INFERIEUR
WHERE I.SALAIRE > E.SALAIRE))
FROM E IN EMPLOYS
===> LITTRAL DE TYPE SET <STRUCT (NOM: STRING, INF_MIEUX_PAYS : LIST
<EMPLOYS>)>
(Q12) SELECT

Voici un profil possible pour une telle question :

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

5.2.11. Cration dobjets en rsultat

Il est possible de crer des objets dans une classe par le biais de constructeurs ayant
pour arguments des requtes. Bien sr, des constructeurs simples peuvent tre appliqus pour insrer des objets dans des extensions de classes, par exemple la requte :
(Q13) EMPLOY (NSS:15603300036029,

NOM:JEAN, SALAIRE:100000).

Plus gnralement, il est possible demployer tous les buveurs sans emploi par la
requte suivante :
(Q14) EMPLOY(SELECT STRUCT(NSS : B.NSS, NOM: B.NOM, SALAIRE : 4000)
FROM B IN BUVEURS
WHERE NOT EXIST E IN EMPLOYS : E.NSS=B.NSS)
==> BAG<EMPLOYS> INSR DANS EMPLOYS

Notez que cette requte utilise une quantification que nous allons expliciter plus loin.
Le profil gnral de ces requtes de cration dobjets est donc :
PCO : <CLASSE>(<QUESTION>).

424 BASES DE DONNES : OBJET ET RELATIONNEL

5.2.12. Quantification de variables

OQL propose des oprateurs de quantification universelle et existentielle directement
utilisables pour composer des requtes, donc des rsultats ou des qualifications.

5.2.12.1. Quantificateur universel

La question suivante retourne vrai si tous les employs ont moins de 100 ans :
(Q15) FOR ALL P IN EMPLOYS : P.AGE < 100

Son profil est :

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

5.2.12.2. Quantificateur existentiel

La requte suivante retourne vrai sil existe une voiture de marque Renault possde
par un buveur de plus de 60 ans :
(Q16) EXISTS V IN SELECT V
FROM V IN VOITURES, B IN V.POSSEDE
WHERE V.MARQUE = RENAULT: B.AGE() > 60.

Un profil gnralis possible est :

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

5.2.13. Calcul dagrgats et oprateur GROUP BY

Dans la premire version, les agrgats taient calculables par utilisation dun oprateur fonctionnel GROUP applicable sur toute requte. La version 2 est revenue une
syntaxe proche de celle de SQL pour des raisons de compatibilit. Les attributs
grouper sont gnralement dfinis par une liste dattributs, alors que le critre de
groupement peut tre explicitement dfinies par des prdicats, ou implicitement par
une liste dattributs. Dans le dernier cas, le mot cl PARTITION peut tre utilis
pour dsigner chaque collection rsultant du partitionnement. Les deux requtes suivantes illustrent ces possibilits :
(Q17) SELECT E
FROM E IN EMPLOYS
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 EMPLOYS
GROUP BY E.HABITE.ADRESSE.VILLE
HAVING AVG (SELECT E.SALAIRE FROM E IN PARTITION)> 5000
===> BAG <STRUCT (VILLE: STRING, MOY: FLOAT)>

Le standard de lODMG : ODL, OQL et OML 425

PAG: SELECT...[<AGGREGAT>(<ATTRIBUT>)]*
FROM...
[WHERE...]
GROUP BY {<ATTRIBUT>+ | <PREDICAT>+}
HAVING <PRDICAT>

AGGREGAT dsigne une fonction dagrgats choisie parmi COUNT, SUM, MIN, MAX et
AVG. PREDICAT dsigne un prdicat expression logique de prdicats simples de la
forme <ATTRIBUT>
<COMPARATEUR>
<CONSTANTE> ou
<AGGREGAT>(PARTITION) <COMPARATEUR> <CONSTANTE>. On voit donc
que OQL gnralise les agrgats de SQL2 en permettant de grouper par prdicats
explicites. Cest aussi possible en SQL3 avec dautres constructions.

5.2.14. Expressions de collections

Il est possible de manipuler directement les collections en appliquant des oprateurs
spcifiques. Les rsultats de requtes sont souvent des collections, si bien que les oprateurs peuvent tre appliqus aux requtes. Voici quelques exemples doprateurs.

5.2.14.1. Tris
La premire syntaxe tait fonctionnelle. La nouvelle est copie sur SQL, comme suit :
(Q19) SELECT E.NOM, E.SALAIRE
FROM E IN EMPLOYS
WHERE E.SALAIRE > 21000
ORDER BY DESC E.SALAIRE

Le profil est donc analogue celui de SQL :

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

5.2.14.2. Union, intersection, diffrence

Comme en SQL, union, intersection et diffrence de questions sont possibles. Par
exemple :
(Q20) EMPLOYS UNION BUVEURS

est une requte valide.

Le profil gnral de ce type de requte est :
PEN : <COLLECTION> {INTERSECT|UNION|EXCEPT} <COLLECTION>

Les priorits sont selon lordre indiqu, les parenthses tant aussi possibles.

5.2.14.3. Accesseurs aux collections

Il est possible dextraire un lment dune collection en utilisant une fonction daccs
gnrale, comme first ou last, ou plus gnralement des fonctions daccs spcifiques

426 BASES DE DONNES : OBJET ET RELATIONNEL

au type de collection. Les constructeurs de collections struct, set, list, bag, array sont
aussi utilisables pour construire des collections comme nous lavons dj vu. Ainsi :
(Q21) SELECT B.NOM, FIRST(B.BOIRE)
FROM B IN BUVEURS

slectionne le premier vin bu par un buveur.

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

sont des profils admissibles.

5.2.15. Conversions de types appliques aux collections

Comme nous lavons vu, le rsultat dune question est souvent une collection.
Rciproquement, une collection correctement spcifie est une question dont la rponse
est la liste de ses lments. Tout oprateur applicable une ou plusieurs collections lest
aussi une ou plusieurs questions. Cest particulirement le cas des oprateurs ci-dessus.
Comme il existe diffrents types de collections, il est possible dappliquer des oprateurs
de conversion, par exemple LISTOSET qui traduit une liste en un ensemble et DISTINCT qui traduit toute collection en un ensemble. De plus, il est possible de transformer une collection ayant un seul lment en un singleton par loprateur ELEMENT. Par
exemple, la question suivante retrouve la marque de la voiture de numro 120 ABC 75 :
(Q22) ELEMENT (SELECT V.MARQUE
FROM V IN VOITURES
WHERE V.NUMRO = 120 ABC 75)
===> STRING

Les collections apparaissant en rsultat de requtes sont parfois imbriques. Les collections peuvent tre aplaties laide de loprateur FLATTEN. Par exemple :
(Q23) FLATTEN (SELECT B.NOM, SELECT V.MILLSIME
FROM V IN B.BOIRE
WHERE V.CRU = VOLNAY

FROM B IN BUVEURS)
slectionne simplement des doublets nom de buveurs et millsime de Volnay pour les
buveurs ayant bu du Volnay.
En gnral, les profils permis sont donc :
PCO : LISTTOSET(<COLLECTION>)|
ELEMENT(<COLLECTION>)|
DISTINCT(<COLLECTION>)|
FLATTEN(<COLLECTION>)

Le standard de lODMG : ODL, OQL et OML 427

5.2.16. Dfinition dobjets via requtes

Finalement, OQL permet aussi de nommer le rsultat dune requte. Celui-ci apparat
alors comme un littral ou un objet nomm (selon le type du rsultat). Par exemple, la
requte suivante obtient un ensemble dobjets buveurs nomm IVROGNE :
(Q24) DEFINE IVROGNES AS
SELECT DISTINCT B
FROM B IN BUVEURS
WHERE B.TYPE = GROS

Le profil gnral est simplement :

PDE : DEFINE <IDENTIFIANT> AS <QUESTION>.

5.3. BILAN SUR OQL

OQL est un langage de requte dessence fonctionnelle trs puissant. Nous navons
donn que quelques exemples de possibilits avec une syntaxe approximative. En fait,
OQL est un langage hybride issu dun mlange dun langage fonctionnel et dun langage assertionnel comme SQL. Dailleurs, SQL est lui-mme un mlange dun langage doprateurs (ceux de lalgbre relationnelle) et dun langage logique purement
assertionnel (QUEL tait proche dun tel langage). Tout cela devient trs complexe et
la smantique est parfois peu claire, quoi quen disent les auteurs. Pour tre juste,
disons que SQL3, dcrit au chapitre suivant, souffre des mmes dfauts.

6. OML : LINTGRATION C++,

SMALLTALK ET JAVA
6.1. PRINCIPES DE BASE
Le modle de lODMG est abstrait, cest--dire indpendant de toute implmentation.
Pour limplmenter dans un langage objet spcifique, il est ncessaire dadapter le
modle. Par exemple, il faut prciser ce que devient un littral dans un langage pur
objet tel Smalltalk, ce que devient une interface en C++, ou une association en Java.
Les types de donnes ODMG doivent tre implments avec ceux du langage pour
conserver un systme de type unique. Il faut aussi pouvoir invoquer les requtes OQL
depuis le langage et rcuprer les rsultats dans des types intgrs au langage, par
exemple comme des objets du langage.

428 BASES DE DONNES : OBJET ET RELATIONNEL

LODMG propose trois intgrations de son modle et de son langage de requtes, une
pour C++, une autre pour Smalltalk, une enfin pour Java. Autrement dit, la vision de
lusager dune BD conforme aux spcifications de lODMG est prcise pour ces trois
langages objet. Les objectifs essentiels de ces propositions sont :
1. La fourniture dun systme de types unique lutilisateur. En principe, le systme de types utilis est celui du langage de programmation parfois tendu, par
exemple avec des collections. En effet, les vendeurs de SGBDO ayant longtemps
dcri les SGBD relationnels pour lhtrognit des types des langages de programmation et de SQL, ils se devaient dviter cet cueil.
2. Le respect du langage de programmation. Cela signifie que ni la syntaxe ni la
smantique du langage ne peuvent tre modifies pour accommoder la manipulation des donnes. Des classes supplmentaires seront gnralement fournies, mais
le langage de base ne sera pas modifi.
3. Le respect du standard abstrait ODMG. Ceci signifie que lintgration propose
doit donner accs toutes les facilits abstraites du modle ODMG et de son langage de requtes OQL. Ce principe nest que partiellement suivi dans ltat actuel
du standard, certaines facilits ntant pas supportes, 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 lintgration Java, celles
avec les autres tant similaires, mais un peu plus complexes. Auparavant, nous allons
discuter des interfaces gnrales de gestion des bases de donnes et des transactions
qui doivent tre fournies.

6.2. CONTEXTE TRANSACTIONNEL

Laccs aux bases de donnes seffectue dans un contexte transactionnel. Le langage
doit donc fournir des transactions implmentes par le SGBDO. Plus prcisment, une
transaction est un objet cr par une TransactionFactory qui implmente
linterface comportant les oprations suivantes :
begin() pour ouvrir une transaction ;
commit() pour valider les mises jour de la transaction, relcher les verrous
obtenus et terminer la transaction avec succs ;
abort() pour dfaire les mises jour de la transaction, relcher les verrous obtenus et terminer la transaction avec chec ;
checkpoint() qui a le mme effet que commit() suivi de begin(), mais ne
relche pas les verrous ;
join() pour rcuprer lobjet transaction rcepteur sous contrle du contexte
dexcution (thread courante) ;

Le standard de lODMG : ODL, OQL et OML 429

leave() pour dissocier un objet transaction du contexte dexcution courant ;

isOpen() pour tester si la transaction est ouverte.
Ce type doprations sur transactions est commun, lexception de join() et
leave() prvus pour permettre un contexte dexcution de grer plusieurs transactions, ou linverse pour permettre une transaction de traverser plusieurs contextes
dexcution.
Avant dexcuter des oprations au sein de transactions, un utilisateur doit ouvrir un
objet bases de donnes. Plus gnralement, limplmentation doit fournir des objets
Database (crs partir dune DatabaseFactory) qui supportent les oprations
suivantes :
open(in string nom-de-base) pour ouvrir une base de nom donn afin
dy accder via le langage en transactionnel ;
close() pour fermer une base ;
bind(in any unObjet, in string nom) pour donner un nom lobjet
pass en paramtre; cest lopration de base pour nommer un objet dans une base
de donnes, le nom ne devant pas dj exister dans la base; un mme objet peut
avoir plusieurs noms ;
Object unbind(in string nom) pour enlever un nom un objet prcdemment nomm ;
Object lookup(in string nom) pour retrouver et charger comme un objet
du langage lobjet de la base de nom donn.
Laccs depuis un langage de programmation objet une base ODMG ncessite donc
limplmentation de ces interfaces dans le langage objet. Ceci est simple puisque le
SGBDO doit supporter ces oprations, les interfaces Transaction et Database
tant partie intgrante du standard ODMG.

6.3. LEXEMPLE DE JAVA

Java est un langage objet la mode, plus simple et plus sr que C++, idal pour raliser des applications distribues robustes. Java comporte des littraux de base (entier,
rel, string, etc.) et des objets instances de classes. Il ne supporte pas les associations
autrement que par des rfrences inter-classes. Tout ceci en fait un langage de choix
pour dvelopper des applications bases de donnes. Nous examinons brivement les
diffrents aspects de Java OML ci-dessous.

6.3.1. La persistance des objets

Pour pouvoir tre persistant, un objet doit tre instance dune classe connue du
SGBDO. Plusieurs moyens sont possibles pour faire connatre une classe Java au

430 BASES DE DONNES : OBJET ET RELATIONNEL

SGBDO : dfinir la classe en ODL et crire un compilateur ODL gnrant des dfinitions de classes Java, avoir un prprocesseur reconnaissant les classes persistantes ou
ajouter une interface spcifique de persistance ces classes, etc. Le standard actuel ne
se prononce pas sur le moyen de dclarer une classe Java persistante. De telles classes
sont supposes existantes et connues du SGBDO. Elles peuvent alors contenir des
objets persistants, mais aussi toujours des objets transients.
Alors, comment rendre un objet (dune classe persistante) persistant ? Le mcanisme
retenu est la persistance par atteignabilit. Les racines de persistance sont les objets
nomms au moyen de lopration bind de linterface base de donnes vue ci-dessus.
Tout objet rfrenc par un objet persistant est persistant. Tout objet non rfrenc par
un objet persistant doit tre dtruit automatiquement de la base, ce qui sous-entend
lexistence dun ramasse-miettes sur disques. Au-del, le standard propose que les
objets persistants puissent conserver des attributs non persistants, ce qui nest sans
doute pas simple dclarer sans modifier Java.

6.3.2. Les correspondances de types

Les types de lODMG sont traduits dans des types Java. Les littraux long, short,
float, double, boolean, octet, char et string sont traduits en type primitif Java correspondant de mme nom, sauf long qui devient int et octet qui
devient byte. Java propose pour chaque type primitif une reprsentation valeur et
une reprsentation objet par des instances de la classe de mme nom : les deux traductions sont possibles. Les types structurs date, time et timestamp sont traduits
comme des objets dfinis dans le package Java.sql de JDBC, le standard daccs aux
bases relationnelles.

6.3.3. Les collections

Linterface Collection et ses extensions Set, Bag, List et Array sont implmentes en Java avec des oprations similaires, mais harmonises avec Java. Java
supporte le type de collection Array de plusieurs manires : les Array sont des
tableaux monodimensionnels de taille fixe intgr au langage, Vector est une classe
standard supportant des tableaux dynamiques. Il est possible dutiliser Array ou
Vector pour implmenter une classe Varray conforme au standard ODMG.

6.3.4. La transparence des oprations

Toute opration excutable en Java sur des objets transients lest galement sur des
objets persistants. Cest au SGBDO dassurer la transparence la persistance, par
exemple de grer les rfrences entre objets persistants, de lire les objets persistants
rfrencs non prsents en mmoire, et de reporter ltat des objets modifis dans la

Le standard de lODMG : ODL, OQL et OML 431

base la validation de transaction. Les techniques mettre en uvre sont spcifiques

chaque SGBD, mais doivent tre transparentes lutilisateur.

6.3.5. Java OQL

Lintgration dOQL seffectue de deux manires. Tout dabord lajout dune opration Query(String predicate) permet de filtrer les objets dune collection avec
un prdicat OQL. En supposant que Vins dsigne une collection dobjets persistants
ou non, on pourra par exemple retrouver les bons vins par la construction suivante :
SET<OBJECT> LESBONSVINS;
LESBONSVINS = VINS.QUERY(QUALIT = BONS).

De manire plus complte, une classe OQLQuery est propose afin de composer des
requtes paramtres OQL sous forme dobjets, de demander leur excution et de
rcuprer les rsultats dans des objets Java, en gnral des collections. La classe
OQLQuery comporte plus prcisment les oprations :
OQLQuery(String question) pour crer des requtes avec le texte paramtr (les paramtres sont nots $i) en OQL pass en argument ;
OQLQuery() pour crer des requtes gnriques, le texte tant pass ensuite par
lopration create(String query) ;
bind(Object parameter) pour lier le premier paramtre non encore li de la
requte ;
execute() pour excuter une requte pralablement construite et rcuprer un
objet Java de type collection ou simple en rsultat.
Voici une illustration simple de cette classe pour retrouver les buveurs dun cru quelconque, par exemple de Volnay ; Java ne supportant pas les associations, on supposera
que lattribut Boire de buveurs est implment comme une collection de vins :
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();

6.3.6. Bilan
Java OML propose une vision simple dune base de donnes ODMG en Java. La premire version de cette proposition est assez brivement dcrite dans le standard. Nous
en avons donn un aperu ci-dessus. La cl du problme semble tre dans le support
des collections en Java, qui est loin dtre standard. Le problme de lODMG pourrait
tre terme de faire concider son standard avec le standard Java, notamment pour les
collections. Sinon, il y aurait vraiment opposition de phase (impedance mismatch), ce
qui serait paradoxal ! Ceci ne serait cependant pas tonnant, car peut-on construire

432 BASES DE DONNES : OBJET ET RELATIONNEL

deux standards (un pour les bases de donnes, lautre pour le langage) indpendamment et conserver un systme de type unique ? Une meilleure approche est probablement de dvelopper un langage de programmation bas sur les types du SGBD pour
viter les problmes de conversion de types. Cest ce que propose SQL3, comme nous
le verrons dans le chapitre qui suit.

7. CONCLUSION
Depuis 1991, les vendeurs de SGBDO tentent de crer un standard afin dassurer la
portabilit des programmes utilisateurs, donc des applications. Cette dmarche est
importante car elle seule peut garantir la prennit de lapproche bases de donnes
objet pour les utilisateurs. Deux versions de ce standard ont t publies, lune en
1993, lautre en 1997. Nous nous sommes bass sur la version 1997 (ODMG 2.0)
pour crire ce chapitre. Bien que remarquable, la version 2 est quelque peu complexe
et nest gure supporte par les systmes actuels (ni dailleurs celle de 1993). Aussi,
elle est parfois ingale dans le niveau de dtails fourni. Elle se compose dun modle
abstrait de bases de donnes objet et dinterfaces concrtes pour chacun des langages
supports.
En outre, le langage de requtes OQL constitue une contribution importante de cette
proposition. OQL offre les fonctionnalits du SQL de base avec en plus des extensions pour manipuler les expressions de chemins, les mthodes et surtout les collections. Cest un langage trs puissant, mais complexe, qui a aussi quelques dficiences,
comme labsence de contrle de droits et de gestion de vues. Il peut tre intgr
C++, Smalltalk et Java de manire standard. Tout ceci est positif.
Alors, peut-on enfin parler de portabilit des applications des SGBDO, par exemple
crites en Java ? Il y a pour linstant peu de retour dexpriences. De plus, les vendeurs de SGBDO, lexception sans doute de O2, nimplmentent pas OQL et ne se
soucient finalement gure plus que dans le discours du standard ODMG. Pour garantir
une certaine portabilit, il faut donc utiliser du pur Java, sans requte. Cest encore
faible. Mais que les adeptes des langages objets, et particulirement les dfenseurs de
Java se rassurent : il ny a pas besoin de SGBDO conforme lODMG pour faire persister et retrouver des objets Java et garantir la portabilit des applications. JDBC,
dvelopp par SunSoft, est un package vraiment standard pour faire persister et
retrouver via SQL des objets Java dans toute base de donnes, y compris dailleurs
certaines bases de donnes objet. Vous pouvez aussi regarder du ct de Persistant
Java et dinterfaces plus spcifiques comme JSQL.

Le standard de lODMG : ODL, OQL et OML 433

8. BIBLIOGRAPHIE
[Adiba93] Adiba M., Collet C., Objets et Bases de Donnes : Le SGBD O2, Herms,
Paris, 1993.
Cet ouvrage de 542 pages dcrit la gnration des SGBD objet et dtaille plus
particulirement le SGBD O2. Il dcrit tout le cycle dutilisation de ce SGBD et
les principaux composants du systme.
[Bancilhon89] Bancilhon F., Cluet S., Delobel C., A Query Language for an ObjectOriented Database System , In 2nd Intl. Workshop on Database Programming
Language, DBPL, p. 301-322, 1989.
Cet article introduit la premire version du langage de requtes du systme O2,
prcurseur du langage OQL. Cette version souligne les aspects fonctionnels du
langage.
[Bancilhon92] Bancilhon F., Delobel C., Kanellakis P., Building an Object-Oriented
Database System : The Story of O2, Morgan Kaufmann Pub., San Fransisco,
CA, 1992.
Ce livre est une collection darticles prsentant lhistoire, la conception et
limplmentation du systme O2, un des premiers SGBD pur objet.
[Chaudhri98] Chaudhri A.B., Workshop Report on Experiences Using Object Data
Management in the Real-World , SIGMOD Record, V. 27, n 1, p. 5-10, Mars
1998.
Cet article rsume les prsentations effectues un Worshop portant sur les
applications relles des BD objet. Il discute en particulier de quelques insuffisances dObjectStore et des multiples diffrences entre O2 et le standard ODMG.
[Ferrandina95] Ferrandina F., Meyer T., Zicari R., Ferran G., Madec J., Schema and
Database Evolution in the O2 Object Database System , Proc. of 21st Intl.
Conf. On Very Large Databases, Zurich, p. 170-181, 1995.
Cet article souligne la difficult dvolution des schmas ODL dans une base
de donnes objet. Il dcrit les algorithmes implments dans O2 pour faire voluer la base en conformit au schma.
[Fishman88] Fishman et. al., Overview of the IRIS DBMS, Hewlett-Packard Internal
Report, Palo Alto, 1988.
Cet article prsente le systme IRIS et son langage OSQL. OSQL est une version fonctionnelle dun SQL tendu aux objets. OSQL est un langage qui permet de dfinir des types abstraits comme des ensembles de fonctions, de crer
des classes dobjets accessibles par des fonctions, puis dappliquer ces fonctions en les imbriquant partir darguments ventuellement instancis. Il sagit
dun des premiers SQL tendus aux objets bas sur une approche fonctionnelle,
donc un prcurseur de OQL.

434 BASES DE DONNES : OBJET ET RELATIONNEL

[ODMG93] Cattell R. (Ed.), Object Databases : The ODMG-93 Standard, MorganKaufman, San Mato, CA, 1993.
Ce livre prsente la premire version du standard ODMG pour les bases de
donnes. Il dcrit le modle objet, le langage de dfinition ODL, le langage de
requtes OQL et les interfaces avec C++ et Smalltalk.
[ODMG97] Cattell R.G.G., Barry D., Bartels D., Berler M., Eastman J.,
Gammerman S., Jordan D., Springer A., Strickland H., Wade D., Object
Database Standard : ODMG 2.0, Morgan Kaufmann Pub., San Fransisco, CA,
1997.
Ce livre prsente la deuxime version du standard ODMG dcrit dans ce chapitre. Il inclut tous les aspects tudis et donne le dtail des spcifications de
ODL, OQL, OML C++, Smalltalk et Java.
[Won Kim95] Won Kim, Modern Database Systems, Addison-Wesley, New-York,
1995.
Cette collection darticles sur les BD objets aborde tous les aspects dun SGBD
objet, en particulier les interfaces avec les langages objet (OQL-C++) ainsi
que les promesses et dceptions des systmes purs objet.

Chapitre XIII

LOBJET-RELATIONNEL ET SQL3

1. INTRODUCTION
Le dveloppement des SGBD objet sest rapidement heurt la ncessit de conserver
la compatibilit avec lexistant. En effet, la fin des annes 80 a vu le dploiement des
SGBD relationnels et des applications client-serveur. Les utilisateurs ntaient donc
pas prts remettre en cause ces nouveaux systmes ds le dbut des annes 90.
Cependant, les tables relationnelles ne permettaient gure que la gestion de donnes
alphanumriques. Avec lavnement du Web au milieu de la dcennie 90, la ncessit
de supporter des donnes complexes au sein de la base de donnes sest amplifie.
Ces donnes complexes peuvent tre des documents textuels, des donnes gomtriques ou gographiques, audiovisuelles ou soniques. En bref, il sagit de supporter
de manire intelligente des donnes multimdia (voir figure XIII.1).
Ce chapitre est consacr ltude du modle objet-relationnel et du langage de
requtes associ SQL3. SQL3 est une extension de SQL2, dveloppe par le groupe
de normalisation ANSI X3 H2 et internationalise au niveau de lISO par le groupe
ISO/IEC JTC1/SC21/WG3. Il sagit de la nouvelle version de SQL. SQL3 comporte
beaucoup daspects nouveaux, lessentiel tant sans doute son orientation vers une
intgration douce de lobjet au relationnel. Ce chapitre traite en dtail de cette intgration et survole les autres aspects de SQL3.

436 BASES DE DONNES : OBJET ET RELATIONNEL

Types de
donnes

ABC123

Temps
1996

Figure XIII.1 : Le besoin de types de donnes multimdia

Aprs cette introduction, la section 2 motive lintgration de lobjet au relationnel, en

soulignant les forces et faiblesses du relationnel, qui justifient la fois sa conservation
et son extension. La section 3 dfinit les notions de base drives de lobjet et introduites pour tendre le relationnel. La section 4 propose une vue densemble de SQL3
et du processus de normalisation. La section 5 dtaille le support des objets en SQL3
avec de nombreux exemples. La section 6 rsume les caractristiques essentielles du
langage de programmation de procdures et fonctions SQL/PSM, appoint essentiel
SQL pour assurer la compltude en tant que langage de programmation. Nous
concluons ce chapitre en soulignant quelques points obscurs et lintrt dune fusion
entre OQL et SQL3.

2. POURQUOI INTGRER LOBJET

AU RELATIONNEL ?
Le modle relationnel prsente des points forts indiscutables, mais il a aussi des points
faibles. Lobjet rpond ces faiblesses. Do lintrt dune intgration douce.

2.1. FORCES DU MODLE RELATIONNEL

Le relationnel permet tout dabord une modlisation des donnes adapte la gestion
laide de tables dont les colonnes prennent valeurs dans des domaines alphanum-

Lobjet-relationnel et SQL3 437

riques. Le concept de table dont les lignes constituent les enregistrements successifs
est simple, bien adapt pour reprsenter par exemple des employs, des services, ou
des paiements. Avec SQL2, les domaines se sont diversifis. Les dates, les monnaies,
le temps et les intervalles de temps sont parfaitement supports.
Dans les annes 80, les SGBD relationnels se sont centrs sur le transactionnel (On
Line Transaction Processing OLTP) et sont devenus trs performants dans ce
contexte. Les annes 90 ont vu le dveloppement du dcisionnel (On Line Analysis
Processing OLAP). Le relationnel sest montr capable dintgrer la prsentation
multidimensionnelle des donnes ncessaire lOLAP. En effet, il est simple de coder
un cube 3D en table, trois colonnes mmorisant les valeurs dune dimension et la quatrime la grandeur analyse.
En bref, grce au langage assertionnel puissant que constitue le standard universel
SQL2, sa bonne adaptation aux architectures client-serveur de donnes, sa thorie
bien assise aussi bien pour la conception des bases (normalisation), loptimisation de
requtes (algbre, rcriture, modle de cots) et la gestion de transactions (concurrence, fiabilit) intgre, le relationnel sest impos dans lindustrie au cours des
annes 80.

2.2. FAIBLESSES DU MODLE RELATIONNEL

Le relationnel prsente cependant des faiblesses qui justifient son extension vers
lobjet. Tout dabord, les rgles de modlisation imposes pour structurer proprement
les donnes savrent trop restrictives.
Labsence de pointeurs visibles par lutilisateur est trs pnalisante. Dans les architectures modernes de machine o la mmoire accs directe est importante, il devient
intressant de chaner directement des donnes. Le parcours de rfrences est rapide
et permet dviter les jointures par valeurs du relationnel. Des enregistrements volumineux reprsentant de gros objets peuvent aussi tre stocks une seule fois et points
par plusieurs lignes de tables : le partage rfrentiel dobjets devient ncessaire. Par
exemple, une image sera stocke une seule fois, mais pointe par deux tuples, un dans
la table Employs, lautre dans la table Clients. Passer par une cl didentification (par
exemple, le numro de scurit sociale) ncessite un accs par jointure, opration
lourde et coteuse. En clair, il est temps de rhabiliter les pointeurs sous la forme
didentifiants dobjets invariants au sein du relationnel.
Le non-support de domaines composs impos par la premire forme normale de
Codd est inadapt aux objets complexes, par exemple aux documents structurs.
Lintroduction de champs binaires ou caractres longs (Binary Large Object BLOB,
Character Large Object CLOB) et plus gnralement de champs longs (Large
Object LOB) est insuffisante.

438 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XIII.1 : Objet long (Large Object)

Domaine de valeurs non structures constitu par des chanes de caractres (CLOB) ou de bits
(BLOB) trs longues (pouvant atteindre plusieurs giga-octets) permettant le stockage dobjets multimdia dans les colonnes de tables relationnelles.

Les objets longs prsentent deux inconvnients majeurs : ils ne sont pas structurs et
ne supportent pas les recherches associatives. La seule possibilit est de les lire
squentiellement. Ils sont donc particulirement insuffisants pour le stockage intelligent de documents structurs, o lon souhaite accder par exemple une section sans
faire dfiler tout le document. En clair, il faut pouvoir lever la contrainte datomicit
des domaines, serait-ce que pour stocker des attributs composs (par exemple
ladresse compose dune rue, dun code postal et dune ville) ou multivalus (par
exemple les points dune ligne).
La non intgration des oprations dans le modle relationnel constitue un manque.
Celui-ci rsulte dune approche traditionnelle o lon spare les traitements des donnes. Certes, les procdures stockes ont t introduites dans le relationnel pour les
besoins des architectures client-serveur, mais celles-ci restent spares des donnes.
Elles ne sont pas intgres dans le modle. Il est par exemple impossible de spcifier
des attributs cachs de lutilisateur, accessibles seulement via des oprations manipulant ces attributs privs.
Tout ceci conduit un mauvais support des applications non standard telles que la
CAO, la CFAO, les BD gographiques et les BD techniques par les SGBD relationnels. En effet, ces applications grent des objets structures complexes, composs
dlments chans souvent reprsents par des graphes. Le relationnel pur est finalement mal adapt. Il en va de mme pour le support dobjets multimdia que lon souhaite pouvoir rechercher par le contenu, par exemple des photos que lon souhaite
retrouver partir dun portrait robot.

2.3. LAPPORT DES MODLES OBJET

Les modles objet sont issus des langages objets. Ils apportent des concepts nouveaux
importants qui rpondent aux manques du relationnel, comme lidentit dobjets,
lencapsulation, lhritage et le polymorphisme.
Lidentit dobjet permet lintroduction de pointeurs invariants pour chaner les
objets entre eux. Ces possibilit de chanage rapide sont importantes pour les applications ncessitant le support de graphes dobjets. On pourra ainsi parcourir rapidement
des suite dassociations, par navigation dans la base. Par exemple, passer dun compos ses composants puis la description de ces composants ncessitera simplement
deux parcours de pointeurs, et non plus des jointures longues et coteuses.

Lobjet-relationnel et SQL3 439

Lencapsulation des donnes permet disoler certaines donnes dites prives par des
oprations et de prsenter des interfaces stables aux utilisateurs. Ceci facilite lvolution des structures de donnes qui peuvent changer sans modifier les interfaces
publiques seules visibles des utilisateurs. Au lieu doffrir des donnes directement
accessibles aux utilisateurs, le SGBD pourra offrir des services cachant ces donnes,
beaucoup plus stables et complets. Ceux-ci pourront plus facilement rester invariants
au fur et mesure de lvolution de la base de donnes.
Lhritage doprations et de structures facilite la rutilisation des types de donnes. Il permet plus gnralement ladaptation de composants son application. Les
composants pourront tre des tables, mais aussi des types de donnes abstraits, cest-dire un groupe de fonctions encapsulant des donnes caches. Il sera dailleurs possible de dfinir des oprations abstraites, qui pourront, grce au polymorphisme, porter le mme nom mais sappliquer sur des objets diffrents avec pour chaque type
dobjet un code diffrent. Cela simplifie la vie du dveloppeur dapplications qui na
plus qu se soucier doprations abstraites sans regarder les dtails dimplmentation
sur chaque type dobjet.

2.4. LE SUPPORT DOBJETS COMPLEXES

Lapport essentiel de lobjet-relationnel est sans doute le support dobjets complexes
au sein du modle. Ceci nest pas inhrent lobjet, mais plutt hrit des premires
extensions tendant faire disparatre la premire forme normale du relationnel. On
parle alors de base de donnes en non premire forme normale (NF2).
Notion XIII.2 : Non premire forme normale (Non First Normal Form NF2)
Forme normale tolrant des domaines multivalus.

Un cas particulier intressant est le modle relationnel imbriqu [Scholl86].

Notion XIII.3 : Modle relationnel imbriqu (Nested Relational Model)
Modle relationnel tendu par le fait quun domaine peut lui-mme tre valu par des tables de
mme schma.

EXEMPLE

Des services employant des employs et enregistrant des dpenses pourront

directement tre reprsents par une seule table externe imbriquant des tables
internes :
SERVICES (N INT, CHEF VARCHAR, ADRESSE VARCHAR, {EMPLOYS (NOM,
AGE)}, {DPENSES (NDEP INT, MONTANT INT, MOTIF VARCHAR)})

440 BASES DE DONNES : OBJET ET RELATIONNEL

Employs correspond une table imbrique (ensemble de tuples) de schma

(Nom, Age) pour chaque service, et de mme, Dpenses correspond une table
imbrique pour chaque service. Notons que le modle relationnel permet une
imbrication plusieurs niveaux, par exemple, Motif pourrait correspondre
une table pour chaque dpense.
Services
N

Chef

Adresse

24

Paul

Versailles

25

Patrick

Paris

Employs

Dpenses

Nom

Age

NDep

Montant

Motif

Pierre

45

2 600

Livres

Marie

37

8 700

Mission

14 500

Portable

Nom

Age

NDep

Montant

Motif

Eric

42

3 000

Livres

Julie

51

4 000

Mission

Figure XIII.2 : Exemples de relations imbriques

Le multimdia, particulirement la gomtrie, a ncessit dintroduire des attributs

multivalus plus gnraux. Comme lobjet, lobjet-relationnel offre des collections
gnriques prdfinies telles que des listes, ensembles, tableaux qui peuvent tre
imbriques pour reprsenter des objets trs compliqus. Par exemple, on pourra
dfinir une ligne comme une liste de points, chaque point tant dfini par une abscisse et une ordonne. Une rgion pourra tre dfinie par une liste de lignes ferme.
Ces possibilits sont essentielles pour la reprsentation de structures complexes.
Celles-ci peuvent tre caches par des fonctions offertes aux utilisateurs afin den
simplifier la vision. Ainsi, objets complexes et encapsulation seront souvent coupls.

3. LE MODLE OBJET-RELATIONNEL
Le modle objet-relationnel est fond sur lide dextension du modle relationnel
avec les concepts essentiels de lobjet (voir figure XIII.3). Le cur du modle reste
donc conforme au relationnel, mais lon ajoute les concepts cls de lobjet sous une
forme particulire pour faciliter lintgration des deux modles.

Lobjet-relationnel et SQL3 441

Types utilisateurs
et encapsulation

Rfrence
et identit

Relationnel

Hritage
et rutilisation

Collection
et objets complexes

Figure XIII.3 : Les extensions apportes au relationnel

3.1. LES CONCEPTS ADDITIONNELS ESSENTIELS

Les types utilisateur permettent la dfinition de types extensibles utilisables comme
des domaines, supportant lencapsulation.
Notion XIII.4 : Type de donnes utilisateur (User data type)
Type de donnes dfinissable par lutilisateur compos dune structure de donnes et doprations
encapsulant cette structure.

Le systme de type du SGBD devient donc extensible, et nest plus limit aux types
alphanumriques de base, comme avec le relationnel pur et SQL2. On pourra par
exemple dfinir des types texte, image, point, ligne, etc. Les types de donnes dfinissables par lutilisateur sont appels types abstraits (ADT) en SQL3. La notion de
type abstrait fait rfrence au fait que limplmentation est spcifique de lenvironnement : seule linterface dun type utilisateur est visible.
Notion XIII.5 : Patron de collection (Collection template)
Type de donnes gnrique permettant de supporter des attributs multivalus et de les organiser
selon un type de collection.

Les SGBD objet-relationnels offrent diffrents types de collections, tels que le tableau
dynamique, la liste, lensemble, la table, etc. Le patron LISTE(X) pourra par

442 BASES DE DONNES : OBJET ET RELATIONNEL

exemple tre instanci pour dfinir des lignes sous forme de listes de points : LIGNE
LISTE(POINT).
Notion XIII.6 : Rfrence dobjet (Object Reference)
Type de donnes particulier permettant de mmoriser ladresse invariante dun objet ou dun tuple.

Les rfrences sont les identifiants dobjets (OID) dans le modle objet-relationnel.
Elles sont en thorie des adresses logiques invariantes qui permettent de chaner directement les objets entre eux, sans passer par des valeurs ncessitant des jointures.
Notion XIII.7 : Hritage de type (Type inheritance)
Forme dhritage impliquant la possibilit de dfinir un sous-type dun type existant, celui-ci hritant
alors de la structure et des oprations du type de base.

Lhritage de type permet donc de dfinir un sous-type dun type SQL ou dun type
utilisateur. Une table correspondant un type sans opration, lobjet-relationnel permet aussi lhritage de table.
Notion XIII.8 : Hritage de table (Table inheritance)
Forme dhritage impliquant la possibilit de dfinir une sous-table dune table existante, celle-ci
hritant alors de la structure et des ventuelles oprations de la table de base.

En rsum, le modle objet-relationnel conserve donc les notions de base du relationnel (domaine, table, attribut, cl et contrainte rfrentielle) auxquelles il ajoute les
concepts de type utilisateur avec structure ventuellement prive et oprations encapsulant, de collections supportant des attributs multivalus (structure, liste, tableau,
ensemble, etc.), dhritage sur relations et types, et didentifiants dobjets permettant
les rfrences inter-tables. Les domaines peuvent dornavant tre des types utilisateurs. La figure XIII.4 illustre tous ces concepts. Deux vues sont possibles : la vue
relationnelle dans laquelle les relations sont des relations entre objets (voir
figure XIII.5), chaque colonne tant en fait value par un objet ; la vue objet (voir
figure XIII.6) o une ligne dune table peut correspondre un objet simple (un tuple)
ou complexe (un tuple avec des attributs complexes).

3.2. LES EXTENSIONS DU LANGAGE DE REQUTES

Au-del du modle, il est ncessaire dtendre le langage de manipulation de donnes
pour supporter les nouvelles avances du langage de dfinition. SQL3 va donc comporter un langage de requtes tendu avec notamment les appels doprations en
rsultat et en qualification, la surcharge des oprateurs de base de SQL (par exemple

Lobjet-relationnel et SQL3 443

OBJET
Accident

Rapport

Photo

Polymorphisme

Types
utilisateurs

RELATIONNEL
Domaine
Table
Attribut
Cl
Rfrence

Opration

134

Collections
219

Identifiant
037

Hritage

Figure XIII.5 : Une relation entre objets

Figure XIII.4 : Les concepts de lobjet-relationnel

Police

24

Nom

Paul

Adresse

Paris

Conducteurs
Conducteur

ge

Paul

45

Robert

17

Accidents
Accident

Rapport

Photo

134

219

037

Objet Police

Figure XIII.6 : Un objet complexe dans une table

laddition), le support automatique de lhritage, le parcours de rfrences, la constitution de tables imbriques en rsultat, etc. Nous tudierons ces diffrentes fonctionnalits laide dexemples.

444 BASES DE DONNES : OBJET ET RELATIONNEL

4. VUE DENSEMBLE DE SQL3

SQL3 est une spcification volumineuse, qui va bien au-del de lobjet-relationnel.
Nous examinons dans cette section ses principaux composants.

4.1. LE PROCESSUS DE NORMALISATION

Au-del du groupe ANSI nord-amricain trs actif, la normalisation est conduite par
un groupe international dnomm ISO/IEC JTC1/SC 21/WG3 DBL, DBL signifiant
Database Language. Les pays actifs sont essentiellement lAustralie, le Brsil, le
Canada, la France, lAllemagne, le Japon, la Core, la Hollande, le Royaume-Uni et
bien sr les tats-Unis. Lessentiel du travail est bien prpar au niveau du groupe
ANSI X3H2 (http://www.ansi.org) dont Jim Melton est le prsident. Ce groupe a dj
ralis le standard SQL2 prsent dans la partie relationnelle. Les standards accepts
taient contrls aux tats-Unis par le NIST (http://ncsl.nist.gov) qui dfinissait des
programmes de tests de conformit. Ceux-ci existent partiellement pour SQL2 mais
pas pour SQL3. Depuis 1996, le congrs amricain a supprim les crdits du NIST si
bien quil ny a plus de programmes de validation esprs

4.2. LES COMPOSANTS ET LE PLANNING

Alors que SQL2 tait un unique document [SQL92], SQL3 a t divis en composants
pour en faciliter la lisibilit et la manipulation, lensemble faisant plus de 1 500 pages.
Les composants considrs sont brivement dcrits dans le tableau reprsent
figure XIII.7.
Le planning de SQL3 a t dcal a plusieurs reprises, ces dcalages tmoignant de la
difficult et de lampleur de la tche. Les parties 1 7 de SQL sont ltat de
brouillons internationaux (Draft International Standard) depuis fin 1997. Ils devraient
devenir de vritables standards fin 1998 ou en 1999. Les deux derniers sont prvus
pour lan 2000.
Au-del de SQL3, dautres composants sont prvus tels SQL/MM pour la spcification de types utilisateurs multimdia et SQL/RDA pour la spcification du protocole
RDA de transfert de donnes entre client et serveur. On parle dj de SQL4, sans
doute pour aprs lan 2000.

Lobjet-relationnel et SQL3 445

Partie

Contenu

Titre

Description

le cadre

SQL/Framework

Une description non-technique

de la faon dont le document
est structur et une dfinition
des concepts communs toutes
les parties.

les fondements

SQL/Foundation

Le noyau de base, incluant les types

de donnes utilisateurs et le modle
objet-relationnel.

linterface client

SQL/CLI

Linterface dappel client permet

le dialogue client-serveur pour laccs
aux donnes via SQL2 puis SQL3.

les procdures stockes

SQL/PSM

Le langage de spcification
de procdures stockes.

lintgration
SQL/Bindings
aux langages classiques

Les liens SQL dynamique

et embedded SQL repris de SQL-92
et tendus SQL3.

la gestion de transactions SQL/Transaction

Une spcification de linterface XA

pour moniteur transactionnel distribu.

la gestion du temps

SQL/Temporal

Le support du temps, des intervalles

temporels et des sries temporelles.

abandonn

laccs aux donnes

externes

SQL/MED

Lutilisation de SQL pour accder

des donnes non-SQL.

10

lintgration
aux langages objet

SQL/OBJ

Lutilisation de SQL depuis un langage

objet, tel C++, Smalltalk ou Java.

Figure XIII.7 : Les composants de SQL3

4.3. LA BASE
Le composant 2 contient lessentiel du langage SQL3, en particulier les fonctionnalits de base pour dfinir les autres composants (Basic SQL/CLI capabilities, Basic
SQL/PSM capabilities), les dclencheurs (Triggers), les types utilisateurs appels

446 BASES DE DONNES : OBJET ET RELATIONNEL

types abstraits (Abstract Data Types) et les fonctionnalits orientes objets que nous
allons tudier en dtail ci-dessous. Un mot sur les dclencheurs : bien que partie intgrante du relationnel tudie en tant que telle au chapitre VIII, les dclencheurs ne
sont normaliss que dans SQL3. Il sagit l de combler une lacune de la normalisation.

5. LE SUPPORT DES OBJETS

Dans cette section, nous allons prsenter lessentiel des commandes composant les
fonctionnalits objet de SQL3 : dfinition de types abstraits, support dobjets complexes, hritage de type et de table. Pour chaque commande, nous donnons la syntaxe
simplifie et quelques exemples.

5.1. LES TYPES ABSTRAITS

5.1.1. Principes
La premire nouveaut de SQL3 est lapparition dune commande CREATE TYPE.
Au-del des types classiques (numriques, caractres, date) de SQL, il devient possible de crer des types dpendant de lapplication, multimdia par exemple (voir
figure XIII.8).

Types
simples

Numrique
Caractres
Date

245
Georges
20-Dec-98

Texte
Types
multimdia

Spatial
Image
Vido
Spcialis

Spcifique application

Figure XIII.8 : Exemples de types de donnes extensibles

Une instance dun type peut tre un objet ou une valeur. Un objet possde alors un
OID et peut tre rfrenc. Une valeur peut simplement tre copie dans une ligne
dune table. Un type possde en gnral des colonnes, soit directement visibles, soit

Lobjet-relationnel et SQL3 447

caches et accessibles seulement par des fonctions encapsulant le type. Les oprateurs
arithmtiques de SQL (+, *, , /) peuvent tre redfinis au niveau dun type. Par
exemple, on redfinira laddition pour les nombres complexes. Enfin, un type peut
possder des clauses de comparaison (=, <) permettant dordonner les valeurs et peut
tre reprsent sous la forme dun autre type, une chane de caractres par exemple.

5.1.2. Syntaxe
La syntaxe de la commande de dclaration de type est la suivante :
CREATE [DISTINCT] TYPE <NOM ADT> [<OPTION OID>] [<CLAUSE SOUS-TYPE>]
[AS] (<CORPS DE LADT>)

Le mot cl DISTINCT est utilis pour renommer un type de base existant dj, par
exemple dans la commande :
CREATE DISTINCT TYPE EURO AS (DECIMAL(9,2)

La clause :
<OPTION OID> ::= WITH OID VISIBLE

permet de prciser la visibilit de lOID pour chaque instance (objet). Par dfaut, une
instance de type est une valeur sans OID. Cette clause semble plus ou moins avoir disparue de la dernire version de SQL3, le choix tant report sur les implmentations.
La clause :
<CLAUSE SOUS-TYPE> ::= UNDER <SUPERTYPE>[,<SUPERTYPE>]

permet de spcifier les super-types dont le type hrite. Il y a possibilit dhritage

multiple avec rsolution explicite des conflits.
La clause <CORPS

DE LADT>

se compose dune ou plusieurs clauses membres :

<CLAUSES MEMBRES> ::=

< DFINITION DE COLONNE >
|
< CLAUSE EGALE >
|
< CLAUSE INFERIEURE>
|
< CLAUSE CAST >
|
< DCLARATION DE FONCTION >
|
< DCLARATION DOPRATEUR >

La dfinition de colonne permet de spcifier les attributs du type sous la forme <NOM>
<TYPE>. Un type peut bien sr tre un type de base ou un type prcdemment cr par
une commande CREATE TYPE. Un attribut peut tre priv ou public, comme en
C++. La clause gale permet de dfinir lgalit de deux instances du type, alors que
la clause infrieure dfinit le comparateur <, important pour comparer et ordonner les
valeurs du type. La clause CAST permet de convertir le type dans un autre type.
Plusieurs clauses CAST sont possibles.

448 BASES DE DONNES : OBJET ET RELATIONNEL

Une dclaration de fonction permet de dfinir les fonctions publiques qui encapsulent
le type. Il existe diffrents types de fonctions : les constructeurs permettent de
construire des instances du type ; ils portent en gnral le nom du type ; les acteurs
agissent sur une instance en manipulant les colonnes du type ; parmi les acteurs, il est
possible de distinguer les observateurs qui ne font que lire ltat et les mutateurs qui
le modifient ; les destructeurs dtruisent les instances et doivent tre appels explicitement pour rcuprer la place disque (pas de ramasse-miettes). Plus prcisment, la
syntaxe dune dfinition de fonction est la suivante :
<DCLARATION DE FONCTION> ::=
[<FUNCTION TYPE>] FUNCTION <FUNCTION NAME> <PARAMETER LIST>
RETURNS <FUNCTION RESULTS>
{ <SQL PROCEDURE> | <FILE NAME> } END FUNCTION

Le type est dfini par :

<FUNCTION TYPE> ::= CONSTRUCTOR | ACTOR | DESTRUCTOR

Les fonctions SQL3 ne sont pas forcment associes un type ; elles peuvent aussi
tre associes une base ou une table. Elles peuvent tre programmes en SQL, en
SQL/PSM (voir ci-dessous) ou dans un langage externe comme COBOL, C, C++ ou
Java. Comme en C++, un oprateur est une fonction portant un nom particulier et
dclare comme oprateur.

5.1.3. Quelques exemples

Voici quelques exemples de cration de types :
1. Type avec OID pouvant tre utilis comme un objet :
CREATE TYPE PHONE WITH OID VISIBLE (PAYS VARCHAR, ZONE VARCHAR,
NOMBRE INT, DESCRIPTION CHAR(20))

2. Type sans rfrence :

CREATE TYPE PERSONNE (NSS INT, NOM VARCHAR, TEL PHONE)

3. Sous-type :
CREATE TYPE TUDIANT UNDER PERSONNE (CYCLE VARCHAR, ANNE INT)

4. Type numr :
CREATE TYPE JOUR-OUVR (LUN, MAR, MER, JEU, VEN);

5. Type avec OID et fonction :

CREATE TYPE EMPLOY WITH OID VISIBLE
(NOM CHAR(10), DATENAIS DATE, REPOS JOUR-OUVR, SALAIRE FLOAT,
FUNCTION AGE (E EMPLOY)RETURNS (INT)
{ CALCUL DE LAGE DE E }
END FUNCTION;);

6. Autre type sans OID avec fonction :

CREATE TYPE ADRESSE WITHOUT OID

Lobjet-relationnel et SQL3 449

(RUE CHAR(20), CODEPOST INT, VILLE CHAR(10),

FUNCTION DEPT(A ADRESSE) RETURNS (VARCHAR) END FUNCTION);

7. Cration de procdure SQL de mise jour associe au type employ :

CREATE PROCEDURE AUGMENTER (E EMPLOY, MONTANT MONEY)
{ UPDATE EMPLOY SET SALAIRE = SALAIRE + MONTANT WHERE EMPLOY.OID = E}
END PROCEDURE

5.2. LES CONSTRUCTEURS DOBJETS COMPLEXES

SQL3 supporte la construction dobjets complexes par le biais de types collection paramtrs. Ces types gnriques, appels patrons de collections, doivent tre
fournis comme une bibliothque avec le compilateur SQL3. Celui-ci doit assurer la
gnricit et en particulier la possibilit de dclarer des collections de types dobjets
ou de valeurs quelconques. Chaque patron de collection fournit des interfaces spcifiques pour accder aux lments de la collection.
Tout environnement SQL3 doit offrir les patrons de base SET(T), MULTISET(T) et
LIST(T). Un multiset, encore appel bag, se comporte comme un ensemble mais
permet de grer des doubles. Par exemple, il est possible de dfinir un type personne
avec une liste de prnoms et un ensemble de tlphones comme suit :
CREATE TYPE PERSONNE WITH OID VISIBLE
(NSS INT, NOM VARCHAR, PRNOMS LIST(VARCHAR), TEL SET(PHONE)).

Il est aussi possible de crer un ensemble de personnes :

CREATE TYPE PERSONNES (CONTENU SET (PERSONNE))

ou un ensemble didentifiants de personnes :

CREATE TYPE RPERSONNES (CONTENU SET(REF(PERSONNE))).

Au-del des types de collections SET, LIST et MULTISET, SQL3 propose des types
additionnels multiples : piles (stack), files (queue), tableaux dynamiques (varray),
tableaux inserables (iarray) pour grer des textes par exemple. Un tableau dynamique
peut grandir par la fin, alors quun tableau insrable peut aussi grandir par insertion
partir dune position intermdiaire (il peut donc grandir par le milieu). Ces types de
collections sont seulement optionnels : ils ne sont pas intgrs dans le langage de base
mais peuvent tre ajouts.
De manire gnrale, il est possible de rfrencer des objets via des OID mmoriss
comme valeurs dattributs. De tels attributs sont dclars rfrences (REF) comme
dans lexemple ci-dessous :
CREATE TYPE VOITURE (NUMRO CHAR(9), COULEUR VARCHAR,
PROPRITAIRE REF(PERSONNE))

450 BASES DE DONNES : OBJET ET RELATIONNEL

5.3. LES TABLES

Les tables SQL restent inchanges, ceci prs que le domaine dun attribut peut maintenant tre un type cr par la commande CREATE TYPE. De plus, des fonctions peuvent
tre dfinies au niveau dune table pour encapsuler les tuples vus comme des objets.
Aussi, lhritage de table qui permet de rutiliser une dfinition de table est possible.
Par exemple, la table reprsente figure XIII.5 sera simplement cre par la commande :
CREATE TABLE ACCIDENTS (ACCIDENT INT, RAPPORT TEXT, PHOTO IMAGE)

en supposant dfinis les types TEXT (texte libre) et IMAGE, qui sont gnralement
fournis avec un SGBD objet-relationnel, comme nous le verrons plus loin.
La table de la figure XIII.6 pourra tre dfinie partir des mmes types avec en plus :
CREATE TYPE CONDUCTEUR (CONDUCTEUR VARCHAR, AGE INT)
CREATE TYPE ACCIDENT (ACCIDENT INT, RAPPORT TEXT, PHOTO IMAGE)

par la commande :
CREATE TABLE POLICE (NPOLICE INT, NOM VARCHAR, ADRESSE ADRESSE,
CONDUCTEURS SET(CONDUCTEUR), ACCIDENTS LIST(ACCIDENT)).

SQL3 donne aussi des facilits pour passer dun type une table de tuples de ce type
et rciproquement, dune table au type correspondant.
Par exemple, en utilisant le type EMPLOY dfini ci-dessus, il est possible de dfinir
simplement une table demploys par la commande :
CREATE TABLE EMPLOYS OF EMPLOY ;

En dfinissant une table VINS, il sera possible de dfinir le type VIN compos des
mmes attributs comme suit :
CREATE TABLE VINS(NV INT, CRU VARCHAR, DEGR FLOAT(5.2))
OF NEW TYPE VIN ;

Comme mentionn, lhritage de table qui recopie la structure est possible par la
clause :
CREATE TABLE <TABLE> UNDER <TABLE> [WITH (LISTE DATTRIBUTS TYPS)].

La liste des attributs typs permet dajouter les attributs spcifiques la sous-table.
Par exemple, une table de vins millsim pourra tre cre par :
CREATE TABLE VINSMILL UNDER VINS WITH (MILLSIME INT, QUALIT VARCHAR).

5.4. LAPPEL DE FONCTIONS ET DOPRATEURS

DANS LES REQUTES
Le langage de requtes est tendu afin de supporter les constructions nouvelles du
modle. Lextension essentielle consiste permettre lappel de fonctions dans les

Lobjet-relationnel et SQL3 451

termes SQL, qui peuvent figurer dans les expressions de valeurs slectionnes ou dans
les prdicats de recherche. Une fonction sapplique laide de la notation parenthse
sur des termes du type des arguments spcifis.
Considrons par exemple la table demploys contenant des instances du type EMPLOY
dfinit ci-dessus. La requte suivante retrouve le nom et lge des employs de moins
de 35 ans :
SELECT E.NOM, AGE(E)
FROM EMPLOYS E
WHERE AGE(E) < 35;

La notation pointe applique au premier argument est aussi utilisable pour invoquer
les fonctions :
SELECT E.NOM, E..AGE()
FROM EMPLOYS E
WHERE E..AGE() < 35;

Il sagit dun artifice syntaxique, la dernire version utilisant dailleurs la double notation pointe (..) pour les fonctions et attributs composs, la notation pointe simple (.)
tant rserve au SQL de base (accs une colonne usuelle de tuple).
Au-del des fonctions, SQL3 permet aussi laccs aux attributs composs par la notation
pointe. Supposons par exemple une table demploys localiss dfinies comme suit :
CREATE TABLE EMPLOYSLOC UNDER EMPLOYS WITH (ADRESS ADRESSE).

La requte suivante permet de retrouver le nom et le jour de repos des employs des
Bouches-du-Rhne habitant Marseille :
SELECT NOM, REPOS
FROM EMPLOYSLOC E
WHERE DEPT(E.ADRESS) = BOUCHES DU RHONE
AND E.ADRESS..VILLE = MARSEILLE;

Notons dans la requte ci-dessus lusage de fonctions pour extraire le dpartement

partir du code postal et lusage de la notation pointe pour extraire un champ compos. Nous prfrerons utiliser partout la notation pointe ; il faut cependant distinguer fonction et accs attribut par la prsence de parenthses.
Afin dillustrer plus compltement, supposons dfinis un type point et une fonction
distance entre deux points comme suit :
TYPE POINT (ABSCISSE X, ORDONNE Y,
FUNCTION DISTANCE(P1 POINT, P2 POINT) RETURN (REAL)) ;

Considrons une implmentation des employs par la table :

EMPLOYS (MUNEMP INT, NOM VARCHAR, ADRESS ADRESSE, POSITION POINT) ;

La requte suivante recherche alors les noms et adresses de tous les employs moins
de 100 units de distance (par exemple le mtre) de lemploy Georges :

452 BASES DE DONNES : OBJET ET RELATIONNEL

SELECT E.NOM, E.ADRESS

FROM EMPLOYS G, EMPLOYS E
WHERE G.NAME = GEORGES AND DISTANCE(G.POSITION,E.POSITION) < 100.

Supposons de plus dfini le type CERCLE comme suit :

TYPE CERCLE (CENTRE POINT, RAYON REAL,
CONSTRUCTOR FUNCTION CERCLE(C POINT, R REAL) RETURN (CERCLE))

Ajoutons une fonction boolenne CONTIENT au type point :

CREATE FUNCTION CONTIENT (P POINT, C CERCLE)
{ CODE DE LA FONCTION } RETURN (BOLEAN)
END FUNCTION.

La question suivante retrouve les employs dont la position est contenu dans un cercle
de rayon 100 autour de lemploy Georges :
SELECT E.NAME, E.ADRESS
FROM EMPLOYS G, EMPLOYS E
WHERE EMPLOYS.NOM = GEORGES AND
CONTIENT(E.POSITION, CERCLE(G.POSITION,1));

Les deux requtes prcdentes sont de fait quivalents et gnrent les mmes
rponses.

5.5. LE PARCOURS DE RFRENCE

SQL3 permet aussi de traverser les associations reprsentes par des attributs de type
rfrences.
Ces attributs peuvent tre considrs comme du type particulier rfrence, sur lequel
il est possible dappliquer les fonctions Ref pour obtenir la valeur de lOID et DeRef
pour obtenir lobjet point. Afin de simplifier lcriture, DeRef peut tre remplace
par la notation . Celle-ci permet donc les parcours de chemins. On peut ainsi crire
des requtes mlangeant la notation simple point (accs un attribut), double point
(accs un attribut ADT compos) et flche (parcours de chemins). Esprons que la
notation point simple pourra tre utilise partout comme une amlioration
syntaxique !
Considrons le type VOITURE dj dfini ci-dessus comme suit :
CREATE TYPE VOITURE (NUMRO CHAR(9), COULEUR VARCHAR,
PROPRITAIRE REF(PERSONNE)).

Crons une table de voitures :

CREATE TABLE VOITURES OF TYPE VOITURE.

La requte suivante recherche les noms des propritaires de voitures rouges habitant
Paris :

Lobjet-relationnel et SQL3 453

SELECT V.PROPRIETAIRENOM
FROM VOITURES V
WHERE V.COULEUR = ROUGE AND V.PROPRIETAIREADRESSE..VILLE = PARIS.

SQL3 permet de multiples notations abrges. En particulier, il est possible dviter

de rpter des prfixes de chemins avec la notation pointe suivie de parenthses. Par
exemple, la requte suivante recherche les numros des voitures dont le propritaire
habite les Champs-Elyss Paris et a pour prnom Georges :
SELECT V.NUMRO
FROM VOITURES V
WHERE V.PROPRITAIRE(ADRESSE..(VILLE = PARIS
AND RUE = CHAMPS ELYSS) AND PRNOM = GEORGES).

5.6. LA RECHERCHE EN COLLECTIONS

Les collections de base sont donc les ensembles, listes et sacs. Ces constructeurs de
collections peuvent tre appliqus sur tout type dj dfini. Les collections sont rendues permanentes en qualit dattributs de tables. La construction TABLE est propose pour transformer une collection en table et lutiliser derrire un FROM comme une
vritable table. Toute collection peut tre utilise la place dune table prcde de ce
mot cl TABLE. Par exemple, supposons lajout dune colonne PASSETEMPS la table
des personnes value par un ensemble de chanes de caractres :
ALTER TABLE PERSONNES ADD COLUMN PASSETEMPS SET(VARCHAR).

La requte suivante retrouve les rfrences des personnes ayant pour passe-temps le
vlo :
SELECT REF(P)
FROM PERSONNES P
WHERE VLO IN
SELECT *
FROM TABLE (P.PASSETEMPS).

Plus complexe, la requte suivante recherche les numros des polices dassurance
dont un accident contient un rapport avec le mot cl Pont de lAlma :
SELECT P.NPOLICE
FROM POLICE P, TABLE P.ACCIDENTS A, TABLE A.RAPPORT..KEYWORDS M
WHERE M = PONT DE LALMA.

Cette requte suppose la disponibilit de la fonction KEYWORDS sur le type TEXT du rapport qui dlivre une liste de mots cls. Nous tablons tout dabord la liste des accidents,
puis la liste des mots cls du rapport de chaque accident. Ceci donne donc une sorte
dexpression de chemins multivalus. SQL3 est donc trs puissant !

454 BASES DE DONNES : OBJET ET RELATIONNEL

5.7. RECHERCHE ET HRITAGE

Lhritage de tables est pris en compte au niveau des requtes. Ainsi, lorsquune table
possde des sous-tables, la recherche dans la table retrouve toutes les lignes qui qualifient au critre de recherche, aussi bien dans la table que dans les sous-tables
Par exemple, considrons la table BUVEURS dfinie comme suit :
CREATE TABLE BUVEURS UNDER PERSONNES WITH ETAT ENUM(NORMAL,IVRE).

La recherche des personnes de prnom Georges par la requte :

SELECT NOM, PRNOM, ADRESSE
FROM PERSONNES
WHERE PRNOM = GEORGES

retournera la fois les personnes et les buveurs de prnom Georges.

6. LE LANGAGE DE PROGRAMMATION
PSM
Le composant PSM dfinit un L4G adapt SQL. Il a t adopt tout dabord dans le
cadre SQL2, puis tendu SQL3.

6.1. MODULES, FONCTIONS ET PROCDURES

SQL/PSM (Persistent Store Modules) est un langage de programmation de modules
persistants et stocks dans la base de donnes [Melton98]. Les modules sont crs et
dtruits par des instructions spciales CREATE MODULE et DROP MODULE. Un
module se compose de procdures et/ou de fonctions. Il est possible de crer directement des procdures (CREATE PROCEDURE) ou des fonctions (CREATE FUNCTION) non contenues dans un module. Un module est associ un schma de base de
donnes sur lequel peuvent tre dfinies des autorisations et des tables temporaires. Il
est aussi possible de dfinir des curseurs partags entre les procdures et fonctions
composantes.
SQL/PSM parachve SQL pour en faire un langage complet. Cependant, il est possible dcrire des procdures stockes en pur SQL ou dans un langage pour lequel
lintgration avec SQL est dfinie (ADA, C, COBOL, FORTRAN, PASCAL, PL/I et
MUMPS). Pour ces langages, PSM permet de dfinir les paramtres dentre et de
retour des procdures (mots cls IN pour les paramtres dentre et OUT pour ceux de

Lobjet-relationnel et SQL3 455

sortie) ou des fonctions (clause RETURN <type>), Ces procdures sont en gnral
invoques depuis des programmes htes par des ordres EXEC SQL plus ou moins
spcifiques du langage hte, ou directement depuis dautres procdures PSM par des
ordres CALL <procdure> ou des appels directs de fonctions.

6.2. LES ORDRES ESSENTIELS

Lintrt essentiel de SQL/PSM est de fournir un langage de programmation homogne avec SQL et manipulant les mmes types de donnes. Ce langage comporte des
dclarations de variables, des assignations, des conditionnels CASE, IF, des boucles
LOOP, REPEAT, WHILE, FOR et des traitements derreurs et exceptions SIGNAL,
RESIGNAL.
Une dclaration de variable est analogue une dclaration de colonne en SQL :
<DECLARATION DE VARIABLE> ::= DECLARE <VARIABLE> <TYPE> [DEFAULT
<VALEUR>]

Par exemple, une dclaration possible est :

DECLARE PRIX INT DEFAULT 0 ;

Une assignation seffectue par une clause SET suivie dune expression de valeur
conforme SQL, ou par lassignation du rsultat dune requte dans une variable. Par
exemple :
DECLARE MOYENNE DECIMAL(7.2)
SELECT AVG(SALAIRE) INTO MOYENNE FROM EMPLOYS

assigne le rsultat de la requte la variable MOYENNE.

Lordre CASE permet de tester diffrents cas de valeurs dune expression de valeur en
paramtre du CASE (expression de valeur1) ou de plusieurs expressions de valeurs
boolennes :
<ORDRE CASE> ::=
CASE [<EXPRESSION DE VALEUR1>]
WHEN <EXPRESSION DE VALEUR2 > THEN <ORDRE SQL> ;
[WHEN <EXPRESSION DE VALEUR> THEN <ORDRE SQL> ;]
ELSE <ORDRE SQL> ;
END CASE

Par exemple :
CASE MOYENNE
WHEN <100 THEN CALL PROC1 ;
WHEN = 100 THEN CALL PROC2 ;
ELSE CALL PROC3 ;
END CASE

permet de traiter diffrents cas de la variable MOYENNE.

456 BASES DE DONNES : OBJET ET RELATIONNEL

Les boucles LOOP, REPEAT et WHILE sont des boucles de calculs en mmoire classiques, qui ne font pas directement appel la base. La boucle FOR permet au contraire
de parcourir le rsultat dune requte par le biais dun curseur. Sa syntaxe simplifie
est la suivante :
<ORDRE FOR> ::=
[<TIQUETTE> :]FOR <NOM DE BOUCLE>
AS [<NOM DE CURSEUR> CURSEUR FOR] <SPECIFICATION DE CURSEUR>
DO
<ORDRE SQL>
END FOR <TIQUETTE> ;

Ltiquette permet de rfrencer la boucle FOR. Le nom de boucle sert de qualifiant

pour les colonnes de la table virtuelle correspondant au curseur, afin de les distinguer
si ncessaire. Le nom de curseur est optionnel pour permettre la rutilisation du curseur. Une dfinition de curseur est classique en SQL : il sagit en gnral dune
requte.

6.3. QUELQUES EXEMPLES

Voici la syntaxe des constructions essentielles du langage et un exemple de procdure
et de fonction. Nous travaillons sur la base des vins composes des tables :
VINS (NV INT, CRU VARCHAR, MILL INT, DEGR FLOAT(5.2))
COMMANDES (NCO INT, NV INT, DAT DATE, QUANTIT INT)

Une procdure pour calculer la variance des quantits commandes dun cru donn en
paramtre peut tre dfinie comme suit :
CREATE PROCEDURE (IN C VARCHAR,
OUT VARIANCE DECIMAL(10.2))
BEGIN
DECLARE MOYENNE DECIMAL(10.2) ;
VARIANCE = 0 ;
SELECT AVG(QUANTITE) INTO MOYENNE
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C ;
BOUCLE1:
FOR M AS SELECT NCO, QUANTIT
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C
DO
SET VARIANCE = VARIANCE+(M.QUANTITE MOYENNE)**2
END FOR BOUCLE1 ;
END

Tout SQL est bien sr intgr PSM. Il serait possible dutiliser un curseur et une
boucle WHILE avec un FETCH dans la boucle la place de la boucle FOR.

Lobjet-relationnel et SQL3 457

Pour montrer la compltude du langage, nous dfinissons la fonction

factorielle comme suit :
CREATE FUNCTION FACTORIELLE (N INT)
RETURNS INT
DETERMINISTIC
BEGIN
DECLARE FAC INT DEFAULT 1 ;
DECLARE I INT ;
SET I = N ;
WHILE I > 1 DO
FAC = FAC*I ;
I = I-1 ;
END WHILE ;
RETURN FAC ;
END

Dautres types de boucles peuvent bien sr tre utiliss pour calculer cette fonction
[Melton98].

6.4. PLACE DE PSM DANS LE STANDARD SQL

SQL/PSM est un standard international dans sa version SQL2. Il a t intgr en 1996
au standard SQL2. Une version plus complte est en cours de spcification pour
SQL3. Cette version prsentera lavantage de pouvoir utiliser les types abstraits et les
collections de SQL3 dans le langage de programmation. SQL/PSM est assez proche
des langages de quatrime gnration de systmes tels quORACLE, INFORMIX ou
SYBASE. Malheureusement, aucun systme nimplmente actuellement exactement
PSM.

7. CONCLUSION
SQL3 est un standard en volution. Comme nous lavons vu, les composants ne sont
pas tous au mme niveau davancement. La plupart sont au stade de brouillons internationaux, et vont donc subir encore des modifications. Lensemble devrait tre termin vers lan 2000.
SQL3 se situe, au moins pour la partie objet et les interfaces avec les langages objet,
comme un concurrent de lODMG. Il est support par tous les grands constructeurs,
comme IBM, Oracle et Sybase, et est impliqu dans un processus de standardisation
international. Au contraire, lODMG est un accord entre quelques constructeurs de

458 BASES DE DONNES : OBJET ET RELATIONNEL

SGBD objet autour dun langage pur objet. LODMG traite bien les aspects collections et, dans une moindre mesure, traverse de chemins. Les deux propositions pourraient donc apparatre comme complmentaires, condition de converger. Il existe
dailleurs un accord entre les groupes ANSI X3 H2 responsable de SQL et ODMG
pour explorer la convergence. Souhaitons que cet accord aboutisse.
Dautres, comme Stonebraker [Stonebraker96], pensent plutt que les bases de donnes objet ont un crneau dapplication diffrent de celui des bases de donnes objetrelationnel. Les premires seraient plutt orientes vers les applications crites en
C++ ou Java, naviguant dans les bases mais ne formulant pas de questions complexes
sur de gros volumes de donnes persistantes. Au contraire, les bases de donnes objetrelationnel profiteraient de lorientation disque du relationnel et seraient capables de
supporter des questions complexes sur des donnes complexes. La figure XIII.9
rsume ce point de vue. Il est possible de mesurer la complexit des requtes en
nombre de jointures et agrgats, la complexit des donnes en nombre dassociations.
Cependant, lvolution des systmes objet vers la compatibilit SQL, et donc vers
lobjet-relationnel, pousse par le march, ne plaide gure pour la validit de ce
tableau.
Complexit
des requtes

Relationnel

O
Obbjjeett--rreellaattiioonnn e l
ne l

Relationnel

Objet

Complexit
des donnes

Figure XIII.9 : Relationnel, Objet ou Objet-Relationnel ?

Et aprs SQL3 ? On parle dj de SQL4, notamment pour les composants orients

applications ou mtiers. Il est en effet possible, voire souhaitable, de standardiser les
types de donnes pour des crneaux dapplications, tels le texte libre, la gographie ou
le multimdia. Nous tudierons plus loin ces types de donnes multimdia qui sont
dactualit. Au-del, on peut aussi penser dvelopper des types pour la CAO, la
finance, lassurance ou lexploration ptrolire par exemple. On aboutira ainsi des
parties de schmas rutilisables, complment souhaitable dobjets mtiers. Beaucoup
de travail reste faire. Reste savoir si SQL est le cadre adquat, et sil nest pas dj
trop complexe pour tre tendu.

Lobjet-relationnel et SQL3 459

8. BIBLIOGRAPHIE
[Darwen95] Darwen H., Date, Introducing the Third Manifesto , Database
Programming & Design Journal, C-J.vol. 1, n 8, p. 25-35, Jan. 1995.
Cet article plaide pour le modle objet-relationnel vu comme une extension
naturelle du relationnel, tel que propos par Codd (et Date). Pour C. Date,
lapport essentiel utile du modle objet est la possibilit de dfinir des types de
donnes utilisateur. En clair, aucune modification nest ncessaire au modle
relationnel qui avait dj le concept de domaine : il suffit douvrir les domaines
et de les rendre extensibles.
[Gardarin89] Gardarin G., Cheiney J.P., Kiernan J., Pastre D., Managing Complex
Objects in an Extensible DBMS , 15th Very Large Data Bases International
Conference, Morgan Kaufman Pub., Amsterdam, Pays-Bas, aot 1989.
Une prsentation dtaille du support dobjets complexes dans le SGBD extensible Sabrina. Ce systme est driv du SGBD relationnel SABRE et fut lun des
premiers SGBD supportes des types abstraits comme domaines dattributs. Il
a ensuite volu vers un SGBD gographique (GoSabrina) qui fut commercialis par la socit INFOSYS.
[Gardarin92] Gardarin G., Valduriez P., ESQL2: An Object-Oriented SQL with FLogic Semantics , 8th Data Engineering International Conf., Phnix, Arizona,
Feb. 1992.
Cet article dcrit le langage ESQL2, prcurseur de SQL3 compatible avec
SQL2, permettant dinterroger la fois des bases de donnes objets et relationnelles. Le langage supporte des relations rfrenant des objets complexes.
Une notation fonctionnelle est utilise pour les parcours de chemins et les
applications de mthodes. Une version plus labore de ESQL2 avec classes et
relations a t spcifie dans le projet EDS. La smantique base sur la FLogic (une logique pour objets) illustre les rapports entre les modles objets et
logiques.
[Godfrey98] Godfrey M., Mayr T., Seshadri P., von Eicken T., Secure and Portable
Database Extensibility , Proc. of the 1998 ACM SIGMOD Intl. Conf. On
Management of Data, ACM Pub. SIGMOD Record vol. 27, n 2, p. 390-401,
Juin 1998.
Cet article dcrit limplmentation de types abstraits dans le SGBD PREDATOR
en Java. Il montre lintrt de fonctions sres et portables, mais souligne aussi les
difficults de performance par comparaison une implmentation en C++.
[Haas90] Haas L., Chang W., Lohman G.M., McPherson J., Wilms P.F., Lapis G.,
Lindsay B., Pirahesh H., Carey M., Shekita E., Starburst Mid-Flight : As the
Dust Clears , IEEE Transactions on Knowledge and Data Engineering, vol. 2,
n 1, Mars 1990.

460 BASES DE DONNES : OBJET ET RELATIONNEL

Cet article dcrit Starburst, un des premiers SGBD objet-relationnel. Starbust a

t implment IBM Almaden, et fut un des prcurseurs de DB2 Universal
Server. Il a conduit de nombreux dveloppements autour de lobjet-relationnel, notamment des techniques dvaluation de requtes.
[Melton98] Melton J., Understanding SQLs Stored Procedures, Morgan Kaufman
Pub., 1998.
Ce livre prsente la version 96 de PSM, intgre SQL2. Il est trs complet,
aborde les diffrents aspects (concepts de base, cration de modules et procdures, routines externes, polymorphisme, contrles, extensions prvues) et
donne un exemple dapplication.
[Scholl86] Scholl M., Abiteboul S., Bancilhon F., Bidoit N., Gamerman S.,
Plateau D., Richard P., Verroust A., VERSO: A Database Machine Based On
Nested Relations. Nested Relations and Complex Objects , Intl. Workshop
Theory and Applications of Nested Relations and Complex Objects, Darmstadt,
Germany, April 1987, in Lecture Notes in Computer Science, vol. 361, p. 2749, Springer Verlag 1989.
La machine bases de donnes Verso (Recto tant le calculateur frontal) fut
dveloppe lINRIA au dbut des annes 1980. Bas sur le modle relationnel
imbriqu, ce projet a dvelopp un prototype original intgrant un filtre matriel spcialis et la thorie du modle relationnel NF2.
[Seshadri97] Seshadri P., Livny M., Ramakrishnan R., The Case for Enhanced
Abstract Data Types , Proc. of 23rd Intl. Conf. On Very Large Databases,
Athens, Greece, p. 66-75, 1997.
Cet article plaide pour des types abstraits amliors exposant la smantique de
leurs mthodes sous forme de rgles. Il dcrit limplmentation et les techniques doptimisation de requtes dans le systme PREDATOR. Dautres implmentation de types abstraits sont voques.
[Siberschatz91] Silberschatz A., Stonebraker M., Ullman J., Next Generation
Database Systems Achievements and Opportunities , Comm. of the ACM,
vol. 34, n 10, p. 110-120, Oct. 1991.
Cet article fait le point sur lapport des systmes relationnels et souligne les
points essentiels que la future gnration de SGBD devra rsoudre.
[Stonebraker86] Stonebraker M., Rowe L., Hirohama M., The Implementation of
PostGres , IEEE Transactions on Knowledge and Data Engineering, vol. 2,
n 1, p. 125-142, Mars 1990.
Cet article dcrit limplmentation de PostGres, le systme ralis Berkeley
aprs Ingres. PostGres fut le premier systme objet-relationnel. Il a t plus
tard commercialis sous le nom dIllustra, qui fut rachet par Informix en 1996.

Lobjet-relationnel et SQL3 461

[Stonebraker96] Stonebraker M., Moore D., Object-Relational DBMSs : The Next

Great wave, Morgan Kaufmann Pub., San Fransisco, CA, 1996.
Ce livre dfinit ce quest un SGBD objet-relationnel. Les fonctionnalits du
SGBD Illustra sont mises en avant pour situer les objectifs essentiels des systmes objet-relationnels, en particulier du point de vue du modle de donnes,
du langage de requtes et de loptimisation.
[Zaniolo83] Zaniolo C., The Database Language GEM , Proc. of 1983 ACM SIGMOD Intl. Conf. on Management of Data, San Jos, Ca, p. 207-218, Mai 1983.
Cet article propose une extension du modle relationnel et du langage de
requte QUEL pour intgrer des tables fortement types, des gnralisations,
des rfrences, des expressions de chemins et des attributs multivalus. Il dcrit
un langage de requtes prcurseur de SQL3.

Chapitre XIV

OPTIMISATION
DE REQUTES OBJET
1. INTRODUCTION
Une des fonctionnalits essentielles des systmes objet ou objet-relationnel est la possibilit dinterroger la base partir de requtes non procdurales, exprimes en OQL
ou en SQL3 (voir chapitre prcdent). Ces requtes peuvent invoquer des oprations
sur des types de donnes utilisateur. En effet, dans les SGBD objet ou relationnelobjet, lutilisateur, ou plutt un implmenteur systme, peut ajouter ses propres types
de donnes, avec des comparateurs logiques et des mthodes daccs spcifiques.
Loptimiseur doit alors tre extensible, cest--dire capable de supporter une base de
rgles de connaissances pouvant tre tendue par lutilisateur afin dexplorer un
espace de recherche plus riche pour les plans dexcution.
Un premier problme est dtre capable de gnrer tous les plans dexcution possibles pour une requte complexe. Ceci ncessite tout dabord des techniques de
rcriture de requtes en requtes quivalentes. La rcriture peut seffectuer au
niveau de la requte source ; plus souvent, elle sapplique sur des requtes traduites en
format interne, sous forme darbres algbriques. De nombreux travaux ont t effectus sur les techniques de rcriture de requtes objet [Graefe93, Haas89, Cluet92,
Mitchell93, Finance94, Florescu96].

464 BASES DE DONNES : OBJET ET RELATIONNEL

Un deuxime problme est le choix des algorithmes et mthodes daccs les plus performants pour raliser une opration de lalgbre dobjets. Ce choix est plus riche que
dans le cas relationnel pour les jointures qui peuvent maintenant seffectuer directement par traverses de pointeurs. Le support direct de pointeurs sous forme didentifiants invariants est en effet une des fonctionnalits nouvelles des systmes objet, permettant la navigation. Le choix des algorithmes daccs va dpendre du modle de
stockage qui inclut de nouvelles techniques dindexation de chemins et de groupage
dobjets. Dautres problmes difficiles sont la mise en place doprateurs spcifiques
sur collections et des index sur fonctions. Nous examinerons plus particulirement les
nouveaux algorithmes de traverses de chemins.
Comme dans le cas relationnel, le choix du meilleur plan ncessite un modle de cot
permettant destimer le cot dun plan la compilation. Ce modle doit prendre en
compte les groupages dobjets, les parcours de pointeurs, les index de chemins, et
aussi les mthodes utilisateur. Ceci pose des problmes difficiles. Plusieurs modles
ont t proposs [Bertino92, Cluet92]. Nous en proposons un prenant en compte le
groupage des objets.
Si lon est capable de gnrer tous les plans candidats pour calculer la rponse une
requte et destimer le cot de chacun, il faut encore choisir le meilleur plan. Une
stratgie exhaustive nest pas possible compte tenu du grand nombre de plans en
gnral. Des stratgies de recherche sophistiques ont t proposes, depuis loptimisation itrative [Ioannidis90, Lanzelotte91] jusqu la recherche gntique [Tang97].
Nous donnons dans ce chapitre une vue densemble des mthodes alatoire de
recherche de plan optimal.
Ce chapitre prsente une synthse des techniques essentielles de loptimisation des
requtes dans les bases de donnes objet, au-del du relationnel. Il sappuie en partie
sur les travaux de recherche que nous avons mens au laboratoire PRiSM de
Versailles de 1990 1996. Ces techniques commencent aujourdhui tre intgres
dans les SGBD objet-relationnel et objet. Dans la section suivante, nous dtaillons
plus particulirement la problmatique doptimisation spcifique lobjet, en lillustrant par quelques exemples. Dans la section 3, nous introduisons un modle de stockage gnrique pour bases de donnes objet. La section 4 se consacre aux algorithmes
de traverse de chemins. Nous donnons diffrents algorithmes de parcours dassociations et de collections imbriques qui gnralisent les algorithmes de jointures en cascade aux bases de donnes objet. La section 5 discute de la gnration des plans quivalents et des types de rgles de rcriture considrer. Elle conduit dvelopper une
architecture type pour un optimiseur extensible. La section 6 dveloppe un modle de
cot pour SGBD objet. Nous examinons ensuite dans la section 7 les diffrentes stratgies de recherche du meilleur plan proposes par les chercheurs. Nous terminons le
chapitre en proposant une stratgie gntique originale applique au choix dalgorithmes de traverses de chemins.

Loptimisation de requtes objet 465

2. PROBLMATIQUE
DES REQUTES OBJET
Dans cette section, nous examinons plus particulirement les problmes soulevs par
loptimisation de requtes OQL ou SQL3 par rapport aux requtes purement relationnelles, cest--dire exprimes en SQL2.

2.1. QUEST-CE QUUNE REQUTE OBJET ?

Les bases de donnes objet et plus encore relationnel-objet permettent de formuler des
requtes classiques, cest--dire exprimables en SQL de base. En consquence, loptimiseur dun SGBD doit toujours tre capable deffectuer les optimisations tudies
pour le relationnel. Au-del, les requtes objet intgrent des constructions inexprimables en relationnel. ce titre, elles posent des problmes doptimisation spcifiques. Les points nouveaux sont pour lessentiel :
1. Le support de mthodes et oprateurs dfinis par lutilisateur. Dans les systmes objet, lutilisateur peut dfinir ses propres mthodes, ses propres comparateurs et aussi surcharger les oprateurs du langage de requtes, par exemple laddition. Ceci pose au moins trois problmes doptimisation : comment utiliser des
acclrateurs, par exemple des index pour acclrer lvaluation de requtes ?
Comment gnrer toutes les squences de mthodes ou doprateurs possibles pour
calculer la rponse une requte ? Comment valuer le cot dune mthode programme par lutilisateur ?
2. Les traverses de chemins. Celles-ci sont des extensions des jointures relationnelles effectues directement par parcours de pointeurs. Ces pointeurs implmentent
les associations. Il nest pas toujours vident de les utiliser efficacement, et parfois
des jointures classiques peuvent tre plus performantes.
3. Les manipulations de collections. Les collections sont implmentes par des structures de donnes spcifiques et supportent des oprateurs spcifiques, par exemple
union, intersection, diffrence, inclusion, recherche dappartenance, pour les
ensembles. Des rgles de transformation nouvelles sont applicables aux collections.
Il faut pouvoir en donner connaissance loptimiseur, qui doit tre capable de les
prendre en compte. De plus, valuer le cot dun oprateur sur collections nest pas
chose vidente.
4. La prise en compte de lhritage et du polymorphisme. Lhritage stipule que
tout objet dune sous-classe est membre implicite de la classe dont il hrite. Cette
rgle doit pouvoir tre prise en compte lors de loptimisation. Elle introduit des difficults lors des surcharges ou redfinitions de mthodes possibles grce au polymorphisme dans les sous-classes. Les calculs de cot la compilation des requtes

466 BASES DE DONNES : OBJET ET RELATIONNEL

deviennent alors trs difficiles, les mthodes rellement appliques ntant connues
qu la compilation.

2.2. QUELQUES EXEMPLES MOTIVANTS

Nous illustrons le concept de requte objet par quelques exemples sur la base reprsente figure XIV.1. Celle-ci est une interprtation objet de la situation bien connue
o des clients passent des commandes de produits des fournisseurs. Une commande
contient plusieurs lignes. Clients et fournisseurs sont des personnes. Les chemins de
traverse sont implments par des attributs portant le nom des associations contenant
des identifiants dobjets. Ils sont marqus par des flches.
Personnes

Habite

Pays
Nom

nom
adresse
telephones

Passe

Clients

Fournisseurs

numcli
type

numfou
commentaire

*
Commandes
numco
etat
date
responsable
prix()

Ligne
Quantit

Vendu

*
Produits
numpro
nom
marque
prix

Figure XIV.1 : Schma de base de donnes objet

2.2.1. Parcours de chemins

Supposons par exemple que lon recherche le nom des produits et ladresse des fournisseurs associs pour ceux de plus de 50 ans qui habitent en France. La question
ncessite une expression de chemins en rsultat mais aussi deux expressions de chemins en qualification, pour tester les prdicats Age
>
50
et
Pays = France. Elle peut scrire comme suit en OQL :

Loptimisation de requtes objet 467

(Q1) SELECT P.NOM, P.VENDU.ADRESSE

FROM PRODUITS P
WHERE P.PRIX > 10.000
AND P.VENDU.AGE > 50
AND P.VENDU.HABITE.PAYS = FRANCE.

On note que les chemins sont monovalus. Il est aussi possible de parcourir des chemins multivalus, en utilisant par exemple des collections dpendantes en OQL. La
question suivante recherche par exemple les clients qui ont command des produits de
prix suprieur 10 000 :
(Q2) SELECT C.NOM, C.ADRESSE
FROM CLIENTS C, C.PASSE M, M.LIGNE P
WHERE P.PRIX > 10.000

Le problme essentiel pour ce type de requtes est de choisir un algorithme de parcours des chemins de traverse, de sorte rduire au maximum le nombre dobjets
traverss. Des jointures par valeur, comme en relationnel, peuvent parfois tre plus
avantageuses afin de trouver rapidement des rsultats partir dun petit nombre
dobjets en mmoire.

2.2.2. Mthodes et oprateurs

Une partie de la base de donnes dcrite figure XIV.1 peut tre tendue avec la localisation gomtrique des clients et des fournisseurs. Nous supposons que lunit de
mesure des distances est le kilomtre. Les types de donnes suivant peuvent tre dfinis :
TYPE POINT ( ATTRIBUTS X, Y COORDONNES ;
REAL FUNCTION DISTANCE(P1 POINT, P2 POINT)) ;
TYPE ZONE ( ATTRIBUTS P1, P2 POINT ;
BOOLEAN FUNCTION INCLUS(Z ZONE, P POINT)).

Considrons une implmentation des fournisseurs et clients par deux tables :

FOURNISSEURS (NUMFOU INT, NOM VARCHAR, ADR ADRESSE, NUMPAYS INT, TEL
TELEPHONES, LOCALISATION POINT) ;
CLIENTS (NUMCLI INT, NOM VARCHAR, ADR ADRESSE, NUMPAYS INT, TEL
TELEPHONE, LOCALISATION POINT).

Loptimiseur doit alors tre capable dvoluer en prenant en compte les nouveaux
types et les rgles doptimisation des oprations sur ces types. Par exemple, on pourra
maintenant rechercher tous les fournisseurs localiss dans une zone donne ( :Z) et
moins de 100 km dun client donn ( :N) par la requte :
(Q3) SELECT NUMFOU, NOM, ADRESSE
FROM CLIENTS C, FOURNISSEURS F
WHERE C.NUMCLI = :N AND INCLUS( :Z, F.LOCALISATION)
AND DISTANCE(C.LOCALISATION, F. LOCALISATION) < 100 ;

468 BASES DE DONNES : OBJET ET RELATIONNEL

Supposons maintenant que les types figure et cercle soient connus du SGBD extensible, dfini comme suit :
TYPE
TYPE

FIGURE (ATTRIBUT CONTOUR LIST<POINT> ;

BOOLEAN FUNCTION INCLUS (P POINT, F FIGURE))
CERCLE (ATTRIBUT CENTRE POINT, RAYON REAL ;
CERCLE FUNCTION CERCLE(C POINT, R REAL) ;
FIGURE FUNCTION INTERSECTION(C CERCLE, Z ZONE)).

Une requte quivalente la requte prcdente consiste chercher tous les fournisseurs inclus dans la figure gomtrique rsultant de lintersection de la zone paramtre
et dun cercle de centre le client et de rayon 100 km, ce qui donne :
(Q4) SELECT NUMFOU, NOM, ADRESSE
FROM CLIENTS C, FOURNISSEURS F
WHERE C.NUMCLI = :N
AND INCLUS(F.LOCALISATION, INTERSECTION(CERCLE(C.LOCALISATION,100),:Z)

Un bon optimiseur doit tre capable de dterminer le meilleur plan dexcution pour
cette requte. Il doit donc sapercevoir de lquivalence des formulations. Voil qui
nest pas chose simple et demande de bonnes notions de gomtrie !

2.2.3. Manipulation de collections

Outre les parcours de chemins vus ci-dessus, les collections peuvent tre manipules
par des oprations spcifiques dextraction de sous-collections, de concatnation,
dintersection, de recherche dlments, etc. Ces oprations peuvent obir des rgles
de rcritures spcifiques. Par exemple, trouver si un lment appartient lunion de
deux collections revient trouver sil appartient lune ou lautre. Supposons que
telephones soit un attribut contenant un ensemble de numros de tlphone. La
requte suivante recherche les noms et adresses des clients de Paris dont le numro de
tlphone est donn par la variable :N :
(Q5) SELECT C.NOM, C.ADRESSE
FROM CLIENTS C
WHERE :N IN
UNION( SELECT S.TELEPHONES
FROM CLIENTS C
WHERE ADRESSE LIKE PARIS)

Grce aux proprits des ensembles, plus particulirement de loprateur dunion par
rapport lappartenance, elle doit pouvoir tre transforme en une requte plus simple.

2.2.4. Hritage et polymorphisme

Lors dune requte sur une super-classe, lhritage ncessite de retrouver tous les lments des sous-classes participant la rponse. Coupl au polymorphisme, il peut

Loptimisation de requtes objet 469

impliquer des difficults pour loptimiseur. En effet, la liaison retarde conduit ne

pas connatre lors de la compilation le code rellement appliqu suite un appel de
mthode. Supposons une fonction revenus() calculant les revenus dune personne.
Celle-ci pourra tre diffrente pour un fournisseur et un client, donc redfinie au
niveau de la classe clients et de la classe fournisseurs. La requte suivante :
(Q6) SELECT NOM, ADRESSE
FROM PERSONNES
WHERE REVENUS() > 50.000

ncessite donc a priori de calculer le revenu de chaque client et de chaque fournisseur

pour vrifier sil est suprieur 50 000. La fonction effectivement applique dpend
du sous-type de la personne. Le cot du plan est donc difficile estimer lors de la
compilation de la requte.

3. MODLE DE STOCKAGE
POUR BD OBJET
Dans cette section, nous introduisons un modle de stockage gnral pour bases de
donnes objet. Ce modle intgre diffrentes variantes didentifiants dobjets, de techniques de groupages dobjets et dindexation. Il est suffisamment gnral pour reprsenter les mthodes de stockage existant dans les SGBD. Lobjectif est dillustrer les
techniques possibles, qui nous servirons plus loin de base aux calculs des cots
daccs.

3.1. IDENTIFIANTS DOBJETS

La plupart des SGBD stockent les objets dans des pages fentes (slotted pages).
Chaque page contient en fin de page un tableau de taille variable adressant les objets
de la page. La figure XIV.2 illustre une page fentes. Le dplacement conduisant du
dbut de la page au dbut de chaque objet est conserv dans un petit index en fin de
page.
Comme nous lavons dj vu, dans les SGBDO, les objets sont dsigns par des identifiants dobjets. Il est possible de distinguer identifiants physiques et identifiants
logiques.

470 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XIV.1 : Identifiant physique (Physical OID)

Identifiant dobjet compos dun numro de fichier, dun numro de page et dun numro de fente
dans la page contenant lobjet.

Objet 1
Objet 2
Objet 3

Fentes

Figure XIV.2 : Page fentes

Les identifiants physiques sont rapides dcoder pour atteindre lobjet rfrenc. Par
contre, ils ne permettent pas le dplacement libre des objets dans la base. En cas de
dplacement, une technique de chanage doit tre mise en place : lentre de la page
initiale doit indiquer que lobjet nest plus dans la page et pointe sur son nouvel identifiant physique. Cette technique de suite (forwarder) est trs lourde grer, surtout si
les objets se dplacent souvent. On lui prfrera les identifiants logiques, plus coteux
lors de laccs mais invariants au dplacement dobjet.
Notion XIV.2 : Identifiant logique (Logical OID)
Identifiant dobjet compos dun numro dentre dans une table permettant de retrouver lidentifiant physique de lobjet.

En cas de dplacement de lobjet, seule lentre dans la table est change ; elle est
positionne la nouvelle adresse de lobjet. En gnral, les SGBD grent une table
didentifiant logique par type dobjets. La taille de la table est ainsi limite. Pour la
limiter plus encore et viter les entres inutiles, la table est souvent organise comme
une table hache : chaque identifiant logique est affect une entre dtermine par
une fonction de hachage ; chaque entre contient des couples de correspondance
<identifiant logique-identifiant physique>. La figure XIV.3 illustre le dcodage dun
identifiant logique.
Un bon modle de stockage permet la fois les identifiants physiques (OIDP) et les
identifiants logiques (OIDL). Le choix du type didentifiants affecte directement le
cot de traverse des pointeurs.

Loptimisation de requtes objet 471

OID logique
Objet 1
Objet 2
Objet 3

OID physique
Page

Table des objets

Figure XIV.3 : Dcodage dun identifiant logique

3.2. INDEXATION DES COLLECTIONS DOBJETS

Pour acclrer lvaluation de requtes avec prdicats de slection, les systmes
offrent des index, gnralement organiss comme des arbres-B contenant dans les
feuilles des listes didentifiants dobjets. Un index peut tre peru comme une fonction donnant une liste didentifiants dobjets partir dune valeur dattributs. Le cot
de traverse dun index est gnralement de deux E/S, voire trois pour des trs grosses
collections dobjets.
Au-del des index classiques, certains systmes objets offrent des index de chemins.
Notion XIV.3 : Index de chemin (Path index)
Index donnant pour chaque valeur dun attribut dune collection dobjets lextrmit dun chemin
tous les chemins menant des objets ayant cette valeur dattributs.

Il existe diffrents types dindex de chemins [Bertino89, Kim89]. Les index de chemin simples [Bertino89] [Kemper90] associent pour chaque valeur figurant la fin
du chemin tous les identifiants dobjets suffixes du chemin. Ils peuvent tre implments comme des relations : chaque colonne dun tuple correspond une collection
du chemin, en remontant depuis la fin du chemin. Le premier attribut contient la
valeur figurant la fin du chemin, les suivants contiennent des identifiants dobjets
dsignant les objets successivement rencontrs en parcourant le chemin lenvers. La
figure XIV.4 illustre un index de chemins simple pour le chemin Produits
Fournisseurs Pays de la base reprsente figure XIV.1.

472 BASES DE DONNES : OBJET ET RELATIONNEL

Produits

vendu

Fournisseurs

habite

Pays

Pays

Fournisseurs

Produits

Allemagne

F1
F1
F2
F2
F3
F4
F4
F5
F6
F6
F7

P1
P2
P1
P3
P4
P5
P1
P1
P1
P6
P7

France

Italie
USA

Figure XIV.4 : Exemple dindex de chemin simple

Une premire variante consiste imbriquer les chemins, en vitant ainsi de rpter plusieurs fois un mme identifiant dobjet pour chacun de ses parents. Par exemple, pour le
fournisseur F1, on indiquera directement la liste des parents, pour F2 de mme, si bien
que lentre Allemagne de lindex prcdent devient (Allemagne(F1(P1, P2) F2 (P1,
P3) ). Un tel index est appel index de chemin imbriqu [Bertino91]. De tels index
sont plus difficiles maintenir et utiliser que des tables lors des mises jour.
Les multi-index [Kim89] sont une alternative aux index de chemin. Pour chaque
couple de collections (Ci, Ci+1) conscutives du chemin, on gre un index de jointure
[Valduriez87] contenant les couples identifiants dobjets lis par le chemin. Le dernier
index est un index classique donnant pour chaque valeur terminale du chemin lidentifiant de lobjet contenant cette valeur. Le parcours du chemin seffectue alors par des
intersections de listes didentifiants. Chaque index est finalement un index classique
qui peut tre implment comme un arbre B. Le problme des multi-index est que
chaque index doit tre lu ou crit indpendamment, ce qui ncessite des entres-sorties supplmentaires par rapport aux index de chemin. Lutilisation de tels index est
par contre plus large, par exemple pour acclrer des jointures de collections intermdiaires sur le chemin ou des slections sur la collection feuille.

3.3. LIAISON ET INCORPORATION DOBJETS

Dans les SGBD modernes, les objets associs peuvent tre stocks ensemble comme
un objet composite (cest--dire composs dautres objets), ou sparment comme

Loptimisation de requtes objet 473

plusieurs objets relis par des identifiants logiques ou physiques. On distingue alors la
liaison de lincorporation dobjets.
Notion XIV.4 : Liaison dobjet (Object linking)
Reprsentation dobjets associs par un attribut mono (association 1-1) ou multivalu (association
1-N) contenant un ou plusieurs identifiants dobjet pointant depuis un objet vers lobjet associ.

La liaison peut tre effectue dans les deux sens, lobjet rfrenc pointant lui-mme
son ou ses objets associs. Il existe alors pour chaque objet cible un ou plusieurs liens
inverses vers lobjet source. La liaison est une technique classique pour reprsenter
les associations ncessitant le parcours didentifiants pour retrouver les objets associs. La liaison inverse permet le parcours de lassociation dans les deux sens. La liaison a le mrite de rendre les objets lis quasiment indpendants, ce qui nest pas le cas
avec lincorporation.
Notion XIV.5 : Incorporation dobjet (Object embedding)
Reprsentation dobjets associs par un objet composite contenant un objet englobant avec un attribut complexe mono (association 1-1) ou multivalu (association 1-N) contenant directement la
valeur des objets lis.

Lincorporation rend les objets incorpors dpendants de lobjet englobant : ils sont
dtruits avec lui. Le choix entre liaison ou incorporation est donc aussi un problme
de smantique : un objet incorpor a le mme cycle de vie que lobjet incorporant. Du
point de vue stockage, lincorporation prsente lavantage de rendre les objets incorporant et incorpor accessibles simultanment. En outre, elle permet le placement des
objets dans une mme page, ce qui est aussi possible avec la liaison comme nous le
verrons ci-dessous. Elle prsente par contre linconvnient de ne pas supporter le partage rfrentiel des objets dpendants, qui sont de fait copis sils sont rfrencs
ailleurs. La figure XIV.5 illustre la liaison et lincorporation dans le cas de commandes et de lignes de commandes.
Commandes

Commandes

C1

C1

Ligne

Ligne

Ligne

P1-10

P2-15

P3-7

L1

L2

L3

Ligne

Ligne

Ligne

P1-10

P2-15

P3-7

Figure XIV.5 : Incorporation et liaison dobjets

474 BASES DE DONNES : OBJET ET RELATIONNEL

3.4. GROUPAGE DOBJETS

Pour permettre la navigation rapide dun objet matre vers des objets lis (par
exemple, des commandes aux lignes de commandes) ou pour acclrer les jointures
dans le cas dune implmentation relationnelle, il est possible de grouper diffrents
objets lis dans une mme page.
Notion XIV.6 : Groupage (Clustering)
Technique consistant stocker dans une mme page des objets lis par une association afin dacclrer les accs ces objets par navigation ou jointure.

Le groupage est plus souple que lincorporation car il permet une vie autonome des
objets lis, qui peuvent exister sans objets associs. En cas dobjets sans matre ou
dobjets partags par plusieurs matres, le choix de la page de stockage nest pas vident. Pour capturer une large classe de stratgies de groupage, il est possible de dfinir les groupes par des prdicats de slection ou dassociation. Un prdicat de slection permet par exemple de dfinir le groupe des commandes de prix suprieur
10 000 (Commandes.prix>10.000). Un prdicat dassociation permet par
exemple de dfinir un groupe pour chaque produit (Produits vendu
Fournisseurs). Ces prdicats sont utiliss pour dfinir les ensembles dobjets
stocker ensemble dans une mme page ou au moins dans des pages proximit.
Les prdicats ntant pas forcment disjoints, un objet peut appartenir logiquement
plusieurs groupes. Si lon exclut les duplications dobjets, il faut lors du chargement
choisir un groupe. Une technique possible consiste associer des priorits chaque
prdicat de liens. Si un objet appartient deux groupes ou plus, celui de priorit suprieure est retenu. Pour pouvoir discriminer les groupes, les priorits doivent tre diffrentes, dfinies par exemple par un nombre de 0 10.
Afin de visualiser les informations de spcifications des groupes, il a t propos
[Amsaleg93] dutiliser un graphe de groupage dfini comme suit :
Notion XIV.7 : Graphe de groupage (Clustering graph)
Graphe dont les nuds reprsentent les extensions de classes et les arcs les prdicats de liens servant au groupage, chaque arc ayant une priorit pouvant varier de 0 10.

Un graphe de groupage est correct si tous les arcs pointant vers un mme nud ont
une priorit diffrente. Les objets points par plusieurs liens de groupage sont donc
assigns au groupe de plus forte priorit. La figure XIV.6 prsente diffrents graphes
de groupage possibles pour les fournisseurs, les produits et les commandes. Elle suppose que lassociation directe des fournisseurs aux produits est gre par le SGBD.
droite du graphe de groupage, les groupes de diffrents types possibles sont reprsents, par exemple les groupes de fournisseurs, de produits, ou les groupes mixtes.

Loptimisation de requtes objet 475

(a) Groupage simple

Fournisseurs

Produits

(b) Groupage conjonctif

Fournisseurs

Produits

Commandes

(c) Groupage disjonctif

Clients

Produits
5

10

Commandes

Figure XIV.6 : Exemple de graphe de groupage

La figure XIV.6 montre quatre possibilits de groupage des objets de collections :

1. Le groupage simple. Cest le groupage classique de deux collections selon un prdicat de lien. Ce type de groupage existe dans les bases de donnes en rseaux
(matre et membres via un lien) et est possible dans les bases de donnes relationnelles selon un prdicat de jointure. Figure XIV.6a, les objets de la collection produits sont groups simplement avec les objets de la collection fournisseurs,
avec une priorit maximale de 10. Tous les produits sans fournisseurs seront groups ensemble.
2. Le groupage conjonctif. Il permet de grouper plusieurs objets de collections diffrentes avec ceux dune collection matre. Figure XIV.6b, tous les objets produits
et commandes sont groups avec leurs fournisseurs.
3. Le groupage disjonctif. Dans le cas o plusieurs matres se partagent un objet qui
devrait tre group avec eux, un choix doit tre fait afin dviter les duplications
dobjets. Selon le mcanisme de priorit, lobjet est alors plac dans le groupe dter-

476 BASES DE DONNES : OBJET ET RELATIONNEL

min par lobjet matre selon larc de poids maximal. Par exemple, figure XIV.6c,
chaque objet commandes sera stock prs de son fournisseur sil existe.

3.5. SCHMA DE STOCKAGE

Afin de regrouper et visualiser toutes les informations permettant de stocker les objets
dans la base et dy accder, nous avons propos [Gardarin95] dintroduire un graphe
de stockage plus complet que le graphe de groupage vu ci-dessus. Ce graphe permet
de reprsenter un schma objet de donnes avec des notations proches dUML (voir
chapitre sur la conception), avec en plus les informations suivantes :
1. les objets incorpors lis aux objets incorporants par des flches doubles en pointills ;
2. les objets groups lis aux objets groupants par des flches simples en pointills tiquetes par la priorit du groupage et lventuel prdicat, sil ne sagit de lassociation existant entre les objets ;
3. les index par des rseaux de lignes pointilles issus de lattribut index et pointant
vers la ou les collections indexes.
Personnes

Habite

Pays
Nom

nom
adresse
telephones

Passe

Clients

Fournisseurs

numcli
type

numfou
commentaire

Vendu

10

Ligne

Commandes
numco
etat
date
responsable
prix()

3
Quantit

*
Produits
numpro
nom
marque
prix

Figure XIV.7 : Exemple de graphe de stockage

La figure XIV.7 reprsente un exemple de graphe de stockage pour la base dont le

schma a t dfini figure XIV.1. Pays est incorpor dans Personnes, dont les

Loptimisation de requtes objet 477

attributs sont eux-mmes incorpors dans Clients et Fournisseurs. Les

lignes de commandes sont incorpores dans les commandes. Elles rfrencent les
produits. Les commandes sont places en priorit proximit des clients, sinon
proximit des produits. Les produits sont placs proximit des fournisseurs. Il existe un index de chemin depuis nom de produit vers produits et
fournisseurs. Deux index primaires classiques sont grs, respectivement sur
numro de commande (numco) et numro de produit (numpro).
Un graphe de stockage induit une organisation physique des donnes. Il reprsente en
fait le modle interne de la base et est donc un lment essentiel prendre en compte
pour loptimiseur. Le problme de loptimiseur est de trouver le meilleur plan daccs
pour excuter une requte compte tenu du modle interne reprsent par le graphe de
stockage. Pour ce faire, loptimiseur doit aussi prendre en compte la taille des collections et groupes. Il doit bien sr optimiser la navigation via des pointeurs, comme
nous allons le voir ci-dessous. Notez que la plupart des systmes objet ne distinguent
pas clairement le graphe de stockage et nont gure doptimiseur labor capable de
bien prendre en compte le modle interne.

4. PARCOURS DE CHEMINS
Optimiser la navigation dans une base de donnes objet est lun des soucis essentiels
dun optimiseur. Ce problme prolonge loptimisation des squences de jointures dans
les bases de donnes relationnelles. Dans cette partie, nous prsentons plusieurs algorithmes pour valuer une expression de chemins avec prdicats. De tels algorithmes
ont t tudis dans [Bertino91, Shekita90, Gardarin96]. Ils correspondent des types
varis de traverse dun graphe dobjets. Un tel graphe est reprsent figure XIV.8.

Figure XIV.8 : Exemple de graphe dobjets

478 BASES DE DONNES : OBJET ET RELATIONNEL

Chaque famille verticale dobjets correspond une collection Ci (par exemple, une
extension de classes). Chaque objet de la collection Ci pointe sur 0 N objets de la
collection Ci+1, selon les cardinalits des associations traverses. Nous crivons
lexpression de chemin C1(P1).C2(P2)Cn(Pn) en dsignant par Pi le prdicat de
slection de la collection Ci. Il sagit donc dassembler les squences c1.c2cn
dobjets lis par des pointeurs et vrifiant respectivement (c1 C1 et P1), (c2 C2 et
P2) (cn Cn et Pn).

4.1. TRAVERSE EN PROFONDEUR DABORD

La traverse en profondeur dabord (Depth-First-Fetch, DFF) est la mthode la
plus naturelle pour valuer une expression de chemins avec prdicats. Lalgorithme
suit le chemin depuis la collection racine vers la collection terminale. Chaque objet est
travers en allant toujours vers le premier objet du niveau suprieur non encore travers, vers lobjet de mme niveau sil nen nexiste pas, et en remontant lorsquil ny
a plus dobjet voisin. Loprateur correspondant est un oprateur n-aire, qui sapplique
sur N collections avec un prdicat possiblement vrai (tous les objets qualifient alors)
pour chaque collection. DFF peut tre vu comme un oprateur de jointures en cascade
utilisant une mthode pipeline. La figure XIV.9 donne un sketch de lalgorithme.
// Recherche des objets dun chemin C1.C2Cn vrifiant les prdicats P1,P2Pn
DFF(C1(P1).C2(P2)....Cn(Pn)) {
i = 1 ;
while (in) {
for each x in (Ci) {
if Pi(x) = VRAI {
if i < n return (x + DFF(FETCH(x.Ci+1)(Pi+1).Cn(Pn)))
else return(x) }
}
i = i+1 ;
}
}

Figure XIV.9 : Traverse en profondeur dabord

Lavantage de DFF est quil sagit dun oprateur n-aire qui ne gnre pas de rsultats
intermdiaires. Lalgorithme assemble les objets en accdant via les OID, ce qui est
efficace dans la plupart des SGBD. Les rsultats sont obtenus lun aprs lautre en
pipeline. Lalgorithme est dailleurs trs analogue celui de jointures n-aire en pipeline vu dans le cadre relationnel, ceci prs quil navigue en suivant les pointeurs.
Ainsi le SGBD peut-il retourner une rponse avant davoir travers tous les objets.
Intuitivement, cet oprateur est trs efficace lorsque la taille mmoire est suffisante

Loptimisation de requtes objet 479

pour contenir tous les objets sur un chemin de la racine aux feuilles, cest--dire au
moins une page par collection. Cependant, si les objets ne sont pas groups selon le
chemin et si la taille mmoire est insuffisante, le systme peut tre conduit relire de
nombreuses fois une mme page.

4.2. TRAVERSE EN LARGEUR DABORD

La traverse en largeur dabord (Breadth-First-Fetch, BFF) parcourt larbre
dobjets par des jointures binaires en avant (Forward Join, FJ) successives. Les jointures sont effectues par parcours des pointeurs de la collection Ci vers la collection
Ci+1. Ainsi, soit une expression de chemin qualifie C1(P1).C2(P2)Cn(Pn). Pour
trouver les objets qualifiants, (n-1) jointures par rfrences successives du type
Si+1 = FJ(SiCi+1(Pi+1)) sont accomplies, o Si dsigne une table mmorisant les
objets satisfaisant le sous-chemin C1(P1).C2(P2)Ci(Pi). Le critre de jointure est une
simple traverse de pointeurs. Le prdicat Pi+1 doit tre vrifi sur les objets cibles de
Ci+1. Lalgorithme est proche de celui ralisant la traverse en profondeur vue ci-dessus (DFF), mais rduit deux collections, cest--dire un chemin de longueur 1. Une
table intermdiaire rpertoriant les identifiants dobjets qualifiants doit tre gnre en
rsultat de chaque jointure en avant. Dans la suite, nous appelons cette table table
support. La jointure en avant suivante repart de la table support. La figure XIV.10
illustre lalgorithme de traverse en largeur dabord pour trois collections, C1, C2 et
C3, dont les objets sont nots ai, bi et ci respectivement.
T12

FJ

C1

C2
(a)

C1

C2

a1
a2
a3
a4
a5
a6
a7

b5
b2
b1
b3
b2
b4
b1

T13

FJ

T12

C3
(b)

C1

C3

a1
a1
a3
a4
a5
a6
a6

c5
c7
c1
c2
c8
c4
c2

Figure XIV.10 : Traverse en largeur dabord

Lavantage de lalgorithme en largeur dabord est dtre bas sur des jointures binaires
par rfrence, donc pr-calcules. Le cot de calcul est donc rduit. Cependant, pour
accomplir la jointure entre les collections Ci et Ci+1, les tats des objets de la premire
collection Ci doivent tre chargs en mmoire pour trouver les pointeurs vers les objets
de Ci+1 (contenus dans lattribut Ai) ; les tats de la seconde Ci+1 doivent aussi tre
chargs en mmoire pour tester le prdicat Pi+1. Si aucun groupage selon lassociation

480 BASES DE DONNES : OBJET ET RELATIONNEL

nest ralis, des accs multiples alatoires aux pages peuvent tre ncessaires. Un tri
des identifiants des objets de la deuxime collection sera alors souvent avantageux.
Contrairement lalgorithme DFF, lalgorithme BFF ncessite de conserver si possible
en mmoire des rsultats intermdiaires. Si lon veut dlivrer tous les objets sur les chemins qualifiants, la table support doit tre tendue avec un attribut contenant les identifiants dobjets par collection traverse. Lalgorithme ne permet gure de dlivrer des
rsultats avant la traverse totale au moins des n-1 premires collections. Soulignons
que dans le cas rduit de deux collections, les algorithmes DFF et BFF sont similaires.

4.3. TRAVERSE LENVERS

La traverse lenvers, cest--dire en partant par la dernire collection du chemin, est
aussi possible en utilisant un algorithme de jointure binaire classique, de type jointure
relationnelle. Comme lalgorithme BFF, la traverse en largeur dabord lenvers
(Reverse-Breadth-First-Fetch, RBFF) accomplit une squence de jointures binaires
entre collections voisines sur le chemin, mais procde en ordre inverse, donc reculons.
Chaque jointure est appele une jointure inverse (Reverse Join, RJ). Sil ny a pas de
lien inverse, il sagit dune jointure par valeur, cest--dire que le critre est lappartenance de lidentifiant de lobjet de la seconde collection aux valeurs de lattribut de liens
de la premire collection. Pour traiter une expression de chemin qualifie
C1(P1).C2(P2)Cn(Pn) de la collection C1 collection Cn, (n-1) jointures successives
Si = RJ(SiCi(Pi)) sont accomplies, o Si designe la table support des objets satisfaisant le sous-chemin Ci(Pi)Cn(Pn) ; RJ est lalgorithme de jointure inverse testant
lappartenance de lidentifiant aux pointeurs. Une technique de jointure par hachage ou
par tri-fusion peut tre appliqu. La traverse lenvers est illustre figure XIV.11.
T32

RJ

C3

C2
(a)

C3

C2

c1
c2
c2
c4
c4
c7
c6

b2
b5
b4
b7
b4
b2
b1

T31

RJ

T32

C1
(b)

C3

C1

c1
c1
c2
c4
c6
c6
c6

a2
a4
a5
a7
a4
a1
a6

Figure XIV.11 : Traverse lenvers

La traverse lenvers est avantageuse lorsquune slection directe est possible sur la
dernire collection (par exemple par un index) et que cette slection retrouve un
nombre faible dobjets (forte slectivit). Pour mmoriser le parcours, une table sup-

Loptimisation de requtes objet 481

port est gnre (voir figure XIV.11). Un avantage de la mthode est qu chaque pas
la jointure est faite entre cette table support et la collection prcdente sur le chemin.
Lalgorithme est bon si la table support est petite (expression de chemin slective).
Soulignons quune expression de chemins peut toujours tre divise en plusieurs sousexpressions, chacune pouvant tre traite avec un algorithme diffrent, DFF, BFF ou
RBFF. Si un prdicat trs slectif est rapidement valuable sur une collection du chemin, on aura avantage considrer RBFF pour la partie prfixant cette collection, puis
BFF ou DFF pour la partie suffixe. Le choix dun algorithme ou dun autre nest pas
vident et ncessite un modle de cot, comme nous le verrons plus loin.

4.4. TRAVERSE PAR INDEX DE CHEMIN

La traverse par index de chemin (Path Index Traversal, PIT) bnficie de lexistence
dun index suivant le chemin. Comme vu ci-dessus, pour une valeur dattribut de la
collection cible, lindex donne tous les sous-chemins qualifiant. Il suffit donc daccder lindex pour trouver les associations dobjets satisfaisant le prdicat. Cependant,
si dautres prdicats figurent dans les collections prcdant la collection indexe, il
faut accder aux objets associs dont les identifiants sont trouvs dans lindex. Cela
peut tre trs pnalisant si les accs sont parpills sur les disques. Des tris sur les
identifiants physiques dobjets seront souvent avantageux, car ils permettront de grouper les accs aux objets dune mme page. Une autre faiblesse des index de chemins
est bien sr les cots de maintenance lors des mises jour, souvent importants.

5. GNRATION DES PLANS QUIVALENTS

5.1. NOTION DOPTIMISEUR EXTENSIBLE
Plus quen relationnel, la gnration de plans quivalents doit se faire par application
de rgles de transformation. En effet, la diffrence des systmes relationnels, les
systmes objet ou objet-relationnel ne sont pas ferms : limplmenteur de bases de
donnes peut ajouter ses propres types de donnes obissant des rgles de transformation spcifiques, comme les types gomtriques (point, cercle, etc.) vus ci-dessus.
Un optimiseur dun SGBD objet ou objet-relationnel doit donc tre extensible.
Notion XIV.8 : Optimiseur extensible (Extensible optimiser)
Optimiseur capable denregistrer de nouveaux oprateurs, de nouvelles rgles de transformation de
plans, de nouvelles fonctions de cot et de nouvelles mthodes daccs lors de la dfinition de types
de donnes utilisateurs, ceci afin de les utiliser pour optimiser les requtes utilisant ces types.

482 BASES DE DONNES : OBJET ET RELATIONNEL

Cette notion doptimiseur extensible a t bien formalise pour la premire fois dans
[Grafe93]. Un optimiseur extensible est construit autour dune base de connaissance
mmorisant les dfinitions de types et oprateurs associs, de mthodes daccs, de
fonctions de cot et de rgles de transformation de plans dexcution. Toutes les transformations de plans peuvent tre exprimes sous la forme de rgles. Comme en relationnel, les rgles permettent de transformer les arbres doprateurs de lalgbre reprsentant les requtes en arbres quivalents. Au-del du relationnel, pour supporter les
types de donnes utilisateurs, lalgbre relationnelle doit tre tendue en une algbre
dobjets complexes, avec en particulier les fonctions dans les expressions de qualification et de projection, et le support doprations sur collections imbriques telles que
Nest, Unnest et Flatten. Une telle algbre a t prsente au chapitre XI.
Nous reprsentons figures XIV.12 et XIV.13 les questions Q1 et Q3 du paragraphe 2.2
sous la forme darbres algbriques. Larbre de la figure XIV.12 contient trois restrictions sur attributs ou mthodes, suivies de deux jointures par rfrences qui traduisent
le parcours de chemin. Ces deux jointures peuvent par exemple tre remplaces par un
oprateur de parcours du graphe en profondeur dabord (DFF) vu ci-dessus, ou par
des jointures en arrire (RBFF). Une projection finale gagnerait tre descendue par
les rgles classiques vues en relationnel.
Rsultats

P.nom,
F. adresse

habite

P.nom =

vendu

" France"

Pays P

P.prix > 10.000

F.age() >

50

Produits P
Fournisseurs F

Figure XIV.12 : Arbre algbrique pour la question Q1

Larbre de la figure XIV.13 prsente une restriction sur prdicats utilisateurs

(Inclus) et une jointure sur fonction utilisateur (Distance < 100). Loptimisa-

Loptimisation de requtes objet 483

tion de telles requtes est difficile et ncessite des connaissances spcifiques sur les
fonctions utilisateurs [Hellerstein93], ici des fonctions gomtriques.
Rsultats

F.numfou,
F.nom, F.adresse

F.localisation) < 100

Distance(C.localisation,

C.numcli

:N

Clients C
Inclus(:Z,

F.localisation)

Fournisseurs F

Figure XIV.13 : Arbre algbrique pour la question Q2

5.2. LES TYPES DE RGLES DE TRANSFORMATION

DE PLANS
Comme pour le relationnel, un plan dexcution est un arbre annot, lannotation
associe chaque oprateur spcifiant lalgorithme choisi. Une rgle exprime que
lorsquun sous-arbre annot est rencontr dans un plan dexcution, il peut tre remplac par un autre sous-arbre annot sous certaines conditions. Le choix dun langage
de rgles pour crire les rgles de transformation est un problme difficile
[Finance94]. Certaines sont simplement des rgles dquivalence, conduisant des
transformations applicables dans les deux sens. Nous les noterons simplement :
<SOUS-ARBRE> <SOUS-ARBRE>

Dautres rgles ne sont applicables que dans un sens et peuvent ncessiter des conditions. titre dexemple, nous les crirons sous la forme suivante :
<SOUS-ARBRE> [<CONDITION>] <SOUS-ARBRE>.

Une telle rgle signifie que lorsquun sous arbre est rencontr, si la condition optionnelle est satisfaite, il peut tre rcrit dans le sous-arbre figurant aprs limplication.
En pratique, il faut en plus appliquer quelques procdures par exemple pour changer

484 BASES DE DONNES : OBJET ET RELATIONNEL

des variables ou des annotations ; celles-ci sont supposes attaches la rgle ; elles
ne sont pas mentionnes pour des raisons de simplicit.

5.2.1. Rgles syntaxiques

Les premires rgles que lon peut exprimer simplement sont celles caractrisant les
proprits de lalgbre, dj vues dans le cadre relationnel pour la plupart. Par
exemple, la rgle dassociativit des jointures scrira simplement
JOIN(JOIN(X,Y),Z) JOIN(X,JOIN(Y,Z)) ;

Plus complexe, la rgle de permutation de la projection sur un schma Z de la jointure

naturelle de deux relations de schmas X et Y ncessite une condition :
PROJECT(JOIN(X,Y), Z) [XY Z]
JOIN(PROJECT(X,ZX),PROJECT(Y,ZY) ;

Toutes les rgles classiques de lalgbre relationnelle peuvent ainsi tre codes, avec
plus ou moins de difficults. Il est possible aussi dajouter des rgles prenant en
compte les oprations sur collections, NEST,UNNEST et FLATTEN. Par exemple, la
rgle permettant de pousser une restriction avant une opration dimbrication NEST
peut scrire :
RESTRICT(NEST(X, G, N), Q) [ ATTRIBUT(Q) G ]
RESTRICT(NEST(RESTRICT(X, Q1), G, N), Q2) ;

Cette rgle exprime le fait que si une restriction est applique sur certains attributs de
groupement, alors la partie de la restriction concernant ces attributs peut tre applique avant le groupement.
Au-del, des rgles de simplification peuvent aussi tre introduites pour isoler des
sous-arbres identiques et les remplacer par une relation intermdiaire utilisable en plusieurs points. Ce genre de rgles est important car il permet dviter de calculer deux
fois la mme sous-question. Son expression gnrale ncessite un langage de rgles
un peu plus puissant, permettant de tester si deux sous-arbre sont quivalents.

5.2.2. Rgles smantiques

Nous groupons dans cette catgorie toutes les rgles gnrales permettant de gnrer
des questions quivalentes soit en prenant en compte des rgles dintgrit des donnes, soit en exprimant des axiomes sur les types de donnes abstraits.

5.2.2.1. Contraintes dintgrit

La prise en compte des contraintes sur les donnes dans les bases de donnes objet ou
objet-relationnel est difficile. Un optimiseur capable de prendre en compte de telles
contraintes pour un SGBD objet a t dvelopp lINRIA [Florescu96]. Une
contrainte est exprime sous la forme suivante :
[FOR ALL [<VARIABLE> OF TYPE <TYPE>]*] <EXPRESSION> <EXPRESSION>.

Loptimisation de requtes objet 485

Les expressions sont des termes fonctionnels du langage OQL, cest--dire des
expressions de chemins, des prdicats avec expressions de chemins ou des requtes.
De telles rgles permettent dexprimer divers types de contraintes, comme lexistence
de liens inverses et la redondance de donnes. Considrons par exemple la dfinition
en ODL de la base dcrivant pays et clients, en supposant ces classes lies par une
association 1N :
INTERFACE CLIENTS {
ATTRIBUT
INT NUMCLI KEY, STRING NOM,
ADRESSE CADRESSE, REF(PAYS) CPAYS, INT TELEPHONE,
INT SEGMENT, STRING COMMENTAIRE }
INTERFACE PAYS {
ATTRIBUT
INT NUMPAYS KEY, STRING NOM, INT NUMCONT,
STRING COMMENTAIRE, RESIDENTS SET <CLIENTS>}

La rgle de lien inverse spcifiant quun client rfrence un pays sil est rsident de ce
pays scrit :
FOR ALL C OF TYPE CLIENTS, P OF TYPE PAYS
C.CPAYS = P C IN P.RESIDENTS.

Supposons en plus que les adresses contiennent le pays :

INTERFACE ADRESSE {
ATTRIBUT
INT NUM, STRING RUE,
STRING VILLE, INT ZIP, STRING PAYS }

Une rgle exprimant une redondance de valeurs est :

FOR ALL C OF TYPE CLIENTS
C.CADRESSE.PAYS C.CPAYS.NOM

De telles quivalences sont trs puissantes et permettent dexprimer toutes sortes de

redondances, par exemple lexistence de vues matrialises ; lquivalence peut tre
remplace par une implication. Les quivalences ou implications peuvent tre facilement tendues pour exprimer des impossibilits, telles que la valeur nulle interdite ou
lunicit de cl (absence de doubles). Il est aussi possible de prendre en compte des
assertions dinclusion et des assertions dappartenance [Florescu96].
Par exemple, une rgle exprimant la non-nullit de lattribut pays peut scrire :
FOR ALL C OF TYPE CLIENTS C
C.CPAYS = NIL

Une rgle exprimant lunicit de la cl de client scrit :

FOR ALL C1,C2 OF TYPE CLIENTS
C1.NUMCLI = C2.NUMCLI C1 = C2

5.2.2.2. Types abstraits de donnes

Lquivalence de termes constitue un langage de rgles puissant qui peut aussi tre
adapt aux types abstraits de donnes. Ajoutons la base prcdente des images
dcrivant nos clients dfinies comme suit :

486 BASES DE DONNES : OBJET ET RELATIONNEL

INTERFACE IMAGE {
ATTRIBUT NUMCLI INT, CONTENT ARRAY[1024,1024] INT,
OPERATION
ARRAY[10] SUMMARY(IMAGE),
IMAGE ROTATE (IMAGE, ANGLE),
IMAGE CLIP (REGION) }

Considrons la requte suivante qui recherche les images des clients du segment 5, les
intersecte avec une fentre prdfinie $zone, et les fait tourner de 90 avant de les
afficher :
SELECT CLIP(ROTATE(I,90),$ZONE)
FROM CLIENTS C, IMAGES I
WHERE C.NUMCLI = I.NUMCLI
AND C.SEGMENT = 5 ;

Il apparat que plutt de faire tourner les images, on aurait intrt faire lintersection
(le clip) avec la zone tourne de 90, et faire tourner seulement la partie intressante. Lquivalence de termes est aussi trs approprie la dfinition daxiomes sur
des types abstraits. Par exemple, la transformation ncessaire pour rcrire la question
prcdente de manire plus optimise est :
FOR ALL I OF IMAGE, F OF FENETRE
CLIP(ROTATE(I,$A), F) ROTATE(CLIP(I,ROTATE(F,-$A),$A).

On dcouvre alors la question quivalente en principe plus rapide excuter :

SELECT ROTATE (CLIP(I, ROTATE($ZONE,-90)),90)
FROM CLIENTS C, IMAGES I
WHERE C.NUMCLI = I.NUMCLI
AND C.SEGMENT = 5 ;

Plus gnralement, de telles rgles permettent de prendre en compte les spcificits

des types abstraits afin de rcrire les expressions de fonctions dans les requtes. Elles
permettraient par exemple de spcifier des connaissances gomtriques suffisantes
pour montrer que les questions Q3 et Q4 vues dans la section sur les motivations sont
quivalentes.

5.2.3. Rgles de planning

Pour gnrer lespace de recherche des plans, il faut bien sr ajouter les rgles permettant de choisir les algorithmes de slection, jointures, et plus gnralement les traverses de chemins qualifis. Pour les systmes relationnels, les rgles de planning
sont bien connues [Ioannidis90, Ioannidis91]. Pour les jointures, elles permettent par
exemple de choisir le meilleur algorithme parmi le tri-fusion (SORT-MERGE), les
boucles imbriques (NESTED-LOOP) et la construction dune table de hachage
(HASH-TABLE). Ces rgles peuvent sexprimer comme suit :
JOINSORT-MERGE (X,Y) JOINNESTED-LOOP (X,Y)
JOINSORT-MERGE (X,Y) JOINHASH-TABLE(X,Y)

Loptimisation de requtes objet 487

Pour les systmes objet, il est possible de les tendre [Gardarin96] par quelques rgles
permettant de prendre en compte les traverses de chemin, avec les algorithmes prsents dans la section 4. Ces nouvelles rgles concernent lutilisation de loprateur DFF
de parcours en profondeur dabord, des jointures par rfrences et des index de chemins. JOINFJ dsigne la jointure par rfrence en avant non considre ci-dessus et
JOINRJ la jointure par rfrence en arrire. JOINPATH-INDEX dsigne lalgorithme de
jointure exploitant lexistence dun index de chemin. On obtient les nouvelles rgles :
1. Jointure en avant ou en arrire :
A JOINFJ B A JOINRJ B

2. Dcoupage et groupage de traverses en profondeur dabord :

DFF(A,B,C...N) JOIN(DFF(A,B..x-1),DFF(x...N))

3. Utilisation dindex de chemin :

JOINFJ(X,Y) [PATH-INDEX(X,Y)] JOINPATH-INDEX(X,Y)
DFF(A,B,C...N)[PATH-INDEX(A,B,C...N)] JOINPATH-INDEX(X,Y)

5.3. TAILLE DE LESPACE DE RECHERCHE

Quelle est la taille de lespace de recherche des plans pour une question donne ? Tout
dpend bien sr de la forme de la question et des rgles qui sy appliquent. En gnral, loptimisation de requtes objet conduit des espaces de recherche plus grands
que pour les requtes relationnelles. Cela provient surtout du fait que les requtes sont
souvent plus complexes et les rgles de transformation plus nombreuses.
Prenons par exemple le cas dune expression de chemin linaire qualifie. De telles
requtes sappellent des requtes chanes (voir figure XIV.14). Le profil de requtes
OQL correspondant est :
SELECT (X1, X2.Xn)
FROM X1 IN C1, X2 IN C1.AC2.Xn IN Cn-1.ACn
WHERE .

Pour simplifier, supposons labsence dindex de chemins. Chaque collection est relie
chacune de ses voisines par une association multivalue (le cas monovalu est un
cas dgnr).
C1

AC2

C2

AC3

........

Cn1

ACn

Cn

Figure XIV.14 : Une requte chane

FJ et RJ sont les deux algorithmes de jointures, lun par parcours de rfrence en

avant (FJ), lautre par jointure sur valeur de rfrence en arrire (RJ). DFF est lopra-

488 BASES DE DONNES : OBJET ET RELATIONNEL

teur n-aire de jointure par rfrence parcourant le graphe en profondeur dabord. Dans
le cas o DFF nest pas utilis, le problme revient calculer le nombre dordres de
jointures possibles avec deux oprateurs de jointures en vitant les produits cartsiens
[Tan91], [Lanzelotte93]. On obtient pour lespace de recherche de jointures binaires
de n collections :
(2n 2)!
n1
BJ_SS(n) =
*2
n!(n 1)!
Si lon introduit loprateur DFF, la taille de lespace de recherche devient bien sr
plus grande. Soit SS(n-1) lespace de recherche pour traverser (n-1) collections. On a :
SS(n) = BJ_SS(n) + PC_SS(n)
BJ_SS(n) est lespace de recherche pour les jointures binaires et PC_SS(n) est le
nombre darbres annots avec au moins un nud DFF. Pour dterminer la valeur de
PC_SS(n), supposons tout dabord un seul DFF avec trois collections : celles-ci sont
traites ensemble par cet oprateur DFF et peuvent tre vues comme une unique collection ; pour le reste, la longueur du chemin est rduite de 2, ce qui signifie que SS(n
2) plans peuvent tre gnrs. Il existe n 2 positions parmi les n collections o il
est possible dappliquer loprateur DFF sur trois collections. Pour la mme raison, il
existe n 3 positions o appliquer DFF sur quatre collections ; et ainsi de suite ; finalement, il existe 2 positions o appliquer DFF sur n 1 collections et 1 position pour
appliquer DFF sur les n collections. En sommant tous les cas analyss, on obtient une
borne suprieure de PC_SS(n). Ainsi, une bonne approximation du nombre de plans
est :
(2n 2)!
n1
BJ_SS(n) =
*2
n!(n 1)!
avec SS(1) = 1, SS(2) = 2, SS(3) = 9.
Ainsi, la table prsente figure XIV.15 donne une approximation du nombre de plans
pour des chemins de longueur 1 8. On constate quau-del de 8, lespace devient
rapidement important. Il est donc trs coteux pour un optimiseur de considrer toutes
les solutions, surtout dans les cas de requtes plus complexes que les requtes chanes.
Nombre de
collections

Espace de
recherche

Nombre de
collections

256

1544

9910

45

65462

Espace de
recherche

Figure XIV.15 : Espace de recherche pour des requtes chanes

Loptimisation de requtes objet 489

5.4. ARCHITECTURE DUN OPTIMISEUR EXTENSIBLE

Un optimiseur extensible doit donc permettre la prise en compte complte de nouveaux types de donnes, avec oprateurs, rgles, etc. Il sagit donc dun vritable systme expert spcialis. La figure XIV.16 reprsente une architecture possible pour un
optimiseur extensible [Lanzelotte91]. Celui-ci explore lespace des plans dexcution.
Un tel optimiseur accepte de ladministrateur la dfinition de rgles de transformation
darbres algbriques annots. Il est extensible, en ce sens quil est possible dajouter
de nouveaux types et de nouvelles rgles. Il transforme un arbre algbrique dentre
en un plan dexcution quasiment optimal. Pour cela, il utilise le schma de stockage
de la base. Le gnrateur de plan applique les rgles. La stratgie dvaluation est
base sur un modle de cot et tend rduire le nombre de plans explors afin
datteindre le but qui est un plan de cot proche du minimal possible, dit quasioptimal.
Arbre
algbrique

Schma de
stockage

Plans dexcution
Gnrateur
de plans

Stratgie
de recherche
action :
cot :
but :

{ }
rel
boolen

Rgles
de transformation

Modle de cot

Plan quasioptimal

Figure XIV.16 : Architecture dun optimiseur extensible

6. MODLE DE COT POUR BD OBJET

Un modle de cot est un ensemble de formules permettant destimer le cot dun
plan dexcution. Un optimiseur bas sur un modle de cot cherche slectionner le
plan de cot minimal parmi les plans quivalents. Le cot dun plan se compose de
plusieurs composants : le cot de calcul (CPU_Cost), le cot dentre-sorties
(IO_Cost), ventuellement le cot de communication (COM_Cost). Le premier cor-

490 BASES DE DONNES : OBJET ET RELATIONNEL

respond au temps pass excuter des instructions de lunit centrale, par exemple
pour valuer un prdicat ou excuter une boucle. Le deuxime correspond au temps
de lecture et criture sur disques. Le troisime intervient surtout dans les bases rparties o des changes de messages sont ncessaires sur le rseau.
Dans cette section, nous prsentons un modle de cot pour bases de donnes objet,
publi dans [Gardarin95]. Considrant une base centralise, nous valuons seulement
les cots dentres-sorties et de calcul. Pour simplifier, nous supposons que les objets
ont une taille infrieure une page et que les valeurs dattributs sont uniformment
distribues lintrieur de leurs domaines de variation.

6.1. PRINCIPAUX PARAMTRES

DUN MODLE DE COT
Le modle de cot utilise des statistiques sur les donnes de la base pour estimer le
cot dune opration. Ces statistiques se composent dinformations sur les collections
de la base comme la cardinalit (nombre dobjets) de ces collections, la taille
moyenne des objets, le nombre de valeurs distinctes dun attribut, la prsence dindex
et de groupes dobjets. Un bon modle de cot doit prendre en compte le placement
des objets dans des groupes (clustering). En effet, une collection C peut tre divise
en n groupes nots C1, C2Cn. Les techniques de groupage permettent de placer dans
un mme groupe des objets de collections diffrentes.
Plus prcisment, pour chaque collection dobjets C nous utilisons les statistiques suivantes :


C

la cardinalit de la collection C,

C
le nombre de pages de la collection C,


Ci

la cardinalit du groupe i de la collection C,

Ci
le nombre de pages du groupe i de la collection C,
SC la taille moyenne des objets dans la collection C.
Afin dvaluer le cot de la navigation entre objets, il est ncessaire destimer finement les cardinalits des associations entre collections. Soient deux collections C1 et
C2 relies par un chemin de traverse implment par des pointeurs de C1 vers C2.
Un tel chemin C1 C2 sera caractris par les statistiques suivantes :
FanC1,C2 le nombre moyen de rfrences dun objet de C1 vers des objets de C2,
DC1,C2 le nombre moyen de rfrences distinctes dun objet de C1 vers des objets
de C2,
XC1,C2 le nombre dobjets de C1 nayant pas de rfrences (ou des rfrences
nulles) vers des objets de C2.

Loptimisation de requtes objet 491

partir de ces paramtres, nous pouvons calculer le nombre de rfrences distinctes

des objets de C1 ayant au moins une rfrence non nulle vers des objets de C2 par la
formule :
D
*

C1


Z C1,C2 = C1,C2


C1

X C1,C2
De plus, nous supposons connus les paramtres suivants, dpendant essentiellement
de choix dimplmentation du systme :
b le degr moyen des arbres-B utiliss (par exemple 256 cls par page),
BLevel(I) le nombre de niveaux dun index I (souvent 3),
Sp la taille dune page (par exemple 4K),
Proj_Cost le cot moyen dextraction dun attribut dun objet,
m la taille mmoire disponible en page,
Cost_load_page le cot de chargement dune page en mmoire (une E/S).
Tous ces paramtres sont donc utiliss par le modle de cot dtaill ci-dessous.

6.2. ESTIMATION DU NOMBRE DE PAGES

DUNE COLLECTION GROUPE
Lorsque plusieurs collections sont groupes ensemble par des associations, il nest pas
vident de dterminer le nombre de pages balayer pour trouver les objets dans lune
S
delles. Si une collection A nest pas groupe avec dautres collection, il y a p
SA
objets au plus dans une page et le nombre total de pages aprs chargement squentiel
peut tre calcul comme suit :


A



A
=
Sp
SA

Dans le cas de plusieurs collections groupes, certaines pages peuvent tre homognes, dautres contenir des objets de diffrentes collections. Une mthode pour estimer le nombre total de pages dune collection groupe avec dautres a t propose
dans [Tang96]. Supposons que la collection B soit groupe avec la collection A (voir
figure XIV.17). Rappelons que nous notons respectivement SA et S B les tailles
moyennes des objets des collections A et B, et que SA et SB sont supposes infrieures la taille de la page. Estimons tout dabord la taille de la collection A qui est
la racine de larbre de groupage. Il existe deux partitions physiques pour A aprs le

492 BASES DE DONNES : OBJET ET RELATIONNEL

placement des deux collections, lune contenant des objets groups avec des objets de
B note ClAB, lautre ne contenant que des objets de A note ClA.
ClA

ClAB

A
ClB
B

Figure XIV.17 : Diffrentes partitions dans le cas dun groupage de B avec A

La partition Cl A contient les objets A ne rfrenant pas dobjets B, donc

ClA

=XA,B, do lon dduit la taille de cette partition :

A
C l =
A

X A, B
Sp
SA

Pour ClAB, le nombre dobjets de A dans cette partition est

A

XA,B. La taille
dun groupe autour dun objet A est SClAB = SA+(ZA,B*SB), do lon dduit :

A
C l

A XA, B
Sp
AB

si S C l

AB

< Sp

A

X A, B si S C l

AB

Sp

SC l

AB

Le nombre total de pages de la collection A est donc donn par :

A
=
A
ClA +
A
ClAB
Dune manire similaire, nous pouvons estimer le nombre de pages de la collection B,
une collection non racine dans le graphe de placement. Les diffrentes partitions composant la collection B sont notes ClAB et ClB.
Pour ClB, le nombre dobjets de B non rfrencs par un quelconque objet de A est


B

-(

A

*DA,B), do nous dduisons :

B
C l =
B

B

(

A

* DA, B)

Sp
SA

Loptimisation de requtes objet 493

Pour ClAB, la taille et le nombre dobjets par groupe reste le mme que celui calcul ci-dessus, mais le nombre de groupes auxquels accder est maintenant
XClAB= Min(ZA,B*XA,B, XA,B). Nous obtenons donc :

A
C l

B
C l

si S C l

AB

AB

< Sp

sinon
AB

A

X A, B

si Z A, B * S B S p

(

A

X A, B) *

Z A, B * S B
Sp

si Z A, B * S B > S p

Le nombre total de page de la collection B est obtenu par :

B
=
B
ClA +
B
ClAB.
Ainsi, en tudiant la taille des diffrentes partitions, il est possible de calculer la taille
globale en nombre de pages dune collection groupe.

6.3. FORMULE DE YAO ET EXTENSION

AUX COLLECTIONS GROUPES
Le modle de cot doit permettre de calculer le nombre de pages auxquelles accder
lors dune slection dune collection par un prdicat. Dans le cas de bases de donnes
relationnelles, la formule de Yao [Yao77] permet de calculer le nombre de blocs
contenant au moins un enregistrement lors dune slection de k enregistrements parmi
n.
Notion XIV.9 : Formule de Yao (Yao Formula)
Formule permettant de calculer le nombre de blocs auxquels accder lors dune slection de k enregistrements parmi n (kn) uniformment distribus dans m blocs (1<mn) comme suit :
k
yao(n,m,k) = m * 1

i=1

nd i + 1
ni+1

avec d = 1 1m

Dans le cas dune collection C groupe avec dautres, il nest pas possible dappliquer
simplement la formule de Yao pour estimer le nombre de pages auxquelles accdes
lors dune slection par un prdicat P par Yao(

C

,
C
,Sel(P)*

C

). Le problme est
quune collection groupe est compose de plusieurs partitions. Certains objets sont
groups avec des objets de collections diffrentes. Ainsi, la distribution des objets
dans les pages nest pas uniforme, bien que les collections soient supposes indpendantes dun point de vue probabiliste. Il est possible dappliquer la formule de Yao

494 BASES DE DONNES : OBJET ET RELATIONNEL

chaque partition, aprs avoir dtermin la taille de chaque partition comme vu ci-dessus, soit ||C||i objets et |C|i pages pour la partition i. Nous obtenons alors la formule de
Tang pour le calcul des entre-sorties [Tang96].
Notion XIV.10 : Formule de Tang (Tang Formula)
tant donn une collection C divise en p partitions, chacune ayant

C

i objets et

C

i pages, la
slection alatoire de k objets de C ncessite laccs :
Tan g(C,k) =

i=1

yao (

C i

,
C i
, k i)

o ki est le nombre dobjets slectionns dans la partition Ci.

Si les objets slectionner sont placs uniformment dans les partitions, on slectionne ki = (

Ci

/

C

)*k dans la partition i. Quand les objets qui satisfont le prdicat
de recherche ne sont pas placs uniformment, il faut calculer la slectivit du prdicat dans chaque partition pour calculer ki. Bien que drive de la formule de Yao, la
formule de Tang est plus gnrale que celle de Yao, qui en est un cas particulier pour
une collection avec une seule partition.

6.4. COT DINVOCATION DE MTHODES

Avec lapproche objet, les attributs peuvent tre publics ou privs. Les attributs
publics sont directement accessibles et le cot dextraction peut tre assimil une
constante. Il peut aussi tre plus prcisment dtermin en fonction du type de lattribut et de sa longueur en octets.
Les attributs privs sont manipuls par des mthodes. Dterminer le cot dune
mthode nest pas chose simple. Deux approches ont t proposes pour cela.
Notion XIV.11 : Rvlation de cot (Cost rvlation)
Technique consistant fournir une mthode de calcul de cot associe chaque opration dune
classe, avec des paramtres identiques ou simplifis.

Par exemple, si une classe Gomtrie publie une fonction distance(gomtrie), elle
pourra aussi publier une fonction cot_distance(gomtrie). Le cot pourra tre trs diffrent selon les gomtries sur lesquelles sapplique la fonction : il est par exemple beaucoup plus simple de calculer la distance de deux points que celle de deux polygones.
Notion XIV.12 : Moyennage de cot (Cost averaging)
Technique consistant mmoriser le cot moyen dapplication dune mthode au fur et mesure de
son utilisation.

Loptimisation de requtes objet 495

Au dpart, le cot de la mthode est inconnu, et estim par exemple comme une projection sur attribut. Puis, suite aux requtes ou des demandes destimation de
ladministrateur (par une requte spcifique ANALYZE <mthode>), la mthode
est excute sur un chantillon de N objets. Une table est gre dans la mta-base
pour maintenir le cot moyen observ, de schma simplifi COSTMETHOD (cot
real, nombre int), cot tant le cot moyen et nombre le nombre dexcutions observes. La table peut aussi mmoriser le type des paramtres, les heures
dappels, etc., afin dobtenir des statistiques plus fines.

6.5. COT DE NAVIGATION VIA EXPRESSION

DE CHEMIN
Ce cot dpend videmment de lalgorithme de travers de chemin utilis. Nous analysons ici le cas o une expression de chemin avec prdicats est value en utilisant
lalgorithme en profondeur dabord (DFF) vu ci-dessus. Soit une expression de chemin entre des collections C1, C2Cn qualifie par des prdicats P1, P2Pn chaque
niveau. Une telle expression est note C1 (P1).C2 (P2) Cn(Pn). Dsignons par Ai
lattribut de Ci-1 rferenant un ou plusieurs objets de la collection Ci. Soit Si la slectivit du prdicat Pi (Si = Sel(Pi)). Lalgorithme DFF accde successivement, pour
chaque objet de la collection de niveau i satisfaisant le prdicat Pi, lattribut pointant
sur les objets de la collection (i+1). Suivant ces liens, il lit les pages successives des
collections en profondeur dabord. Pour simplifier, nous supposons quil existe au
moins une page disponible en mmoire par collection.
Calculons tout dabord le nombre de rfrences Refi distinctes moyennes pointant
dun objet de la collection Ci-1 vers un objet de Ci dans le chemin, soit Refi = (1Probi)*

Ci

. Probi est la probabilit quun objet de la collection Ci ne soit pas pris en
compte dans le chemin, probabilit calcule par la formule :
1 (Refi 1 * Si 1 * fan c i 1, c i)
Probi = 1


C i


Selon la taille mmoire disponible, trois cas sont possibles :
Si la mmoire disponible p est assez grande pour contenir toutes les pages du chemin, chaque page est charge une fois et une seule. Selon que le groupage est effectu selon la rfrence ou non, on effectue laccs Refi objet de la collection en 0
ou en Tang(Ci,Refi) entre-sorties, do lon calcule le nombre de pages lues :
n

Page min =

i=2

0 si C i 1 est groupe avec C i

Tang(Ci , Refi ) sinon

Si le nombre de pages disponibles en mmoire p est exactement la taille du chemin

(p = n), nous obtenons le cas limite trs dfavorable :

496 BASES DE DONNES : OBJET ET RELATIONNEL

Page m ax =

i=2

0 si C i 1 est groupe avec C i

* S j 1 sinon


C 1

* fan C
j 1, C j
j=2

Si le nombre de pages disponibles en mmoire p est compris entre n et Pagemin, la

mmoire ne peut contenir toutes les pages ncessaires lvaluation de lexpression
de chemin. Le cot dentres-sorties dpend de la politique de remplacement des
pages du SGBD. Certaines pages devront tre lues plusieurs fois. Il est possible
dapprocher le nombre dentres-sorties par une fonction linaire entre Pagemin et
Pagemax, comme suit :
Page max Page min
NbPage =
* (n p) + Page max
Page min n
Finalement, le cot dvaluation dun prdicat P constitu dune expression de chemin
qualifie avec p pages disponibles en mmoire centrale est :
NbPage if n p < Page min
IO_Eval_Cost(P) =
Page min if p Page min
Le cot de calcul associ lvaluation dun tel prdicat est le cot de projection plus
le cot dvaluation des prdicats lmentaires pour chaque objet travers, soit :
CPU_Eval_Cost(P) =

C 1

* (CPU_Pr oj_Cost
n

+ CPU_Comp_Cost) * fan C , C * S j 1)
j1
J
i = 2i = 2

6.6. COT DE JOINTURE

En dehors des parcours de rfrences valus ci-dessus pour lalgorithme DFF, les
algorithmes de jointures sont analogues ceux des bases relationnelles. Vous pouvez
donc vous reporter au chapitre concernant loptimisation de requtes dans les BD relationnelles pour trouver les formules de cot applicables. Des formules plus dtailles
pourront tre trouves dans [Harris96]. Plus gnralement, en dehors du groupage des
objets, des parcours de rfrences et des index de chemins, les BD objet nont gure
dautres spcificits dimplmentation.

Loptimisation de requtes objet 497

7. STRATGIES DE RECHERCHE
DU MEILLEUR PLAN
La recherche du meilleur plan dexcution dans une base de donnes objet ou objetrelationnel est encore plus complexe que dans une base relationnelle. En effet,
lespace des plans est plus large du fait de la prsence de rfrences, dindex de chemins, de collections imbriques, etc. Au-del de la programmation dynamique classique limite des espaces de recherche de faible taille [Swami88, Swami89,
Vance96] vue dans le cadre relationnel, des mthodes doptimisation pour la
recherche de plans optimaux base sur des algorithmes alatoires ont t proposes.
Aprs les avoir prsents, nous proposons une mthode plus avance base sur des
algorithmes gntiques.

7.1. LES ALGORITHMES COMBINATOIRES

Les algorithmes combinatoires accomplissent une marche au hasard dans lespace de
recherche sous la forme dune suite de dplacement. Un dplacement dans cet espace
est gnr par application dune rgle de transformation sur le plan dexcution. Un
dplacement est appel descendant sil diminue le cot du plan, montant sil laugmente. Un tat (donc un plan) est un minimum local si tout dplacement unitaire augmente son cot. Le minimum global est celui parmi les minimums locaux qui a le plus
faible cot. Cette classe dalgorithmes inclut lamlioration itrative (Iterative
Improvement [Nahar86]), le recuit simul (Simulated Annealing [Ioannidis87]),
loptimisation deux phases (Two Phase Optimization [Ioannidis90]) et la recherche
taboue (Tabu Search [Glover89, Glover90]). Nous prsentons en dtail ces mthodes
ci-dessous.

7.2. LAMLIORATION ITRATIVE (II)

Lamlioration itrative commence par un plan dexcution initial choisi plus ou
moins alatoirement, par exemple celui rsultant de la compilation directe de la
requte utilisateur. Ensuite, seuls les dplacements descendants sont accepts. Cest
loptimisation locale. Quand le minimum local est atteint, lalgorithme gnre au
hasard un nouveau plan, et recommence loptimisation locale partir de ce nouveau
plan. Le processus est rpt jusqu atteindre une condition darrt, par exemple
lpuisement du temps doptimisation. Le minimum global est le meilleur minimum
local trouv lors de larrt. Lalgorithme est donn en pseudo-code figure XIV.18.

498 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XIV.13 : Amlioration itrative (Itrative improvment)

Technique doptimisation consistant choisir alatoirement des plans dans lespace de recherche,
les optimiser localement au maximum, et enfin retenir le meilleur des minima locaux comme plan
optimal.

Procedure II(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
while not(condition_arrt) do { // Boucle doptimisation globale
while not (condition_locale) do { // Boucle doptimisation locale
p = dplacer(p); // Appliquer une transformation valide p
if (Cot(p)<Cot(p)) then p = p; // Garder si moins coteux
}
// Slectionner le plan optimal
if cot(p)<cot(PlanOptimal) then PlanOptimal = p;
p = Random(p) ; // Se dplacer au hasard vers un autre plan
}
Return(PlanOptimal);
}

Figure XIV.18 : Algorithme damlioration itrative

7.3. LE RECUIT SIMUL (SA)

Le recuit simul part galement dun plan initial choisi plus ou moins alatoirement et
gnre des plans successifs par application de rgles de transformation valide de ce
plan. la diffrence de lamlioration itrative, le recuit simuler accepte la fois des
dplacements descendants et montants. Lide originelle est de simuler le refroidissement dun mtal recuit : tant que le mtal est chaud, les mouvements de molcules
sont nombreux, puis ils dcroissent comme la temprature. Donc, quand le systme
est chaud, les dplacements montants qui dtriorent le cot du plan sont admis afin
de permettre une exploration plus large de lespace autour du plan en cours danalyse,
pour dcouvrir dautres minima locaux. Ces dplacements sont permis avec une probabilit qui dcrot avec la temprature : P = e DeltaCot/Temprature. Le paramtre
Temprature reprsente la temprature du systme. Il dcrot au fur et mesure de
lavancement de loptimisation, si bien que les mouvements ascendants sont accepts
avec une probabilit de plus en plus faible. DeltaCot est la diffrence de cot
entre les deux plans. Quand la condition darrt est atteinte (temps puis), le meilleur
plan travers est slectionn et retenu comme pseudo-optimal. La figure XIV.19
donne la procdure correspondante en pseudo-code.

Loptimisation de requtes objet 499

Notion XIV.14 : Recuit simul (Simulated Annealing)

Technique doptimisation consistant choisir alatoirement un plan dans lespace de recherche et
explorer alentour par des dplacements descendants ou ascendants, ces derniers tant accepts
avec une probabilit qui tend vers 0 quand la temprature tend vers 0.

Procdure SA(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
T = T0; // Initialiser la temperature
while not(condition_arrt) do { // Boucle doptimisation globale
while not(equilibrium) do { // Boucle doptimisation locale
p = dplacer(p); // Appliquer une transformation valide p
delta = cost(p)-cost(p); // Calculer la diffrence de cot
if (delta<0) then p = p; // Si cot rduit prendre le nouveau plan
// Si cot accru, accept si chaud
if (delta>0) then p = p with probability e delta/T;
// Maintenir le plan optimal
if cost(p)<cost(PlanOptimal) then PlanOptimal = p;
}
T = reduce(T); // Reduire la temprature
}
Return(PlanOptimal); }

Figure XIV.19 : Algorithme de recuit simul

7.4. LOPTIMISATION DEUX PHASES (TP)

Lamlioration itrative travaille efficacement pour couvrir de grands espaces et trouver rapidement des minima locaux. Elle ne garantit gure une couverture fine autour
de ces minima. Le recuit simul est bien adapt pour explorer autour dun minimum
local. Do lide de combiner les deux [Ioannidis90], ce qui conduit loptimisation
deux phases. Tout dabord, une phase amlioration itrative (II) est excute pour
trouver les tats initiaux de la phase recuit simul (SA) suivante. Ainsi, loptimisation
deux phases travaille comme suit [Steinbrunn97] :
1. Pour un petit nombre de plans alatoirement slectionns, des minima locaux sont
cherchs en appliquant II, puis
2. partir du (ou des) moins coteux de ces minima locaux, SA est appliqu afin
dexplorer le voisinage pour trouver de meilleures solutions.
Cette mthode mixte peut donner de bons rsultats condition de bien rgler les diffrents paramtres (temps de chaque phase, temprature).

500 BASES DE DONNES : OBJET ET RELATIONNEL

7.5. LA RECHERCHE TABOUE (TS)

La recherche taboue (TS) est une procdure du type mta-heuristique trs efficace
pour loptimisation globale [Glover89]. Lide principale est de faire chaque pas le
meilleur dplacement possible, tout en vitant une liste de plans tabous. Lutilisation
dune liste de tabous permet dviter des recherches inutiles et de converger plus vite
vers des solutions proches de loptimal. TS part dun plan initial gnr alatoirement,
et accomplit les meilleurs mouvements non interdits successivement. chaque itration, la procdure gnre un sous-ensemble V* de lensemble des voisins non interdits
du plan courant. Le sous-ensemble ne contient donc pas de plans de la liste des
tabous. Les plans dj explors sont gnralement retenus, au moins pour un temps,
dans la liste des tabous, ce qui vite en gnral de boucler. La liste des tabous est mise
jour chaque fois quun nouveau plan est explor pour mmoriser les plans dj vus.
La figure XIV.20 donne le pseudo-code correspondant cet algorithme.
Notion XIV.15 : Recherche taboue (Tabou search)
Technique doptimisation consistant se dplacer alentour vers le plan de cot minimal tout en vitant une liste de plans interdits dynamiquement mise jour.

Procedure TS(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
T = ; // initialiser la liste taboue
while not(condition_arrt) do { // boucle globale
// accepter tous les mouvements non tabous
gnrer V*N(p)-T en appliquant dplacer(p);
choisir le meilleur plan p V*; // Prendre le meilleur plan
T= (T-(plus vieux)){p}; // Mettre jour la taboue liste
// maintenir le plan optimal
if cot(p)<cot(PlanOptimal) then PlanOptimal = p;
}
return(PlanOptimal);
}

Figure XIV.20 : Algorithme de recherche taboue

7.6. ANALYSE INFORMELLE DE CES ALGORITHMES

La performance de tous les algorithmes prcdents dpend fortement de la distribution de la fonction de cot sur lespace de recherche. Alors que le recuit simul (SA)
et la recherche taboue (TS) dpendent fortement du plan initial, lamlioration itra-

Loptimisation de requtes objet 501

tive (II) et loptimisation deux phases (TP) utilisent une transformation alatoire pour
explorer cet espace. Pour amliorer les performances de ces algorithmes, des
mthodes de transformation darbres introduisant une meilleure couverture de
lespace de recherche ont t mises au point. Ce sont par exemple lchange de jointures et le swap [Swami89, Lanzelotte93]. Lchange de jointure permute alatoirement des relations alors que le swap change des parties darbres. De telles mthodes
ont t introduites seulement pour les jointures relationnelles. Il est possible de les
tendre au cas objet.
Suite aux mouvements ascendants, SA est gnralement plus lent que les autres
mthodes mais trouve souvent de meilleurs plans que II quand le temps de recherche
est suffisant. TP combine les avantages de SA et II. Il a t montr [Ioannidis90] que
TP trouve en gnral de meilleurs plans que SA et II. TS est rapide mais accomplit
une recherche agressive. En consquence, lalgorithme peut rester bloqu sur un minimum local. Ceci peut tre vit avec une longue liste taboue, mais la recherche ralentit alors lalgorithme.
II, SA, TP et TS utilisent tous une fonction appele dplacer. Celle-ci applique
lune des rgles de transformation pour trouver un plan quivalent. Comme vu ci-dessus, dans une base de donnes objet ou objet-relationnel avec beaucoup de types, le
nombre de rgles peut tre important. Certaines ne provoquent que de petits dplacements dans lespace des plans, dautres de beaucoup plus larges. Il faudrait donc pouvoir introduire des transformations permettant dappliquer des squences de rgles, et
donc de faire de grands sauts dans lespace des plans. Nous allons tudier une
mthode permettant de telles transformations dans la section suivante.

8. UN ALGORITHME DOPTIMISATION
GNTIQUE
Dans cette section, nous tudions lapproche gntique et son application possible
loptimisation de requtes [Bennett91]. Pour lillustrer concrtement, nous tudions le
cas de longues expressions de chemins avec prdicats. Les expressions de chemins
sont importantes dans les BD objets ; certains SGBD se concentrent dailleurs sur leur
optimisation et ne proposent gure dautres optimisations.

8.1. PRINCIPE DUN ALGORITHME GNTIQUE

Lalgorithme gntique (GA) est un algorithme doptimisation bas sur les principes
dvolution des organismes dans la nature : lalgorithme cherche gnrer les

502 BASES DE DONNES : OBJET ET RELATIONNEL

meilleurs lments dune population en combinant les meilleurs gnes ensemble.

Cest une famille dalgorithmes utiliss dans la recherche dextrema (minimum ou
maximum) de fonctions plusieurs variables [Holland75, Goldberg89]. Ces fonctions
sont gnralement dfinies sur des domaines discrets vastes et complexes. Dans notre
cas, il sagit de retrouver idalement le minimum global de la fonction de cot dans
lespace des plans. Au lieu de travailler sur une solution particulire chaque tape,
lalgorithme considre une population de solutions. Diverses sortes dalgorithmes
gntiques ont t proposes pour diffrentes tches doptimisation. La figure XIV.21
reprsente un algorithme type utilisable pour la recherche du meilleur plan.

Initialisation

Mutation

Croisement

valuation
Tri
Slection

Non

Fin ?

Figure XIV.21 : Algorithme gntique type

Voici les fonctions des principaux blocs dun tel algorithme :

Initialisation gnre une petite population initiale de solutions (dans notre cas, des
plans dexcution) couvant lespace de recherche.
Mutation choisit une solution (cest--dire un plan) de la population, et lui applique
des rgles de transformation.
Croisement choisit deux solutions dans la population et change leurs gnes communs (dans notre cas, des sous-arbres quivalents) pour gnrer deux nouvelles
solutions.
valuation value, pour chaque solution, la fonction optimiser, dans notre cas la
fonction de cot.

Loptimisation de requtes objet 503

Tri trie la population en fonction du cot.

Slection choisit un certain nombre des meilleurs lments comme parents pour la
prochaine gnration.
Fin test le critre darrt afin de stopper loptimisation.
Le cur de lalgorithme est la gnration dune nouvelle population par les oprateurs
de mutation et de croisement. chaque gnration, une partie de la population subit
la mutation et lautre le croisement. La mutation est identique au dplacement des
algorithmes vus ci-dessus. Ce qui est nouveau, cest le croisement qui permet de
construire une solution partir de deux solutions. Avec la slection naturelle, il est
permis de penser que le croisement ne laissera se propager que les bons gnes, pour
converger vers les bons plans. En rsum, la notion dalgorithme gntique peut tre
dfinie comme suit :
Notion XIV.16 : Algorithme gntique (Genetic algorithm)
Algorithme de recherche doptimum consistant partir dune population et la faire se reproduire
par mutation et croisement, en slectionnant les meilleurs lments chaque gnration, de sorte
converger vers une population contenant la solution optimale ou presque.

8.2. BASES DE GNES ET POPULATION INITIALE

Nous appliquons maintenant lalgorithme gntique loptimisation des expressions
de chemins. Comme vu ci-dessus, diffrentes mthodes de jointures peuvent tre
appliques : la jointure n-aire DFF en profondeur dabord, la jointure binaire en largeur dabord note FJ (plusieurs jointures peuvent tre excutes successivement, ce
qui donne lalgorithme BFF), la jointure en arrire note RJ, et la traverse dun index
de chemins lorsquil en existe un, note PI. Touts ces mthodes apparaissent comme
des gnes permettant de gnrer la population des plans. La figure XIV.22 reprsente
la base de gnes avec cinq collections lies par une chane dassociation. Sil ny a ni
lien inverse ni index de chemin, le nombre total de gnes est le nombre de cellules
dans le triangle suprieur de la figure XIV.22 gnralise n, soit :
Genes = 1 + 2 + ... + (n 1) + 2 * (n 1) = (n 2 + 3 * n 2)2
Dans tous les cas, le nombre de gnes est de lordre de O(n2). Un plan dexcution
peut tre vu comme une combinaison de gnes dont le rsultat permet le parcours du
chemin, dans un sens ou dans lautre, ceci afin de trouver le rsultat de la requte.
Lobjectif de loptimiseur est de trouver la meilleure combinaison de gnes pour obtenir le plan de cot minimal.

504 BASES DE DONNES : OBJET ET RELATIONNEL

DFF/PI
(0,4)

DFF/PI
(0,3)

DFF/PI
(0,2)
FJ/PI/RJ
(0,1)

DFF/PI
(1,4)

DFF/PI
(1,3)
FJ/PI/RJ
(1,2)

FJ/PI/RJ
(1,0)

DFF/PI
(2,4)
FJ/PI/RJ
(2,3)

FJ/PI/RJ
(2,1)
DFF/PI
(2,0

FJ/PI/RJ
(3,4)

FJ/PI/RJ
(3,2)
DFF/PI
(3,1)

DFF/PI
(3,0)

FJ/PI/RJ
(4,3)
DFF/PI
(4,2)

DFF/PI
(4,1)
DFF/PI
(4,0)

Figure XIV.22 : Base de gnes pour cinq collections

Ltape dinitialisation consiste gnrer alatoirement une population initiale de

plans. Notons quune telle population est gnre par des parcours alatoires dans la
base de gnes de la figure XIV.22, depuis la collection source jusqu la collection
cible. De tels parcours vitent les produits cartsiens, ce qui est gnralement sage.

8.3. OPRATEUR DE MUTATION

La mutation est un des oprateurs importants dune mthode gntique. chaque
tape, un certain pourcentage des plans doit subir une mutation. Cette procdure
consiste simplement slectionner un sous-arbre et lui appliquer une rgle de transformation valide. Quelques exemples de mutation possibles sont reprsents
figure XIV.23. La mutation apporte de nouveaux gnes qui peuvent ne pas exister
dans la population courante.

Loptimisation de requtes objet 505

DFF
A

RJ
C

DFF
B

Si liens inverses

FJ
A

RJ
C

FJ
B

FJ
C

DFF
A

FJ

RJ

PI
C

Figure XIV.23 : Exemples de mutations possibles

8.4. OPRATEUR DE CROISEMENT

Cet oprateur consiste mixer deux lments de la population pris plus ou moins au
hasard. Par exemple, deux plans sont choisis et leurs sous-arbres communs sont changs. Deux sous-arbres sont quivalents sils ont les mmes feuilles et gnrent les
mmes rsultats. La figure XIV.24 illustre un croisement. Alors que la mutation transforme un plan en lun de ses voisins, en accomplissant de petits mouvements, le croisement peut accomplir de plus larges transformations. Il permet ainsi de sortir de zone voisine dun minimum local, en sautant vers une autre partie de lespace de recherche.
La figure XIV.25 donne le pseudo-code de lalgorithme gntique appliqu loptimisation des expressions de chemins. Nous utilisons le tableau Popu pour reprsenter la
population. Chaque lment contient deux variables : un plan et son cot. BasePopu
contient les plans subissant le croisement ou la mutation. Comme la population
saccrot aprs le croisement, la procdure de slection est applique avant de passer
la nouvelle gnration. Celle-ci conserve les plans de cots minimaux. Pendant le
croisement, le plus grand sous-arbre commun des deux parents est choisi. Si deux
parents nont pas de sous-arbre commun, ils sont soumis la mutation. Les plans
rsultants du croisement sont placs de BasePopu + 1 NewPopu. Part est le
pourcentage de la population effectuant un croisement.

506 BASES DE DONNES : OBJET ET RELATIONNEL

RJ
FJ
A

DFF
DFF

crossover
RJ
FJ

RJ

FJ

RJ
D

FJ

E
F

Figure XIV.24 : Oprateur de croisement

Procedure GA(Question) {
Gnrer(Popu[BasePopu]) ; // Initialiser la population alatoirement
Sort(Popu) ; // Trier la population des plans par cot croissant
PlanOptimal = Popu[0] ; // Garder le meilleur plan trouv
While not (condition_arrt) do {
Pourcent = 0;
While Pourcent < Part * BasePopu do {
// Appliquer croisement Part de la population
p1 = Popu[Random(BasePopu)] ; // Choisir p1 et p2 de Popu
p2 = Popu[Random(BasePopu)] ; // alatoirement
Croisement(p1, p2) ; // Les croiser si possible
Pourcent = Pourcent + 2 ;
}
For le reste de Popu do Mutation ; // Mutation pour les autres
For (i=0 ; i < NewPopu ; i++) do evaluate(Popu[i]) ; // Calcul du cot
Trier(Popu) ; // Trier la population par cot croissant
PlanOptimal = Popu[0] ; // Garder le meilleur plan trouv
}
return(PlanOptimal) ;
}

Figure XIV.25 : Une implmentation de lalgorithme gntique

Loptimisation de requtes objet 507

Des expriences effectues avec cet algorithme ont montr quil pouvait tre amlior
en ajoutant des plans alatoirement gnrs chaque gnration, ceci afin de garantir
la diversit des plans explors [Tang96]. Les limites de tels algorithmes doptimisation appliqus aux bases de donnes, notamment dans le cas dun trs grand nombre
de rgles, restent encore dcouvrir.

9. CONCLUSION
Dans ce chapitre, nous avons tudi diffrentes techniques doptimisation pour les
SGBD objet. Tout dabord, les techniques de groupage des objets sur disques permettent de placer proximit les objets souvent accds ensemble, par exemple via des
parcours de chemins. Elles prolongent les techniques de groupage des relations par
jointures pr-calcules de certains SGBD relationnels. Au-del, les index de chemins
constituent aussi une spcificit des BD objet ; ils peuvent tre perus comme une
extension des index de jointure des BD relationnelles.
Ensuite, nous avons tudi diffrents algorithmes de parcours de chemins. Ces algorithmes permettent la navigation ensembliste dans les BD objet. Ils sont des extensions naturelles des algorithmes de jointures [Valduriez87], quils tendent en utilisant
des identifiants dobjets.
La gnration de plans quivalents est plus complexe que dans le cas relationnel, surtout
par la ncessit de prendre en compte les types de donnes utilisateurs et les rcritures
dexpressions de mthodes associes. Ceci ncessite le dveloppement doptimiseurs
extensibles, supportant lajout de rgles de rcriture. Ce sont de vritables systmes
experts en optimisation, qui sont maintenant au cur des SGBD objet-relationnel.
Le dveloppement dun modle de cot pour bases de donnes objet est un problme
des plus difficiles. Il faut prendre en compte de nombreuses statistiques, les groupes,
les rfrences, les index de chemins, les mthodes et les diffrentes formes de collections. Nous avons prsent un modle de cot simple labor par extension des
modles classiques des BD relationnels. Peu doptimiseurs prennent en compte un
modle de cot intgrant les spcificits de lobjet, par exemple les mthodes.
Beaucoup reste faire.
Nous avons enfin dvelopp des stratgies de recherche sophistiques pour trouver le
meilleur plan dexcution. Beaucoup ont t proposes et paraissent suffisantes pour
des questions mettant en jeu une dizaine de collections. Au-del, les stratgies gntiques semblent prometteuses. Peu de SGBD utilisent aujourdhui ces stratgies, la
plupart restant bass sur la programmation dynamique. Lintgration dans des systmes pratiques reste donc faire.

508 BASES DE DONNES : OBJET ET RELATIONNEL

10. BIBLIOGRAPHIE
[Amsaleg93] Amsaleg L., Gruber O., Object Grouping in EOS , Distributed Object
Management, Morgan Kaufman Pub., San Mateo, CA, p. 117-131, 1993.
EOS est un grant dobjets un seul niveau de mmoire ralis lINRIA de
1990 1995. Une technique originale de groupement dobjets avec priorit a
t propose, ainsi que des techniques de ramassage de miettes.
[Bertino89] Bertino E., Kim W., Indexing Techniques for Queries on Nested
Objects , IEEE Transactions on Knowledge and Data Engineering, vol. 1(2),
June 1989, p. 196-214.
Cet article compare diffrentes techniques dindexation pour les bases de donnes objet, en particulier plusieurs techniques dindex de chemins et dindex
spars ou groups (multi-index) dans le cas de hirarchie de gnralisation.
[Bertino91] Bertino E., An Indexing Technique for Object-Oriented Databases ,
Proceedings of Int. Conf. Data Engineering, Kobe, Japan, p. 160-170, April
1991.
Cet article dveloppe le prcdent et propose des techniques de recherche et
mise jour avec index de chemin.
[Bertino92] Bertino E., Foscoli P., An Analytical Model of Object-Oriented Query
Costs , Persistent Object Systems, Workshop in Computing Series, SpringerVerlag, 1992.
Les auteurs dveloppent un modle de cot analytique pour BD objet. Celui-ci
prend notamment en compte les index de chemin.
[Bennett91] Bennett K., Ferris M.C., Ioannidis Y.E., A Genetic Algorithm for
Database Query Optimization , Proc. 4th International Conference on Genetic
Algorithms, San Diego, CA, p. 400-407, June 1991.
Cet article a propos pour la premire fois lutilisation dun algorithme gntique dans les bases de donnes objet.
[Christophides96] Christophides V., Cluet S., Moerkotte G., Evaluating Queries
with Generalized Path Expressions , Proceedings of the 1996 ACM SIGMOD
International Conference on Management of Data, ACM Ed., 1996.
Cet article propose dtendre OQL avec des expressions de chemin gnralises, par exemple traversant de multiples associations. Des techniques dvaluation de telles expressions de chemin sont discutes. Il est montr comment
ces techniques peuvent tre intgres dans le processus doptimisation.
[Cluet92] Cluet S., Delobel C., A General framework for the Optimization of ObjectOriented Queries , Proceedings of the 1992 ACM SIGMOD International
Conference on Management of Data, ACM Ed., p. 383-392, 1992.

Loptimisation de requtes objet 509

Cet article dveloppe un cadre gnral pour loptimisation de requtes objet

bas sur la rcriture de graphes doprations. Il tend la rcriture dexpressions algbriques en introduisant une sorte de graphe de flux. Les nuds reprsentent les collections et les arcs les oprations. Des informations de typage
sont ajoutes aux nuds. La rcriture des expressions de chemins est intgre
la rcriture des expressions algbriques. Les index et le groupage sont aussi
pris en compte.
[Cluet94] Cluet S., Moerkotte G., Classification and Optimization of Nested
Queries xin Object bases , Journes Bases de Donnes Avances, 1994.
Cet article contient une classification des requtes imbriques en OQL. Il propose des techniques de dsimbrication bases sur la rcriture algbrique.
[DeWitt93] DeWitt D., Lieuwen D., Mehta M., Pointer-based join techniques for
object-oriented databases , Proceedings of Parallel and Distributed System
International Conf., San Diego, p. 172-181, CA, 1993.
Les auteurs comparent divers algorithmes de traverses de chemin dans les
bases de donnes objet. Ils comparent leurs performances et tudient la paralllisation.
[Finance94] Finance B., Gardarin G., A Rule-Based Query Optimizer with Multiple
Search Strategies, Data & Knowledge Engineering Journal, North-Holland Ed.,
vol. 13, n 1, p. 1-29, 1994.
Un article proposant un optimiseur extensible pour bases de donnes objets :
loptimiseur est bas sur des rgles de transformations darbres doprations
algbriques, exprimes sous la forme de rgles de rcriture de termes. Les
restructurations incluent des rgles syntaxiques (descente des oprations de filtrages, permutation des jointures) et smantiques (prises en compte de
contraintes dintgrit). La stratgie de recherche est elle-mme paramtrable
par des rgles. Un tel optimiseur a t implment dans le projet Esprit EDS.
[Florescu96] Florescu D., Espaces de Recherche pour lOptimisation des Requtes
Orientes Objets , Thses de Doctorat, Universit de Paris VI, Versailles,
1996.
Cette excellente thse de doctorat dcrit la conception et la ralisation dun
optimiseur extensible pour bases de donnes objet. Les rgles de rcriture sont
introduites par des quivalences de requtes. Ceci permet de traiter des cas
varis, comme les ordonnancements de jointures, les rcritures de chemins, la
prise en compte de rgles smantiques et de vues concrtes, etc. Loptimiseur
est capable dappliquer diffrentes stratgies de recherche diffrents niveaux.
[Gardarin95] Gardarin G., Gruser J.R., Tang Z.H., A Cost Model for Clustered
Object-Oriented Databases , Proceedings of 21st International Conference on
Very Large Databases, Zurich, Switzerland, 1995, p. 323-334.

510 BASES DE DONNES : OBJET ET RELATIONNEL

Cet article prsente les techniques de groupage avec priorit et le modle de

cot pour BD objet dcrits ci-dessus.
[Gardarin96] Gardarin G., Gruser J.R., Tang Z.H., Cost-based Selection of Path
Expression Processing Algorithms in Object-Oriented Databases ,
Proceedings of the 22nd International Conference on Very Large Data Bases,
Bombay, India, 1996, p. 390-401.
Cet article dtaille les principaux algorithmes dexpression de chemins prsents ci-dessus, tudie leur cot et propose des heuristiques permettant de choisir
le meilleur algorithme.
[Glover89] Glover F., Tabu Search-part I , ORSA Joinal on Computing 1, p. 190206, 1989.
[Glover90] Glover F., Tabu Search-part II , ORSA Joinal on Computing 2, p. 4 32,
1990.
Deux articles de rfrence qui dveloppent les techniques de recherche taboues.
[Goldberg89] Goldberg D. E., Genetic Algorithms in Search Optimization and
Machine Learning, Addison-Wesley, Reading, MA, 1989.
Ce livre dcrit des stratgies de recherche doptimum, notamment pour
lapprentissage. Une place importante est rserve aux algorithmes gntiques.
[Graefe93] Graefe G., McKenna W., The Volcano Optimizer Generator ,
Proceedings of the 9th International Conference on Data Engineering, IEEE
Ed., p. 209-218, 1993.
Cet article dcrit loptimiseur extensible Volcano, bas sur des rgles de rcriture dont les conditions et les actions sont crites comme des procdures C.
Volcano supporte loptimisation de plans pour architecture parallle.
[Haas89] Haas L. M., Cody W.F., Freytag J.C., Lapis G., Lindsay B.G.,
Lohman G.M., Ono K., Pirahesh H., Extensible Query Processing in
Starburst , Proceedings of the 1989 ACM SIGMOD International Conf. on
Management of Data, ACM Ed., p. 377-388, 1989.
Starburst fut le projet de recherche qui a permis le dveloppement des techniques objet-relationnel chez IBM. Loptimiseur extensible fut un des premiers
raliss. Il distinguait la phase de rcriture de celle de planning. La premire
tait paramtre par des rgles, la seconde par des tables doprateurs.
[Harris96] E.P. Harris, K. Ramamohanarao, Join Algorithm Costs Revisited , The
VLDB Journal, vol. 5(1), p. 64-84,1996.
Cet article propose diffrents algorithmes de jointures et compare trs prcisment les cots en entres-sorties et en temps unit centrale.
[Hellerstein93] Hellerstein J. M., Michael Stonebraker, Predicate Migration:
Optimizing Queries with Expensive Predicates , ACM SIGMOD Intl. Conf. On
Management of Data, p. 267-276, 1993.

Loptimisation de requtes objet 511

Cet article discute de loptimisation de questions avec des prdicats coteux,

incluant des fonctions utilisateurs. Il propose des mthodes de transformation.
[Holland75] Holland J.H., Adaptation in Natural and Artificial Systems, University of
Michigan Press, Ann Arbor, MI, 1975.
Ce livre traite de ladaptation et introduit en particulier les algorithmes gntiques pour des fonctions multivariables.
[Ioannidis87] Ioannidis Y.E.,Wong E., Query Optimization by Simulated
Annealing , Proceedings of the 1987 ACM SIGMOD Conference on
Management of Data, San Francisco, California, p. 9-22,1987.
Cet article prsente ladaptation de la stratgie de recherche recuit simul
loptimisation de requtes Select-Project-Join. La mthode est value en
comparaison la programmation dynamique classique.
[Ioannidis90] Ioannidis Y., Kang Y.C., Randomized Algorithms for Optimizing
Large Join Queries , Proceedings of the 1990 ACM SIGMOD Intl. Conference
on Management of Data, Atlantic City, NJ, p. 312-321, 1990.
Cet article prsente ladaptation des stratgies de recherche amlioration itrative et recuit simul loptimisation de requtes Select-Project-Join. Il teste
ces algorithmes sur de larges requtes et montre que le recuit simul trouve en
gnral un meilleur plan. La mthode deux phases est alors propose pour corriger lamlioration itrative. Il est finalement montr que cette mthode est la
meilleure des trois.
[Ioannidis91] Ioannidis Y., Kang Y.C., Left-Deep vs. Bushy Trees : An Analysis of
Strategy Spaces and its Implications for Query Optimization , Proceedings of
the 1991 ACM SIGMOD International Conference on Management of Data,
Denver, Colorado, 1991, p. 168-177.
Cet article tudie les stratgies doptimisation en fonction de lespace de
recherche considr : espace limit aux arbres linaires gauches ou prenant en
compte tous les arbres, y compris les arbres branchus.
[Kim89] Kim K.C., Kim W., Dale A., Indexing Techniques for Object-Oriented
Databases , Object-oriented concepts, Databases, and Applications, W. Kim
and F. H. Lochovsky, editors, AddisonWesley, 1989, p. 371-392.
Cet article introduit et value les index de chemins.
[Kemper90] Kemper A., Moerkotte G., Advanced Query Processing in Object
Bases Using Access Support Relations , Proceedings of the 16th International
Conference on Very Large Data Bases, Brisbane, Queensland, Australia,
p. 290-301, 1990.
Cet article dcrit loptimiseur de GOM (Generic Object Model), un prototype
ralis Karlsruhe. Cet optimiseur utilise des index de chemins sous la forme
de relations support et un optimiseur bas sur des rgles de rcriture. Ces dernires permettent lintgration des index dans le processus de rcriture.

512 BASES DE DONNES : OBJET ET RELATIONNEL

[Lanzelotte91] Lanzelotte R., Valduriez P., Extending the Search Strategy in a

Query Optimizer , 17th International Conference on Very Large Data Bases,
Barcelona, Catalonia, Spain, Morgan Kaufman Pub, p. 363-373,1991.
Cet article montre comment une conception oriente objet permet de rendre
extensible un optimiseur pour bases de donnes. Plus particulirement, la stratgie de recherche peut tre paramtre et change en surchargeant quelques
mthodes de base. Les stratgies alatoires (amlioration itrative, recuit
simul, algorithmes gntiques) sont particulirement intgrables loptimiseur.
[Lanzelotte93] Lanzelotte R., Valduriez P., Zait, M. On the Effectiveness of
Optimization Search Strategies for Parallel Execution Spaces , Proceedings of
the 19th International Conference on Very Large Data Bases, Dublin, Ireland,
p. 493-504, 1993.
Cet article analyse diffrentes stratgies doptimisation pour loptimisation de
requtes parallles.
[Mitchell93] Mitchell G., Dayal U., Zdonick S., Control of an Extensible Query
Optimizer : A Planning-Based Approach , Proceedings of the
19th International Conference on Very Large Data Bases, Dublin, Ireland,
p. 517-528,1993.
Les auteurs proposent dorganiser un optimiseur en modules de connaissance
appels rgions, chaque rgion ayant sa propre stratgie de recherche. Les
rgions sont organises hirarchiquement, chaque rgion parente contrlant
ses subordonnes. Chaque rgion dcrit ses capacits via son interface. Un
niveau de contrle global utilise les capacits des rgions afin de planifier une
squence dexcutions des rgions pour traiter une requte. Le contrle global
est un planning dirig par les buts.
[Nahar86] Nahar S., Sahni S., Shragowitz E., Simulated Annealing and
Combinatorial Optimization , Proceedings of the 23rd ACM/IEEE Design
Automation Conference, Las Vegas, NV, p. 293-299, 1986.
Cet article dcrit la technique de recuit simul pour loptimisation combinatoire.
[Orenstein92] Orenstein J., Haradhvala S., Margulies B., Sakahara D., Query
Processing in the ObjectStore Database System , ACM SIGMOD Int. Conf. on
Management of Data, San Diego, Ca., 1992.
ObjectStore est un SGBD objet parmi les plus vendus. Il supporte la persistance des objets C++ de manire orthogonale aux types de donnes, la gestion
de transactions et les questions associatives. Il est bas sur une technique efficace de gestion de mmoire virtuelle intgre au systme. Les collections sont
gres comme des objets. Les questions sont intgres C++ sous forme
doprateurs dont les oprandes sont une collection et un prdicat. Le prdicat

Loptimisation de requtes objet 513

peut lui mme contenir une question imbrique. Cet article dcrit la stratgie
doptimisation de questions implmente.
[Ozsu95] Ozsu T., Blakeley J.A., Query Processing in Object-oriented Database
Systems , Modern database systems, edited by W. Kim, p. 146-174, 1995.
Cet article prsente une vue densemble des techniques doptimisation dans les
BD objet : architecture, techniques de rcriture algbriques, expressions de
chemins, excution des requtes. Cest un bon tutorial sur le sujet.
[Shekita89] Shekita E. J., Carey M. J., A Performance Evaluation of Pointer-Based
Joins , Proceddings of the 1990 ACM SIGMOD Intl. Conference on
Management of Data, New Jersey, p. 300-311, May 1990.
Cet article dcrit trois algorithmes de jointures bass sur des pointeurs. Ce sont
des variantes des boucles imbriques, du tri-fusion et du hachage hybride. Une
analyse permet de comparer ces algorithmes aux algorithmes correspondants
qui ne sont pas bass sur des pointeurs. Il est montr que lalgorithme naturel
de traverse en profondeur est peu efficace.
[Steinbrunn97] Steinbrunn M., Moerkotte G., Kemper A., Heuristic and
Randomized Optimization for the Join Ordering Problem , VLDB Journal,
p. 191-208, 1997.
Les auteurs prsentent une description assez complte et une valuation compare de tous les algorithmes doptimisation combinatoire proposs pour les
bases de donnes.
[Swami88] Swami A. N., Gupta A., Optimization of Large Join Queries ,
Proceedings of the 1988 ACM SIGMOD Intl. Conference on Management of
Data, Chicago, Illinois, p. 8-17,1988.
Il sagit du premier article ayant introduit les techniques doptimisation alatoire pour chercher le meilleur plan dexcution. Les auteurs montrent que le
problme de recherche du meilleur plan est NP complet. Les mthodes combinatoires doptimisation telles que litration itrative et le recuit simul sont
alors proposes. Des comparaisons montrent lintrt de lamlioration itrative.
[Swami89] Swami A. N., Optimization of Large Join Queries : Combining
Heuristics and Combinatorial Techniques , Proceedings of the 1989 ACM SIGMOD Conference, Portland, Oregon, 1989, p. 367-376.
Les auteurs discutent la combinaison dalgorithmes combinatoires tels que
lamlioration itrative et le recuit simul avec des heuristiques doptimisation
comme laugmentation, lamlioration locale et KBZ. Laugmentation consiste
choisir les relations dans un certain ordre croissant selon une mesure simple
la taille, la taille du rsultat attendu, la slectivit, le nombre de relations joignant, etc. Lheuristique KBZ consiste tudier tous les arbres drivant dun

514 BASES DE DONNES : OBJET ET RELATIONNEL

arbre choisi en permutant la racine. Ils dfinissent ainsi diffrents algorithmes

combins qui sont compars. Les rsultats sont encourageants pour la combinaison de lamlioration itrative avec laugmentation.
[Tan91] Tan K-L., Lu H., A Note on the Strategy Space of Multiway Join Query
Optimization Problem in Parallel Systems , ACM SIGMOD Record, vol. 20,
1991, p. 81-82.
Les auteurs tudient lespace de recherche pour un arbre de jointure quelconque dans le cas dun systme parallle. Ils estiment en particulier sa taille.
[Tang96] Tang Z., Optimisation de requtes avec expressions de chemin pour BD
objet , Thse de doctorat, Universit de Versailles, 197 pages, Versailles,
France, sept. 1996.
Cette thse dveloppe et compare trois algorithmes de traverse de chemins.
Lauteur discute leur intgration dans le processus doptimisation. Une stratgie gntique est propose pour choisir la meilleure traverse pour de longs
chemins. Diverses comparaisons dmontrent lintrt de cette mthode. Un
modle de cot pour BD objet voisin du modle dcrit ci-dessus est dvelopp,
avec la formule de Tang.
[Valduriez87] Valduriez P., Optimization of Complex Database Queries Using Join
Indices , Database Engineering Bulletin, vol. 9, 1986, p. 10-16.
Cet article introduit les index de jointures, prcurseur des index de chemins.
[Vance96] Vance B., Maier D., Rapid Bushy Join-order Optimization with Cartesian
Products , Proceedings of the 1996 ACM SIGMOD Conference on
Management of Data, Montreal, Canada, p. 35-46, 1996.
Cet article montre quil est possible dimplmenter avec les techniques
actuelles un optimiseur capable de considrer tous les arbres de jointures, y
compris ceux avec des produits cartsiens.
[Yao77] Yao S.B., Approximating the Number of Accesses in Database
Organizations , Comm. of the ACM, vol. 20, n 4, p. 260-270, April 1977.
Cet article introduit la fameuse formule de Yao.

Partie 4

AU-DEL DU SGBD

XV Bases de donnes dductives (Deductive databases)

XVI Gestion de transactions (Transaction management)
XVII Conception des bases de donnes (Database Design)
XVIII Nouvelles perspectives (New developments)

Chapitre XV

BASES DE DONNES
DDUCTIVES
1. INTRODUCTION
Depuis que la notion de base de donnes dductive est bien comprise [Gallaire84],
sous la pression des applications potentielles, les concepteurs de systmes sefforcent
de proposer des algorithmes et mthodes efficaces pour raliser des SGBD dductifs
traitant de grands volumes de faits (les bases de donnes classiques) et de rgles.
Lobjectif est de fournir un outil performant pour aider la rsolution de problmes,
exprims sous forme de requtes, dont la solution ncessite des volumes importants
de donnes et de rgles. Les applications potentielles sont nombreuses. Outre la gestion classique ou prvisionnelle, nous citerons par exemple laide la dcision, la
mdecine, la robotique, la productique et plus gnralement toutes les applications de
type systmes experts ncessitant de grands volumes de donnes. Il a mme t possible de penser que lcriture de rgles rfrenant de grandes bases de donnes remplacerait la programmation classique, au moins pour les applications de gestion. Ces
espoirs ont t quelque peu dus, au moins jusqu aujourdhui.
Ce chapitre introduit la problmatique des SGBD dductifs, puis prsente le langage
standard dexpression de rgles portant sur de grandes bases de donnes, appel
DATALOG. Celui-ci permet les requtes rcursives. Nous tudions les extensions de

518 BASES DE DONNES : OBJET ET RELATIONNEL

ce langage, telles que le support des fonctions, de la ngation, des ensembles. Ensuite,
nous abordons les problmes de lvaluation de questions sur des relations dduites.
Aprs une brve vue densemble, nous introduisons quelques techniques de reprsentation des rgles par les graphes, puis nous nous concentrons sur la rcursion. Les
mthodes gnrales QoSaQ et Magic sont prsentes. Quelques mthodes plus spcifiques sont rsumes. Avant un bilan en conclusion, nous abordons, travers des
exemples, les langages de rgles pour BD objet.

2. PROBLMATIQUE DES SGBD DDUCTIFS

Un SGBD dductif est tout dabord un SGBD. En ce sens, il doit possder un langage
de description de donnes permettant de dfinir les structures des prdicats de la base
B1, B2... Bn, par exemple sous forme de relations, et les contraintes dintgrit associes. Il offre aussi un langage de requte permettant de poser des questions et
deffectuer des mises jour. Ces deux langages peuvent tre intgrs et possder une
syntaxe propre, ou plusieurs, offertes aux usagers. Parmi ces langages, il est permis de
penser que SQL restera une des interfaces offertes par un SGBD dductif, surtout
devant la pousse de sa normalisation.

2.1. LANGAGE DE RGLES

Linterface nouvelle offerte par un SGBD dductif est avant tout le langage de rgles.
Notion XV.1 : Langage de rgles (Rule Language)
Langage utilis pour dfinir les relations dduites composant la base intentionnelle permettant
dcrire des programmes de rgles du style <condition> <action>.

Le langage de rgle est donc utilis afin de spcifier les parties conditions et actions
des rgles de dduction. Plus prcisment, partir des prdicats B1, B2... Bn dfinis
dans la base implante (extensionnelle), le langage de rgles permet de spcifier comment construire des prdicats drivs R1,R2... interrogeables par les utilisateurs. Un
langage de rgles peut donc tre peru comme une extension des langages de dfinition de vues et de triggers des SGBD relationnels classiques.
Lextension est de taille car le langage de dfinition et de manipulation de connaissances va intgrer les fonctionnalits suivantes :
1. la possibilit deffectuer les oprations classiques du calcul relationnel (union, restriction, projection, jointure, diffrence) ;

Bases de donnes dductives 519

2. le support des ensembles incluant les fonctions dagrgats traditionnelles des langages relationnels classiques ainsi que les attributs multivalus ;
3. la rcursivit, qui permet de dfinir une relation dduite en fonction delle-mme ;
4. la ngation, qui permet de rfrencer des faits non existants dans la base ;
5. les fonctions arithmtiques et plus gnralement celles dfinies par les utilisateurs ;
6. les mises jour des faits au travers des rgles ;
7. la modularit avec la gestion de niveaux dabstraction successifs et de mta-rgles.
En bref, toutes les facilits qui existent dans les langages de dveloppement de bases
de donnes vont chercher figurer dans les langages de rgles. Lobjectif vis est
dailleurs de remplacer ces langages.

2.2. COUPLAGE OU INTGRATION ?

La ralisation dun SGBD dductif ncessite donc lintgration dun moteur de rgles
au sein dun SGBD. Celui-ci doit tre capable de raliser linfrence ncessaire lors
de linterrogation, voire la mise jour, des prdicats drivs. Une fonctionnalit analogue celle dun SGBD dductif peut tre obtenue en couplant un moteur de rgles
un SGBD. On distingue le couplage faible o les deux composants restent visibles
lutilisateur du couplage fort o seul le langage de rgles est visible. La figure XV.1
illustre les techniques de couplage et dintgration. Un SGBD dductif essaie donc de
raliser lintgration forte, en offrant un langage de dfinition et de manipulation de
connaissances intgr.
Sql+lg. rgles

lg. rgles

MOTEUR RGLES

MOTEUR RGLES
SGBD

SGBD
Couplage fort

Couplage faible
lg. intgr

MOTEUR RGLES
SGBD
Intgration

Figure XV.1 : Couplage versus intgration

520 BASES DE DONNES : OBJET ET RELATIONNEL

La ralisation dun SGBD dductif intgr pose de nombreux problmes. Tout

dabord, il faut dfinir le langage dexpression de connaissances. Nous tudions cidessous lapproche DATALOG, inspire au dpart du langage de programmation
logique PROLOG, qui est devenue le standard de la recherche. Ensuite, il faut choisir
le modle interne de donnes pour stocker les faits, mais aussi pour stocker les rgles.
Plusieurs approches partent dun SGBD relationnel, soit tendu, soit modifi.
Dautres ont cherch raliser des SGBD dductifs partir de SGBD objet
[Abiteboul90, Nicolas97] intgrant les deux paradigmes. Ensuite, il faut garantir la
cohrence des donnes et des rgles : ce problme dintgrit tendue est trs important, car il est possible en thorie de dduire nimporte quoi dune base de connaissances (faits + rgles) incohrente. Enfin, il faut rpondre aux questions de manire
efficace, en ralisant linfrence partir des faits et des rgles, sans gnrer de faits
inutiles ni redondants, mais aussi sans oublier de rponses. Le problme de lefficacit
du mcanisme dinfrence en prsence dun volume important de faits et de rgles,
notamment rcursives, est sans doute lun des plus difficiles.

2.3. PRDICATS EXTENSIONNELS ET INTENTIONNELS

Dans le contexte logique, une base de donnes est perue comme un ensemble de prdicats. Les extensions des prdicats extensionnels sont matrialises dans la base de
donnes. Les prdicats extensionnels correspondent aux relations du modle relationnel.
Notion XV.2 : Prdicat extensionnel (Extensional predicate)
Prdicat dont les instances sont stockes dans la base de donnes sous forme de tuples.

Une base de donnes est manipule par des programmes logiques constitus dune
suite de clauses de Horn qui dfinissent des prdicats intentionnels. Un prdicat
intentionnel est donc dfini par un programme de rgles logiques ; il correspond une
vue du modle relationnel.
Notion XV.3 : Prdicat intentionnel (Intensional predicate)
Prdicat calcul par un programme constitu de rgles logiques dont les instances ne sont pas stockes dans la base de donnes.

Une base de donnes logique est constitue dun ensemble de prdicats extensionnels
constituant la base de donnes extensionnelle et dun ensemble de prdicats intentionnels constituant la base de donnes intentionnelle. Les rgles permettant de calculer
les instances des prdicats intentionnels sont donc partie intgrante de la base de donnes logique. Elles sont crites dans le langage DATALOG bas sur les clauses de

Bases de donnes dductives 521

Horn. La figure XV.2 illustre les notions de bases de donnes extensionnelle et intentionnelle, la seconde tant drive de la premire par des rgles stockes dans la mtabase du SGBD.
INFORMATIONS

QUESTIONS

MISES JOUR
BD intentionnelle
RGLES

Mta-donnes

BD extentionnelle
BD

Donnes

Figure XV.2 : Base de donnes extentionnelle et intentionnelle

2.4. ARCHITECTURE TYPE DUN SGBD

DDUCTIF INTGR
Le SGBD est dit dductif car il permet de dduire des informations partir de donnes stockes par utilisation dun mcanisme dinfrence logique. Les informations
sont les tuples des prdicats intentionnels ; elles peuvent tre dduites lors de linterrogation des prdicats intentionnels ou lors des mises jour des prdicats extensionnels. La mise jour des prdicats intentionnelles est difficile : il faut thoriquement
rpercuter sur les prdicats extensionnels, ce qui ncessite une extension des mcanismes de mise jour au travers de vues.
Notion XV.4 : SGBD dductif (Deductive DBMS)
SGBD permettant de driver les tuples de prdicats intentionnels par utilisation de rgles.

En rsum, un SGBD dductif va donc comporter un noyau de SGBD permettant de

stocker faits et rgles dans la base, et dexcuter des oprateurs de base comme un
SGBD classique. Au-del, il va intgrer des mcanismes dinfrence pour calculer

522 BASES DE DONNES : OBJET ET RELATIONNEL

efficacement les faits dduits. Un langage intgr de dfinition et manipulation de

connaissances permettra la dfinition des tables, des rgles, linterrogation et la mise
jour des informations (voir figure XV.3).
Interrogation

Mise jour

Dfinition de
connaissances

Infrence

Recherche et Mise jour

Tables

Rgles

Figure XV.3 : Illustration de larchitecture dun SGBD dductif

3. LE LANGAGE DATALOG
Le langage DATALOG est driv de la logique du premier ordre. Cest la fois un
langage de description et de manipulation de donnes. Le modle de description de
donnes support par DATALOG est essentiellement relationnel, une relation tant
vue comme un prdicat de la logique. Le langage de manipulation est un langage de
rgles bti partir des clauses de Horn. Le nom DATALOG signifie logique pour
les donnes . Il a t invent pour suggrer une version de PROLOG (le langage de
programmation logique) utilisable pour les donnes. Dans cette section, nous tudions
tout dabord la syntaxe de DATALOG, puis sa smantique.

3.1. SYNTAXE DE DATALOG

Outre la dfinition des prdicats extensionnels, DATALOG permet dcrire les clauses
de Horn spcifiant les prdicats intentionnels. Lalphabet utilis est directement driv
de celui de la logique du premier ordre. Il est compos des symboles suivants :

Bases de donnes dductives 523

1. des variables dnotes x, y, z ;

2. des constantes choisies parmi les instances des types de base entier, numrique et
chanes de caractres ;
3. des prdicats relationnels dnots par une chane de caractres, chaque prdicat
pouvant recevoir un nombre fixe darguments (n pour un prdicat n-aire) ;
4. les prdicats de comparaison =, <, >, , , ;
5. les connecteurs logiques et dnot par une virgule (,) et implique que lon
interprte de la droite vers la gauche, dnot par le signe dimplication invers ().
partir de cet alphabet (celui de la logique des prdicats du premier ordre particularis et rduit), on construit des formules particulires qui sont des clauses de Horn ou
rgles DATALOG. Un terme est ici soit une constante, soit une variable. Un atome
(aussi appel formule atomique ou littral positif) est une expression de la forme
P(t1,t2tn), o P est un prdicat n-aire. Un atome instanci est un atome sans
variable (les variables ont t remplaces par des constantes). partir de ces
concepts, une rgle est dfinie comme suit :
Notion XV.5 : Rgle DATALOG (DATALOG Rule)
Expression de la forme Q P1, P2 Pn avec n 0 et o Q est un atome construit partir dun
prdicat relationnel, alors que les Pi sont des atomes construits avec des prdicats relationnels ou
de comparaison.

Q est appel tte de rgle ou conclusion ; P1, P2 Pn est appel corps de rgle ou
prmisse ou encore condition. Chaque Pi est appel sous-but. En appliquant lquivalence Q P P Q, une rgle scrit aussi (P1, P2Pn) Q ; puis en
appliquant (P1, P2) P1 P2, on obtient P1 P2 Pn Q. Donc,
une rgle est une clause de Horn avec au plus un littral positif (la tte de rgle Q).
La figure XV.4 donne un exemple de programme DATALOG dfinissant une base de
donnes extensionnelle dcrivant les employs (prdicat extensionnel EMPLOYE) et
les services (prdicat extensionnel SERVICE) dune grande entreprise. La base de
donnes intentionnelle spcifie le chef immdiat de chaque employ (prdicat
DIRIGE1), puis le chef du chef immdiat (prdicat DIRIGE2).
{
/* Dclaration des prdicats extensionnels */
EMPLOYE(NomService : String, NomEmploye : String) ;
SERVICE(NomService : String, NomChef : String) ;
/* Dfinition des prdicats intensionnels */
DIRIGE1(x,y) SERVICE(z,x), EMPLOYE(z,y)
DIRIGE2(x,y) DIRIGE1(x,z), DIRIGE1(z,y)
}

Figure XV.4 : Exemple de programme DATALOG

524 BASES DE DONNES : OBJET ET RELATIONNEL

Un autre exemple de programme DATALOG est prsent figure XV.5. Il dfinit une
base de donnes extensionnelle compose de pays et de vols ariens reliant les capitales des pays. La base de donnes intentionnelle permet de calculer les capitales
proches (prdicat CPROCHE) comme tant les capitales atteignables lune depuis
lautre en moins de cinq heures dans les deux sens. Les pays proches (prdicat
PPROCHE) sont ceux ayant des capitales proches.
{
/* Dclaration des prdicats extensionnels */
PAYS(Nom : String, Capitale : String, Pop : Int) ;
VOLS(Num : Int, Depart : String, Arrivee : String, Duree : Int) ;
/* Dfinition des prdicats intensionnels */
CPROCHE(x,y) VOLS(z,x,y,t), t5, VOLS(w,y,x,u), u5 ;
PPROCHE(x,y) PAYS(x,u,p), PAYS(y,v,q), CPROCHE(u,v) ;
}

Figure XV.5 : Autre exemple de programme DATALOG

Parmi les rgles, il en existe une classe particulirement importante par la puissance
quelle apporte au langage : il sagit des rgles rcursives qui permettent de dfinir
un prdicat intentionnel en fonction de lui-mme.
Notion XV.6 : Rgle rcursive (Recursive rule)
Rgle dont le prdicat de tte apparat aussi dans le corps.

Une rgle rcursive dont le prdicat de tte apparat une seule fois dans le corps est
dite linaire. Une rgle non linaire est quadratique si le prdicat de tte apparat
deux fois dans le corps. Au-del, une rgle rcursive dont le prdicat de tte apparat n
(n 3) fois dans le corps devient difficilement comprhensible.
La figure XV.6 illustre quelques exemples de rgles rcursives.
{
/* Dirige tout niveau spcifi par une rgle rcursive linaire */
DIRIGE(x,y) DIRIGE1(x,y) ;
DIRIGE(x,y) DIRIGE1(x,z), DIRIGE(z,y) ;
/* Dirige tout niveau spcifi par une rgle rcursive quadratique */
DIRIGE(x,y) DIRIGE1(x,y) ;
DIRIGE(x,y) DIRIGE(x,z), DIRIGE(z,y) ;
/* Liaisons effectuables par tapes de moins de 5 heures */
LIAISON(x,y) VOLS(z,x,y,t), t 5 ;
LIAISON(x,y) LIAISON(x,z), LIAISON(z,y) ;
}

Figure XV.6 : Exemples de rgles rcursives

Bases de donnes dductives 525

Chaque relation rcursive ncessite une rgle dinitialisation non rcursive, puis une
rgle de calcul rcursive. Le premier couple de rgles dfinit qui dirige qui et ce,
tout niveau. Le deuxime dfinit la mme relation, mais en utilisant une rgle non
linaire. Le dernier couple spcifie les liaisons ariennes possibles entre capitales par
des suites de liaisons simples effectues en moins de cinq heures.
La figure XV.7 spcifie en DATALOG la clbre base de donnes des familles partir
des prdicats extensionnels PERE et MERE indiquant qui est pre ou mre de qui. La
relation rcursive ANCETRE a souvent t utilise pour tudier les problmes de la
rcursion. Nous avons ajout la dfinition des grand-parents comme tant les parents
des parents et celle des cousins comme tant deux personnes ayant un anctre commun. Les amis de la famille (AMIF) sont les amis (prdicat extensionnel AMI) ou les
amis de la famille des parents. Les cousins de mme gnration (prdicat MG) se
dduisent partir des frres ou surs. Notez que cette dfinition est large : elle donne
non seulement les cousins, mais aussi soi-mme avec soi-mme (vous tes votre
propre cousin de niveau 0 !), les frres et surs, puis vraiment les cousins de mme
gnration.
{
/* Prdicats extensionnels Pre, Mre et Ami */
PERE(Pre String, Enfant String)
MERE(Mre String, Enfant String)
AMI(Personne String, Personne String)
/* Parent comme union de pre et mre */
PARENT(x,y) PERE(x,y) ;
PARENT(x,y) MERE(x,y) ;
/* Grand-parent par auto-jointure de parents */
GRAND-PARENT(x,z) PARENT(x,y), PARENT(y,z) ;
/* Anctre dfini par une rgle linaire */
ANCETRE(x,y) PARENT(x,y) ;
ANCETRE(x,z) ANCETRE(x,y), PARENT(y,z) ;
/* Cousin partir danctres */
COUSIN(x,y) ANCETRE(z,x), ANCETRE(z,y) ;
/* Ami de la familles comme ami des anctres */
AMIF(x,y) AMI(x,y) ;
AMIF(x,y) PARENT(x,z), AMIF(z,y) ;
/* Cousins de mme gnration partir des parents */
MG(x,y) PARENT(z,x), PARENT(z,y) ;
MG(x,y) PARENT(z,x),MG(z,u),PARENT(u,y) ;
}

Figure XV.7 : La base de donnes des familles

526 BASES DE DONNES : OBJET ET RELATIONNEL

Plus gnralement, une relation rcursive est une relation dfinie en fonction dellemme. Une relation rcursive nest pas forcment dfinie par une rgle rcursive. En
effet, des rgles mutuellement rcursives permettent de dfinir une relation rcursive.
Plus prcisment, il est possible de reprsenter la manire dont les prdicats dpendent lun de lautre par un graphe de dpendance. Les sommets du graphe sont les
prdicats et un arc relie un prdicat P un prdicat Q sil existe une rgle de tte Q
dans laquelle P apparat comme un sous-but. Un prdicat intentionnel est rcursif sil
apparat dans un circuit. La figure XV.8 illustre un programme DATALOG avec
rcursion mutuelle. Le prdicat R est rcursif.
{
R(x,y) B(x,y) ;
R(x,y) P(x,z), B(z,y) ;
P(x,y) R(x,z), C(z,y) ;
}

Figure XV.8 : Rcursion mutuelle et graphe de dpendance

En rsum, un programme DATALOG est un ensemble de rgles. On note les rgles

constituant un programme entre crochets {}, chaque rgle tant spare de la suivante
par un point virgule. Lordre des rgles est sans importance. Les prdicats relationnels
sont classs en prdicats extensionnels dont les instances sont stockes dans la base
sur disques, et en prdicats intentionnels qui sont les relations dduites (ou drives).
DATALOG permet aux utilisateurs de dfinir la fois des rgles et des faits, un fait
tant simplement spcifi comme une rgle variable instancie sans corps (par
exemple, PERE (Pierre,Paul)). Bien que la base extensionnelle puisse tre dfinie en DATALOG comme une suite de prdicats, nous admettrons en gnral quelle
est cre comme une base relationnelle classique, par exemple en SQL. Ainsi, DATALOG sera plutt utilis pour spcifier des rgles, avec des corps et des ttes. Le
couple base de donnes extensionnelle-base de donnes intentionnelle crit en DATALOG constitue une base de donnes dductive dfinie en logique.

3.2. SMANTIQUE DE DATALOG

La smantique dun programme DATALOG (cest--dire ce que calcule ce programme) peut tre dfinie de plusieurs manires. Nous examinons ci-dessous les trois
techniques les plus courantes.

3.2.1. Thorie de la preuve

DATALOG drivant de la logique, il apparat naturel dutiliser une mthode de preuve
pour calculer les instances des prdicats intentionnels. On aboutit alors lapproche

Bases de donnes dductives 527

smantique de la preuve. Dans cette approche, un programme DATALOG calcule

tout ce qui peut tre prouv en utilisant la mthode de preuve par rsolution
[Lloyd87]. Un fait non prouvable est considr comme faux.
Notion XV.7 : Smantique de la preuve (Proof theoretic semantics)
Smantique selon laquelle un fait est vrai sil peut tre prouv en appliquant la mthode de rsolution partir des axiomes logiques drivs dun programme DATALOG.

Afin dillustrer la mthode, considrons la base de donnes dfinie figure XV.4,

contenant :
1. le prdicat extensionnel EMPLOYE avec deux tuples <informatique-Julie>
et <informatique-Pierre> indiquant que Pierre et Julie sont deux employs
du dpartement informatique ;
2. le prdicat extensionnel SERVICE avec un tuple <informatique-Pierre>
indiquant que Pierre est le chef du service informatique.
Pour savoir si le tuple <Pierre-Julie> appartient logiquement au prdicat intentionnel DIRIGE1, il suffit dappliquer la mthode de rsolution pour prouver le thorme
DIRIGE1 (Pierre,Julie) partir des axiomes drivs des relations de base
EMPLOYE (informatique,Julie), EMPLOYE (informatique,Pierre) et
de celui driv de la rgle DIRIGE1(x,y) SERVICE(z,x), EMPLOYE(z,y).
Ce dernier axiome se rcrit, en liminant limplication, DIRIGE1(x,y) SERVICE
(z,x) EMPLOYE (z,y). Larbre de preuve permettant de conclure que
<Pierre-Julie> est un fait vrai (cest--dire un tuple de DIRIGE1) est reprsent
figure XV.9.
SERVICE(z,x) EMPLOYE(z,y) DIRIGE1(x,y)
SERVICE(informatique,Pierre)

EMPLOYE(informatique,y) DIRIGE1(Pierrre,y)
EMPLOYE(informatique,Julie)

DIRIGE(Pierre, Julie)

Figure XV.9 : Exemple darbre de preuve

528 BASES DE DONNES : OBJET ET RELATIONNEL

En rsum, la mthode de rsolution permet de donner une smantique un programme DATALOG : un fait appartient un prdicat intentionnel sil peut tre prouv
comme un thorme par rsolution. En cas dchec de la mthode, le fait est suppos
faux : il nappartient pas au prdicat intentionnel. Cette interprtation de labsence de
preuve est appele ngation par chec. La mthode ainsi complte est appele
mthode de rsolution avec ngation par chec (ou encore mthode SLDNF). Il sagit
dune mthode qui permet de dterminer si un tuple appartient ou non un prdicat
intentionnel. Cest donc une mthode essentiellement procdurale qui fonctionne
tuple tuple. Elle est proche des mthodes de calcul appliques par les interprteurs
PROLOG.

3.2.2. Thorie du modle

Une seconde approche consiste voir les rgles comme dfinissant des modles possibles construits partir des instances des prdicats extensionnels. Rappelons quun
modle dun ensemble de formules logiques est une interprtation dans laquelle tous
les thormes sont vrais. Un modle dun programme DATALOG est donc une interprtation vrifiant les proprits suivantes :
1. Pour chaque tuple <a1,a2an> dun prdicat extensionnel B, B(a1,a2an) est vrai
dans linterprtation.
2. Pour chaque rgle Q(t1,t2tn) P1,P2,Pn et pour toute affectation de variable
dans linterprtation, si (P1 P2Pn) est vrai dans linterprtation, alors
(Q(t1,t2tn)) est aussi vrai.
En clair, un modle dun programme DATALOG est un ensemble dinstances de prdicats qui contiennent tous les faits de la base extensionnelle et tous les faits qui peuvent
tre infrs de ceux-ci en appliquant les rgles. partir dun modle, il est possible den
gnrer dautres par exemple par ajout de littraux ninfluant pas sur les conditions.
Une proprit intressante des programmes DATALOG est que lintersection de deux
modles reste un modle. En consquence, il existe un plus petit modle qui est
lintersection de tous les modles. Ce modle correspond la smantique dun programme DATALOG, appele plus petit modle. On peut alors dfinir lapproche
smantique du modle comme suit :
Notion XV.8 : Smantique du modle (Model theoretic semantics)
Smantique selon laquelle un fait est vrai sil appartient au plus petit modle des formules logiques
composant un programme DATALOG.

Afin dillustrer la mthode, le programme constitu des faits de base :

EMPLOYE (informatique,Pierre),
EMPLOYE (informatique,Julie),
SERVICE (informatique, Pierre)

Bases de donnes dductives 529

et de la rgle
DIRIGE1 (x,y) SERVICE (z,x), EMPLOYE (z,y)
a en particulier pour modles :
1. { EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie), SERVICE
(informatique,Pierre), DIRIGE1 (Pierre,Julie), DIRIGE1 (Pierre,Pierre) } ;
2. { EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie),
SERVICE (informatique,Pierre), DIRIGE1 (Pierre,Julie), DIRIGE1 (Pierre,Pierre),
DIRIGE1 (Julie,Julie)} ;
Le plus petit modle est :
{ EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie),
SERVICE
(informatique,Pierre),
DIRIGE1
(Pierre,Julie),
DIRIGE1 (Pierre,Pierre) }.
Il dfinit donc la smantique du programme DATALOG.

3.2.3. Thorie du point fixe

Une autre approche pour calculer la smantique dun programme DATALOG, donc
les prdicats intentionnels, consiste interprter le programme comme un ensemble
de rgles de production et excuter les rgles jusqu ne plus pouvoir gnrer aucun
fait nouveau. Cette procdure correspond lapplication rcursive de loprateur
consquence immdiate [VanEmden76] qui ajoute la base de faits successivement
chaque fait gnr par une rgle dont la condition est satisfaite.
Dans le contexte des bases de donnes, on prfre en gnral calculer des ensembles
de faits en appliquant les oprateurs de lalgbre relationnelle que sont la restriction,
la jointure, lunion et la diffrence. la place de la jointure et afin de simplifier
lalgorithme de traduction des rgles en expressions relationnelles, nous utiliserons le
produit cartsien suivi dune restriction. Afin de traduire simplement une rgle
DATALOG en expression de lalgbre relationnelle, on renommera tout dabord les
variables de mme nom en introduisant des prdicats additionnels dgalit entre
variables. Par exemple, la rgle R(x,y) B(x,z), C(z,y) sera rcrite R(x,y)
B(x,z1), C(z2,y), z1=z2. Une telle rgle est appele rgle rectifie.
Chaque condition dune rgle rectifie du type Q R1,R2, Rn, P1,P2, Pm (Ri
sont des prdicats relationnels et Pj des prdicats de contraintes sur les variables) peut
tre traduite en une expression dalgbre relationnelle P1,P2, Pm(R1xR2xRn), o
dsigne la restriction par le critre en indice et x lopration de produit cartsien.
Cette expression calcule un prdicat dont les colonnes correspondent toutes les
variables apparaissant dans la rgle rectifie. Une projection finale doit tre ajoute
afin de conserver les seules variables rfrences dans la tte de la rgle.

530 BASES DE DONNES : OBJET ET RELATIONNEL

Ainsi, soit Er lexpression de lalgbre relationnelle rsultant de la transformation

dune condition dune rgle r de la forme Q R1,R2, Rn, P1,P2, Pm. La rgle
est remplace par lquation de lalgbre relationnelle Q = Q Er. Chaque programme DATALOG P est ainsi remplac par un programme dalgbre relationnelle
not TP. La figure XV.10 prsente des exemples de transformation de programmes
DATALOG en programmes de lalgbre relationnelle.
EMPINF(x,y) EMPLOYE(x,y), x = informatique;
EMPINF = EMPINF A1=informatique(EMPLOYE)
DIRIGE1(x,y) SERVICE(z,x), EMPLOYE(z,y) ;
DIRIGE1 = DIRIGE1 A2,A4 (A1=A3(SERVICE x EMPLOYE))
DIRIGE2(x,y) DIRIGE1(x,z), DIRIGE1(z,y) ;
DIRIGE2 = DIRIGE2 A1,A4 (A2=A3(DIRIGE1 x DIRIGE1))
DIRIGE(x,y) DIRIGE1(x,y) ;
DIRIGE = DIRIGE DIRIGE1
DIRIGE(x,y) DIRIGE1(x,z), DIRIGE(z,y) ;
DIRIGE = DIRIGE A1,A4 (A2=A3(DIRIGE1 x DIRIGE))

Figure XV.10 : Exemple de transformation de rgles en algbre

partir du programme dalgbre Tp obtenu par traduction ligne ligne en algbre

relationnelle dun programme P, il est possible de dfinir la smantique du programme
DATALOG. Soit les faits initiaux contenus dans la base de donnes (les tuples de la
base extensionnelle). La smantique du programme peut tre dfinie par application
successive de TP , puis au rsultat TP(), puis au rsultat TP (TP()), etc., jusqu
obtenir un point fixe TPn(). On dit quon a obtenu un point fixe lorsquune nouvelle
application de TP ne change pas le rsultat. Lexistence dun point fixe est garantie car
TP est un oprateur monotone qui ne fait quajouter des faits aux prdicats intentionnels ; ceux-ci tant borns par le produit cartsien de leurs domaines, le processus
converge [Tarski55].
Notion XV.9 : Smantique du point fixe (Fixpoint semantics)
Smantique selon laquelle un fait est vrai sil appartient au point fixe dun oprateur qui peut tre
dfini comme tant le programme dalgbre relationnelle obtenu par traduction une une des
rgles du programme DATALOG.

Par exemple, avec le programme DATALOG :

P = {

PARENT(x,y) PERE(x,y);
PARENT(x,y) MERE(x,y) ;
ANCETRE(x,y) PARENT(x,y);
ANCETRE(x,y) PARENT(x,z), ANCETRE(z,y); }

Bases de donnes dductives 531

on calcule :
TP = {

PARENT = PARENT PERE;

PARENT = PARENT MERE;
ANCETRE = PARENT;
ANCETRE = ANCETRE 1,4 (PARENT

ANCETRE); }

Soit = { PERE (Jean,Pierre) ; MERE (Pierre,Julie) ; } les faits initiaux de la base de

donnes. On calcule :
TP() = {

PARENT (Jean,Pierre); PARENT (Pierre,Julie);

ANCETRE (Jean,Pierre); ANCETRE (Pierre,Julie);
ANCETRE (Jean, Julie)};

TP(TP()) = TP() qui est donc le point fixe.

3.2.4. Concidence des smantiques

En rsum, DATALOG permet de dfinir des prdicats drivs dont les instances sont
calculables par diverses smantiques. Heureusement, ces dernires concident pour les
programmes DATALOG purs, cest--dire sans les extensions que nous verrons dans
la suite. Cela provient du fait que toute rgle DATALOG ne fait quajouter des faits
un prdicat intentionnel. En gnral, la smantique dun programme DATALOG nest
pas calcule compltement, cest--dire que les prdicats drivs ne sont pas totalement calculs. Les seuls faits relevants sont calculs pour rpondre aux questions ou
pour rpercuter les mises jour. Une question peut tre exprime en SQL sur un prdicat dduit. Cependant, elle peut aussi tre exprime comme une rgle sans tte : la
qualification de la question est spcifie par le corps de la rgle. Afin de marquer les
rgles questions (sans tte), nous remplacerons limplication par un point dinterrogation. Ainsi, la recherche des anctres de Julie seffectuera par la rgle ? ANCETRE(x,
Julie). En pratique, une question est une rgle avec une tte implicite calculer en
rsultat, contenant les variables libres dans le corps de la rgle.
En conclusion, si lon compare DATALOG avec lalgbre relationnelle, il apparat
que DATALOG permet de dfinir des rgles et de poser des questions complexes
incluant les oprateurs de lalgbre relationnelle que sont lunion (plusieurs rgles de
mmes ttes), la projection (variables du corps de rgle omises en tte de rgles), la
restriction (prdicat non relationnel dans le corps dune rgle) et la jointure (plusieurs
prdicats relationnels dans le corps dune rgle avec variables communes). Aussi,
DATALOG permet la rcursion que ne permet pas lalgbre relationnelle. Cela se traduit par le fait quil faut effectuer une boucle sur loprateur TP jusquau point fixe
pour calculer la smantique dun programme DATALOG. Cette boucle est inutile si le
programme ne comporte pas de relation rcursive. DATALOG inclut la puissance de
la rcursion mais ne supporte pas la ngation, au moins jusque-l. Dans la suite, nous
allons tendre DATALOG avec la ngation. Auparavant, nous allons examiner comment reprsenter les informations ngatives.

532 BASES DE DONNES : OBJET ET RELATIONNEL

4. LES EXTENSIONS DE DATALOG

Nous tudions maintenant lextension de DATALOG avec la ngation, puis avec les
fonctions et les ensembles. Jusque-l, DATALOG avec rcursion ne permet que
dajouter des informations la base intentionnelle. Le type de raisonnement support
est monotone. Il devient non monotone avec la ngation. Fonctions et ensembles permettent dtendre DATALOG pour sapprocher des objets que nous intgrerons plus
loin.

4.1. HYPOTHSE DU MONDE FERM

Jusque-l, les seuls axiomes drivs dune base de donnes extensionnelle sont des faits
positifs (sans ngation). Afin de permettre de rpondre des questions ngatives (par
exemple, qui nest pas dirig par Pierre?), il apparat ncessaire de complter les
axiomes avec des axiomes ngatifs pour chaque fait qui napparat pas dans la base.
Cette drivation daxiomes ngatifs, qui consiste considrer que tout fait absent de la
base est faux, est connue sous le nom dhypothse du monde ferm. Nous lavons dj
introduite dans le chapitre V sur la logique. Nous la dfinissons plus prcisment ici.
Notion XV.10 : Hypothse du monde ferm (Closed World Assumption)
Hypothse consistant considrer que tout fait non enregistr dans la base extensionnelle et non
dductible par les rgles est faux.

Ainsi, si la relation PERE (Pre, Enfant) contient les faits PERE (Julie,Pierre) et
PERE (Jean,Paul), on en dduit :
PERE (Julie,Paul), PERE (Julie,Jean), PERE (Julie,Julie),
PERE (Pierre,Julie), PERE (Pierre,Jean), PERE (Pierre,Paul), etc.
Lhypothse du monde ferm est une rgle puissante pour infrer des faits ngatifs.
Elle suppose quun domaine peut prendre toutes les valeurs qui apparaissent dans la
base (domaine actif) et que tous les faits correspondant ces valeurs non connus sont
faux [Reiter78]. Pour tre valide, cette hypothse ncessite des axiomes additionnels
tels que lunicit des noms et la fermeture des domaines [Reiter84].
Par exemple, en prsence de valeurs nulles dans les bases de donnes, lhypothse du
monde ferm est trop forte car elle conduit affirmer comme faux des faits inconnus.
Les thoriciens se sont penchs sur des hypothses plus fines, tolrant les valeurs
nulles [Reiter84]. Une variante de lhypothse du monde ferme consiste modifier la
mthode de rsolution permettant de rpondre une question en supposant faux tout
fait qui ne peut tre prouv comme vrai. Cette approche est connue comme la ngation par chec.

Bases de donnes dductives 533

4.2. NGATION EN CORPS DE RGLES

Il existe plusieurs raisons pour ajouter la ngation DATALOG ; en particulier, la
ngation est souhaitable pour pouvoir rfrencer linexistence dun fait dans un prdicat. Elle permet de reprsenter la diffrence relationnelle ; elle est aussi utile pour
exprimer des exceptions. Par exemple, lors dun parcours de graphe, si lon dsire viter le parcours des arcs enregistrs dans une relation INTERDIT (Origine, Extrmit),
il est possible de complter le programme de parcours comme suit :
{ CHEMIN(x,y) ARC(x,y), INTERDIT(x,y) ;
CHEMIN(x,y) CN(x,z), ARC(z,y), INTERDIT(z,y) }
Plus gnralement, lintroduction de la ngation permet dcrire des rgles de la forme :
Q L1, L2 Ln
o Q est un littral positif et L1, L2 Ln sont des littraux positifs ou ngatifs.
Rappelons quun littral ngatif est une ngation dune formule atomique de la forme
P(t1,t2tn), o P est un prdicat et t1, t2, tn sont des termes. Le langage DATALOG ainsi tendu avec des prdicats ngatifs dans le corps de rgle est appel
DATALOGneg, encore not DATALOG.
Notion XV.11 : DATALOG avec ngation (DATALOGneg)
Version tendue de DATALOG permettant dutiliser des littraux ngatifs dans le corps des rgles.

La smantique dun programme DATALOGneg nest pas facile dfinir. En effet,

lintersection de modles dun tel programme nest en gnral pas un modle. Par
exemple, le programme :
{ OISEAU (Pgase) ;
PINGOIN(x) OISEAU(x), VOLE(x) ;
VOLE(x) OISEAU(x), PINGOIN(x)
}
a pour modles :
{ OISEAU(Pgase); PINGOIN(Pgase) } et
{ OISEAU(Pgase); VOLE(Pgase) }
dont lintersection { OISEAU(pgase) } nest pas un modle. Un tel programme na
donc pas de plus petit modle. En fait, en utilisant les quivalences logiques, la
deuxime et la troisime rgles peuvent tre rcrites :
VOLE(x) PINGOIN(x) OISEAU(x).
Nous avons l une rgle disjonctive qui introduit des informations ambigus. Do
lexistence de plusieurs modles possibles.
Sous certaines conditions syntaxiques, le problme du choix dun modle peut tre
rsolu en divisant le programme en strates successives, chacune ayant un plus petit

534 BASES DE DONNES : OBJET ET RELATIONNEL

modle [Apt86, Pryzymusinski88]. Un module dun programme DATALOG tant un

ensemble de rgles, un programme stratifi peut tre dfini comme suit :
Notion XV.12 : Programme DATALOG stratifi (Stratified Datalog Program)
Programme DATALOG divis en un ensemble ordonn de modules {S1, S2Sn} appels strates, de
telle manire que la strate Si nutilise que des ngations de prdicats compltement calculs par les
strates S1, S2, Si-1 (ou ventuellement aucune ngation de prdicats).

En fait, le plus petit modle dune strate est calcul partir du plus petit modle de la
strate prcdente, la ngation tant remplace par un test de non-appartenance. Si M
est le plus petit modle de la strate Si-1, P(x) est interprt comme P(x) nappartient pas M dans la strate Si.
Tout programme DATALOG nest pas stratifiable ; il doit tre possible de calculer
compltement toute lextension dun prdicat avant dutiliser sa ngation pour pouvoir stratifier un programme. Cela nest pas vrai si la rcursion traverse la ngation.
Les programmes stratifiables ont un plus petit modle unique qui est caractris en
dfinissant un ordre partiel entre les prdicats. Lordre correspond un calcul de plus
petit modle strate par strate en utilisant lhypothse du monde ferm.
Par exemple, les programmes :
{P(x) P(x)} et
{ PAIRE(0); IMPAIRE(x) PAIRE(x) ; PAIRE(x) IMPAIRE(x) }
ne sont pas stratifiables car la ngation se rencontre sur un cycle de rcursion (cest-dire traverse la rcursion). Le programme
{ R(1) ; P(1) ; P(2) ; Q(x) R(x); T(x) P(x),Q(x)}
est stratifiable; deux strates possibles sont :
S1 = {R(1) ; Q(x) R(x)} puis
S2 = { P(1) ; P(2) ; T(x) P(x), Q(x)};
S1 calcule Q sans utiliser Q, puis S2 calcule T en utilisant Q et P. Le plus petit
modle de S1 est {R(1); Q(1)}. Celui de S2 est {R(1); Q(1); T(2)}. Notez que lordre
de calcul des prdicats est fondamental : si on commenait calculer T avant Q, on
obtiendrait T(1) et un rsultat qui ne serait pas un modle.
La ngation en corps de rgle est importante car elle permet de raliser la diffrence relationnelle. La stratification correspond la smantique couramment admise en relationnelle : avant dappliquer une diffrence une relation, il faut calculer compltement cette
relation (autrement dit, le pipe-line est impossible avec loprateur de diffrence).

4.3. NGATION EN TTE DE RGLES ET MISES JOUR

Comme PROLOG, DATALOG est construit partir des clauses de Horn. Aussi, les
rgles sont en principe limites des clauses de Horn pures, disjonctions dun seul

Bases de donnes dductives 535

prdicat positif avec plusieurs prdicats ngatifs (0 n). Il ny a pas de difficults

tendre les ttes de rgles plusieurs prdicats positifs relis par conjonction (et) ; une
rgle plusieurs ttes est alors interprte comme plusieurs rgles une seule tte
avec le mme corps. Une autre possibilit est de tolrer un prdicat ngatif en tte de
rgle. Une information ngative tant en gnral une information non enregistre dans
la base, une interprtation possible pour un tel prdicat est une suppression des faits
correspondant aux variables instancies satisfaisant la condition de la rgle. Le langage DATALOG avec ngation possible en corps et en tte de rgle est appel
DATALOGneg,neg, encore not DATALOG.
Notion XV.13 : DATALOG avec double ngation (DATALOGneg,neg)
Version tendue de DATALOG permettant dutiliser des littraux ngatifs en tte et en corps de
rgle.

La ngation en tte de rgle est donc interprte comme une suppression. Cest elle
qui confre rellement la non monotonie des programmes DATALOG. Au-del, il
est possible de placer plusieurs prdicats en tte dune rgle DATALOG. Supporter
la fois les rgles ttes multiples et des prdicats ngatifs en tte de rgle conduit
permettre les mises jour dans le langage de rgles. On parle alors du langage DATALOG avec mise jour, not DATALOG*.
Par exemple, la rgle suivante, dfinie sur la base de donnes intentionnelle
{ PARENT(Ascendant, Descendant), ANCETRE(Ascendant, Descendant) } est une
rgle DATALOG* :
ANCETRE(x,z), ANCETRE(z,x) PARENT(x,y), ANCETRE(y,z)
Cette rgle gnre de nouveaux anctres et supprime des cycles qui pourraient apparatre dans la relation anctre (si x est le parent de y et y lanctre de z, alors x est
lanctre de z mais z nest pas lanctre de x).
Une interprtation de DATALOG* est possible partir des rgles de production, trs
populaires dans les systmes experts. Une rgle de production est une expression de
la forme :
<condition> <expression dactions>.
Une expression dactions est une squence dactions dont chacune peut tre soit une
mise jour, soit un effet de bord (par exemple, lappel une fonction externe ou ldition dun message). Une condition est une formule bien forme de logique. Quand
lordre dvaluation des rgles est important, celles-ci sont values selon des priorits dfinies par des mta-rgles (des rgles sur les rgles) ; par exemple, une mtargle peut simplement consister excuter les rgles dans lordre squentiel. Ainsi, un
langage de rgles de production nest pas compltement dclaratif mais peut contenir
une certaine procduralit. Il en va de mme pour les programmes DATALOG avec
mises jour.

536 BASES DE DONNES : OBJET ET RELATIONNEL

Un programme DATALOG* peut tre compris comme un systme de production

[Kiernan90]. Chaque rgle est excute jusqu saturation pour chaque instanciation
possible des variables par des tuples satisfaisant la condition. Un prdicat positif en
tte de rgle correspond une insertion dun fait et un prdicat ngatif une suppression. Une rgle peut la fois crer des tuples et en supprimer dans une mme relation.
Plus prcisment, soit une expression dactions de la forme R(p1), R(p2), R(n1),
R(n2) avec des actions conflictuelles sur une mme relation R. Notons P = {p1,
p2} lensemble des tuples insrs dans R et N = {n1, n2} lensemble des tuples
supprims. Certains tuples pouvant tre la fois insrs et supprims, il faut calculer
leffet net des insertions et suppressions. De sorte viter les smantiques dpendant
de lordre dcriture des actions, lopration effectue peut tre dfinie par : R = R
(N P) (P N). Ainsi, une telle expression dactions effectue une mise jour de la
relation R ; lordre des actions dans lexpression est sans importance.
Lexistence dun point fixe pour un programme DATALOG* nest pas un problme trivial. Certaines rgles peuvent supprimer des tuples que dautres rgles crent. Un programme de rgles avec mises jour peut donc boucler ou avoir diffrents tats stables
selon lordre dapplication des rgles, donc avoir une smantique ambigu. Un programme est confluent sil conduit toujours au mme rsultat (point fixe), quel que soit
lordre dapplication des rgles. Afin dviter les programmes smantique ambigu, il
est possible dutiliser une mta-rgle implicite analogue la stratification : une rgle
avec suppression sur une relation R ne peut tre excute que quand toutes les rgles
insrant dans R ont t excutes jusqu saturation. Une telle rgle est trs restrictive et
impose par exemple de rejeter les rgles la fois insrant et supprimant (mises jour).
Par exemple, pour dmontrer la puissance de DATALOG ainsi tendu, nous proposons des rgles de transformation de circuits lectriques. Cet exemple suppose une
base de donnes relationnelle compose dune unique relation CIRCUIT(Nom,
Fil, Origine, Extrmit, Impdance). Nom est le nom du circuit. Fil
est un identifiant donn chaque fil. Les origines et extrmits de chaque fil sont donnes par les attributs correspondants, alors que le dernier attribut donne limpdance
du circuit. Un problme typique est de calculer limpdance du circuit. Pour cela, il
faut appliquer les transformations srie et parallle, classiques en lectricit. Chaque
rgle remplace deux fils par un fil quil faut identifier. Il faut donc pouvoir crer de
nouveaux identifiants de fils, ce que nous ferons par une fonction de cration dobjets
partir de deux objets existants f1 et f2, dnote new (f1,f2). En consquence, la rgle
suivante effectue la transformation parallle (1/i = 1/i1 + 1/i2) :
CIRCUIT(x,f1,o,e,i1), CIRCUIT(x,f2,o,e,i2),
CIRCUIT(x,new(f1,f2),o,e,(i1*i2)/(i1+i2))
CIRCUIT(x,f1,o,e,i1), CIRCUIT(x,f2,o,e,i2)
La transformation srie est similaire, mais il faut sassurer de la non existence dun fil
partant de la jonction des deux fils en srie, ce qui ncessite une ngation en corps de
rgle. Do la rgle suivante qui cumule les impdances de deux fils en srie :

Bases de donnes dductives 537

CIRCUIT(x,f1,o,e1,i1), CIRCUIT(x,f2,e1,e,i2),
CIRCUIT(x,new(f1,f2),o,e,i1+i2)
CIRCUIT(x,f1,o,e1,i1),CIRCUIT(x,f2,e1,e,i2), CIRCUIT(x,f3,e1,e2,i3)
Ces deux rgles rduisent les circuits par remplacement des fils en parallle et en srie
appartenant un mme circuit par un fil rsultat de la transformation effectue. Notez
quelles ne sont pas stratifiables. Cependant, le programme de rgles est confluent, au
moins pour des circuits lectriques connexes.
Dautres smantiques que la smantique oprationnelle des rgles de production introduite ci-dessus ont t proposes pour Datalog* [Abiteboul95], comme la smantique
inflationiste et la smantique bien fonde. La smantique inflationiste est simple :
elle calcule les conditions, puis tous les faits dduits de toutes les rgles la fois. Elle
applique donc un oprateur de point fixe global modifi. Malheureusement, le rsultat
ne correspond gure la signification courante. La smantique bien fonde est plus
gnrale : elle est base sur une rvision de lhypothse du monde ferme, en autorisant des rponses inconnues des questions. Pour Datalogneg, elle concide avec la
smantique stratifie lorsque les programmes sont stratifiables. Les problmes de
smantique de Datalog* sont en rsum trs difficiles et ont donn lieu de nombreux
travaux thoriques de faible intrt.

4.4. SUPPORT DES FONCTIONS DE CALCUL

Pour accrotre la puissance de DATALOG, il est souhaitable dintgrer les fonctions
de la logique du premier ordre au langage. Des symboles de fonctions pourront alors
tre utiliss dans les arguments des prdicats, en tte ou en corps de rgle. Des
exemples de fonctions sont les fonctions arithmtiques (+,-,/,*) ou plus gnralement
des fonctions mathmatiques (LOG, EXP, SIN), voire des fonctions programmes
par un utilisateur. Les fonctions sont importantes car elles permettent en gnral la
manipulation dobjets complexes [Zaniolo85], par exemple, des figures gomtriques.
En gnral, les fonctions permettent dinvoquer des types abstraits de donnes
[Stonebraker86].
Dun point de vue syntaxique, lextension consiste introduire dans lalphabet des
symboles de fonctions, nots f, g, h Chaque fonction a une arit n, qui signifie que
la fonction accepte n paramtres. De nouveaux termes peuvent tre construis de la
forme f(t1, t2, tn) o chaque ti est lui-mme un terme (qui peut tre construit en
utilisant un symbole de fonction). Les termes fonctionnels peuvent tre utiliss
lintrieur dun prdicat comme un argument. Le langage rsultant est appel
DATALOGfonc.

538 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XV.14 : DATALOG avec fonction (DATALOGfun)

Version tendue de DATALOG dans laquelle un terme argument de prdicat peut tre le rsultat de
lapplication dune fonction un terme.

Ainsi, des prdicats tels que P(a,x,f(x),f(g(x,a))) o f est une fonction unaire et g une
fonction binaire sont accepts. La smantique de DATALOG doit alors tre complte
pour intgrer les fonctions. Cela seffectue comme en logique, en faisant correspondre
chaque fonction n-aire une application de Dn dans D, D tant le domaine dinterprtation.
Les fonctions sont trs utiles en pratique pour effectuer des calculs. Par exemple, un
problme de cheminement avec calcul de distance sur un graphe pourra tre exprim
comme suit :
{ CHEMIN(x,y,d) ARC(x,y,d) ;
CHEMIN(x,y,d+e) CHEMIN(x,z,e), ARC(z,y,d)
}
La recherche des longueurs de tous les chemins allant de Paris Marseille seffectuera
par la requte ? CHEMIN(Paris,Marseille,x).
Un problme qui devient important avec DATALOGfonc est celui de la finitude des
rponses aux questions (ou des relations dduites). Une question est saine (en anglais
safe) si elle a une rponse finie indpendamment des domaines de la base (qui peuvent tre finis ou infinis). Le problme de dterminer si une question est saine existe
dj en DATALOG pur. Si les domaines sont infinis, un programme DATALOG peut
gnrer des rponses infinies. Par exemple, le programme:
{ SALAIRE(100) ;
SUPERIEUR(x,y) SALAIRE(x), x < y ;
? SUPERIEUR(x,y)
}
gnre une rponse infinie. Pour viter des programmes a modle infini, une caractrisation syntaxique des programmes sain a t propose [Zaniolo86]. Cette caractrisation est base sur la notion de rgle champ restreint. Une rgle est champ restreint si toutes les variables figurant en tte de rgle apparaissent dans un prdicat
relationnel dans le corps de la rgle. Par exemple, la rgle
SUPERIEUR(x,y) SALAIRE(x), x < y nest pas champ restreint car y
napparat pas dans un prdicat relationnel dans le corps de la rgle. Si toutes les
rgles dun programme DATALOG sans fonction sont champ restreint, alors le programme est sain et ne peut gnrer des rponses infinies.
Avec des fonctions, le problme de savoir si un programme est sain est plus difficile.
Par exemple, le programme :
{ ENTIER(0);
ENTIER(x+1) ENTIER(x) }

Bases de donnes dductives 539

nest pas sain car il gnre un prdicat infini (les entiers positifs sont gnrs dans
ENTIER). Cependant, ce programme est champ restreint. Notez cependant que la
question ? ENTIER(10) a une rponse finie unique (vrai). Vous trouverez une
mthode gnrale pour dterminer si un programme avec fonctions est sain dans
[Zaniolo86].
En conclusion, il est intressant de remarquer quil est possible dtendre lalgbre
relationnelle avec des fonctions [Zaniolo85], comme vu dans le chapitre XI sur le
modle objet. En fait, il est ncessaire dinclure des fonctions dans les qualifications
de jointures et restrictions (les qualifications sont alors des expressions de logique du
premier ordre avec fonctions). Il est aussi ncessaire dinclure des fonctions dans les
critres de projection. On projette alors sur des termes fonctionnels calculs partir
dattributs. Le plus petit modle dun programme DATALOGfonc peut alors tre calcul par un programme utilisant des boucles dexpressions dalgbre relationnelle
sans diffrence. Ainsi, DATALOGfonc a la puissance de lalgbre relationnelle avec
fonction sans diffrence, mais avec la rcursion. Pour avoir la diffrence, il faut passer
DATALOGfonc,neg et pour avoir les mises jour DATALOGfonc,*.

4.5. SUPPORT DES ENSEMBLES

Une caractristique intressante des langages de manipulation de bases de donnes
relationnelles comme SQL est la possibilit de manipuler des ensembles travers des
fonctions agrgats. Plusieurs auteurs ont propos dintroduire les ensembles dans les
langages de rgles [Zaniolo85, Beeri86, Kupper86]. Le but est de supporter des attributs multivalus contenant des ensembles de valeurs. DATALOG tendu avec des
ensembles est appel DATALOGens.
Notion XV.15 : DATALOG avec ensemble (DATALOGset)
Version tendue de DATALOG permettant de manipuler des ensembles de valeurs rfrencs par
des variables ensembles.

Afin dillustrer lintrt des ensembles, considrons la relation de schma

PIECE(COMPOSE, COMPOSANT) dont un tuple <a,b> exprime le fait que a est
compos avec le composant b. Pour une pice donne a, il existe autant de tuples que
de composants de a dans cette relation. Trouver toutes les sous-pices de chaque pice
et les rpertorier dans une relation COMPOSE(PIECE, ENSEMBLE_DE_SOUSPIECE) est une opration intressante, possible ds que lon tolre des attributs multivalus. Une telle opration est appele groupage (en anglais, nest). Lopration
inverse est le dgroupage (en anglais, unest). Ces deux oprations dj tudies dans
le chapitre XI sur le modle objet sont illustres figure XV.11.

540 BASES DE DONNES : OBJET ET RELATIONNEL

PICE

composant

compos

qt

locomotive
locomotive
roue
roue
moteur

roue
moteur
rayon
jante
bielle

4
1
20
1
1

NEST

PICE

UNEST

composant

{compos,qt}

locomotive
roue
moteur

{<roue, 4> <moteur,1>}

{<rayon,20><jante,1>}
{<bielle , 1> }

Figure XV.11 : Oprations de groupage et dgroupage

Il existe plusieurs manires dintroduire les ensembles dans un langage de rgles. Il

est possible dintroduire de nouveaux domaines dans la base de donnes intentionnelle dont les valeurs sont des ensembles de constantes. Cependant, il est sage dinterdire les ensembles densembles, donc de se limiter un niveau densemble ; dans le
cas contraire, il serait possible de gnrer des ensembles densembles des profondeurs infinies. Pour viter de confondre les variables qui rfrencent des ensembles
avec celles qui rfrencent des valeurs simples, nous utiliserons des majuscules pour
les variables simples et des minuscules pour les variables simples, comme [Kuper86].
Pour accomplir lopration de groupage, un oprateur spcial appel groupage peut tre
introduit comme dans [Beeri86]. Le groupage range dans un ensemble toutes les valeurs
des variables en arguments qui satisfont la condition du corps de rgle. Appliqu une
variable x, le groupage est not <x>. Ainsi, la relation COMPOSE rsultat du groupage
de la relation PIECE illustre figure XV.11 peut tre dclare comme suit :
COMPOSE (x,Y) PIECE(x,y), Y = <y>.
Etant donn des ensembles et des lments, un prdicat dappartenance, not , peut
tre introduit. En utilisant ce prdicat, le dgroupage illustr figure XV.11 est excut
par la rgle :
PIECE(x,y) COMPOSE(x,Y), y Y.
Afin de comparer des ensembles, dautres prdicats classiques peuvent tre introduits,
comme linclusion stricte note . Des fonctions sur ensembles sont aussi possibles,
telles que les fonctions agrgats classiques COUNT, MIN, MAX, AVG qui dlivrent
des valeurs simples, ou des fonctions binaires entre ensembles qui dlivrent des
ensembles (, , ).

Bases de donnes dductives 541

Remarquons que le groupage ne donne pas plus de puissance au langage que les fonctions interprtes et la ngation. En fait, si lon dfinit la fonction unaire interprte
qui un lment fait correspondre un ensemble compos de cet lment {}: x {x}
et la fonction binaire interprte sur ensemble : X,Y X Y (cest--dire lunion
classique), il est possible deffectuer le groupage par les rgles suivantes :
SOUS-PIECE (x,Y) PIECE (x,y), Y = {y}
SOUS-PIECE (x,Y) SOUS-PIECE (x,Z), SOUS-PIECE (x,T), Y = Z T
COMPOSE (x,Y) SOUS-PIECE (x,Y), SOUS-PIECE (x,Z), Z Y
En clair, la deuxime rgle fait lunion de tous les lments composant chaque pice x
et la dernire garde le plus grand ensemble de sous-pices Y ainsi gnr. Il va de soi
quutiliser loprateur de groupage est plus simple ; aussi, si le systme ralise efficacement cet oprateur, il sera probablement plus performant pour effectuer le groupage
quen excutant les trois rgles ci-dessus.
Pour conclure sur les ensembles, notons que lintroduction densembles en DATALOG ncessite la stratification pour dfinir la smantique dun programme sans ambigut. Cela provient du fait que les ensembles intgrent un cas particulier de ngation.
La smantique de la stratification ncessaire peut tre exprime comme suit : calculer tout ensemble avant dutiliser son contenu . Ainsi, les rgles doivent tre partiellement ordonnes en strates dans lesquelles les oprations de groupage sont effectues
ds que possible. Si des groupages sont effectus dans des cycles de calculs de prdicats rcursifs, le programme nest pas stratifiable et a une smantique ambigu : il
doit tre rejet.

5. VALUATION DE REQUTES DATALOG

Cette section prsente les techniques de base pour valuer des questions sur des prdicats drivs dfinis en Datalog.

5.1. VALUATION BOTTOM-UP

La solution la plus simple pour rpondre une question portant sur un prdicat dduit
par un programme DATALOG est de calculer ce prdicat, puis de le filtrer avec la
question. Le calcul du prdicat peut se faire par calcul de point fixe comme vu formellement ci-dessus, lors de ltude de la smantique du point fixe. Ce calcul commence
partir des prdicats de base contenant les faits et gnre des faits dans les prdicats
drivs par application successive des rgles. Pour appliquer une rgle, les variables

542 BASES DE DONNES : OBJET ET RELATIONNEL

sont instancies avec des faits connus. Cela ncessite dvaluer la condition composant le corps de rgle sur les faits connus ; pour chaque instance des variables satisfaisant la condition, laction (ou les actions) dfinie par le prdicat de tte est excute.
La procdure de gnration est applique jusqu saturation, cest--dire jusquau
point o aucune rgle ne peut produire de nouveau fait. Une telle procdure est
connue en intelligence artificielle comme la gnration en chanage avant
[Nilsson80]. Elle est rsume figure XV.12.
{ Tant que Il existe une relation drive R non sature faire{
slectionner une rgle r, dont laction sapplique sur R ;
pour chaque tuple de la base satisfaisant la condition de r faire
excuter les actions de r ;
}
} ;

Figure XV.12 : Gnration en chanage avant

Lapproche propose part des donnes pour laborer la rponse lusager. Pour cette
raison, elle est souvent appele mthode dvaluation bottom-up.
Notion XV.16 : Evaluation Bottom-up (Bottom-up evaluation)
Technique dvaluation partant des tuples de la base de donnes, consistant appliquer les rgles
en avant jusqu saturation pour gnrer la rponse la question finalement obtenue par filtrage
des donnes gnres.

Une illustration de la gnration bottom-up apparat figure XV.13.

Une technique dvaluation bottom-up calcule le plus petit modle dun programme
logique ; donc, elle gnre la base intentionnelle. La question est applique la base
intentionnelle. Lordre et la manire selon lesquels les rgles sont appliques sont
importants pour au moins deux raisons :
1. Ils peuvent changer les performances du processus de gnration. Puisque les rgles
peuvent interagir de diffrentes manires (le rsultat dune rgle peut changer la
valeur de la condition dune autre), il est souhaitable de choisir un ordre. Dans le
cas de DATALOG pur, le problme du choix de lordre des rgles est une extension
de loptimisation de question des SGBD relationnels.
2. Dans le cas de rgles avec ngations ou ensembles et de programmes stratifis, il
est ncessaire de gnrer chaque strate dans lordre de stratification pour obtenir un
modle correct. Plus complexe, avec des langages de rgles de production (rgles
avec mises jour), le rsultat peut dpendre de lordre dapplication des rgles.

Bases de donnes dductives 543

PROGRAMME DATALOG AVEC QUESTION

(r1) PARENT(x,z) MERE(x,z)
(r2) PARENT(x,z) PERE(x,z)
(r3) GRANPARENT(x,z) PARENT(x,y), PARENT(y,z)
(q) ? GRANDPARENT(x, Jean)
BASE EXTENSIONNELLE
MRE

ASC

DESC

Marie
Julie
Julie

Jean
Marie
Jack

APPLICATION DE r1
PARENT

ASC

DESC

Marie
Julie
Julie

Jean
Marie
Jack

APPLICATION DE r3

PRE

ASC

DESC

Pierre
Ted
Ted
Jef

Chris
Marie
Jack
Pierre

APPLICATION DE r2
PARENT

ASC

DESC

Marie
Julie
Julie
Pierre
Ted
Ted
Jef

Jean
Marie
Jack
Chris
Marie
Jack
Pierre

APPLICATION DE q

GRANDPARENT ASC

DESC

GRANDPARENT ASC

DESC

Julie
Ted
Jef

Jean
Jean
Chris

Julie
Ted

Jean
Jean

Figure XV.13 : Exemple de gnration bottom-up

5.2. VALUATION TOP-DOWN

Au lieu de partir de la base extensionnelle pour gnrer les rponses aux questions, il
est possible de partir de la question. Le principe est dutiliser le profil de la question
(nom de prdicat et valeurs connues) et de le remonter via les rgles en chanage
arrire jusqu la base extensionnelle pour dterminer les faits capables de gnrer
des rponses. Un tel procd est connu sous le nom chanage arrire en intelligence
artificielle [Nilsson80]. Si des faits de la base sont retrouvs en utilisant le chanage
arrire, alors la question est satisfaite ; donc, une rponse oui/non est facile laborer

544 BASES DE DONNES : OBJET ET RELATIONNEL

en chanage arrire. Plus gnralement, la remonte des constantes de la question vers

les tuples de la base permet de gnrer des faits relevants, seuls capables de produire
des rponses aux questions [Lozinskii86].
Notion XV.17 : Faits relevants (Relevant facts)
Tuples de la base extensionnelle qui participent la gnration dau moins un tuple de la rponse
la question.

Les faits relevants peuvent tre utiliss afin de gnrer toutes les rponses la question si ncessaire, en appliquant une procdure de chanage avant partir de ces faits.
Cependant, la technique est trs diffrente de lvaluation bottom-up puisquelle profite des constantes de la question pour rduire les espaces de recherche. La mthode
part de la question de lusager pour remonter aux faits de la base. En consquence,
elle est appele mthode top-down.
Notion XV.18 : valuation top-down (Top-Down Evaluation)
Technique dvaluation partant de la question et appliquant les rgles en arrire pour driver la
rponse la question partir des faits relevants.

Une valuation top-down de la question PARENT(x,Jean) est reprsente

figure XV.14. La question GRANDPARENT(x,Jean) de la figure XV.13 est plus
difficile valuer. En premire approche, tous les faits seront considrs comme relevants du fait de la rgle (r3) (aucune variable ne peut tre instancie en chanage
arrire dans la premire occurrence du prdicat PARENT). Le problme de dterminer
prcisment les faits relevants est difficile et nous ltudierons plus gnralement pour
les rgles rcursives dans la section suivante.
La mthode dvaluation top-down est formellement base sur la mthode de rsolution. Soit ? R(a,y) une question portant sur un prdicat driv R. Toute rgle du type
suivant :
R(..) B1,B2...Q1,Q2...
dont la conclusion peut tre unifie par une substitution avec la question permet de
calculer une rsolvante de la question. Pour chaque rgle de ce type, une sous-question {B1,B2...Q1,Q2...}[] est gnre. Le processus doit tre rpt pour les sousquestions Q1[], Q2[]... Dans le cas o aucune relation nest rcursive, on finit toujours par aboutir des sous-questions portant sur les prdicats de base B1,B2... qui
peuvent tre values par le SGBD ; la collecte des rsultats permet dlaborer les
rponses la question initiale.
En rsum, la drivation top-down transmet les constantes depuis la question vers la
base afin de filtrer les faits relevants. Malheureusement, la remonte des constantes
qui rduit grandement les espaces de recherche nest en gnral pas simple. Elle

Bases de donnes dductives 545

demande de comprendre les connexions entre les rgles dans un programme de rgles,
cest--dire les unifications possibles entre prdicats. Dans ce but, plusieurs reprsentations par des graphes dun programme DATALOG ont t proposes.
PROGRAMME DATALOG AVEC QUESTION
(r1) PARENT(x,z) MERE(x,z)
(r2) PARENT(x,z) PERE(x,z)
(q) ? PARENT(x,Jean)

BASE EXTENSIONNELLE
MRE

ASC

DESC

Marie
Julie
Julie

Jean
Marie
Jack

PRE

ASC

DESC

Pierre
Ted
Ted
Jef

Chris
Marie
Jack
Pierre

FAIT RELEVANT DDUIT DE LA QUESTION

PARENT(?,Jean)
FAIT RELEVANT PAR LA RGLE r2
PERE(?,Jean) qui donne un rsultat vide
FAIT RELEVANT PAR LA RGLE r1
MERE(?,Jean) qui donne

MRE

ASC

DESC

Marie

Jean

Ainsi, la rponse la question est Marie.

Figure XV.14 : Exemple dvaluation top-down

6. LA MODLISATION DE RGLES
PAR DES GRAPHES
Il est important de comprendre les connections entre les rgles dun programme. Un
modle bas sur un graphe est gnralement utilis pour visualiser les liens entre
rgles. Un tel modle capture les unifications possibles entre les prdicats en tte de

546 BASES DE DONNES : OBJET ET RELATIONNEL

rgles et ceux figurant dans les conditions. Il permet souvent dillustrer le mcanisme
doptimisation-excution ou de vrifier la cohrence des rgles. Par exemple, des
rgles peuvent tre contradictoires ou organises de telle manire que certaines relations restent vides. Dans cette section, nous allons prsenter les modles graphiques
les plus connus.

6.1. ARBRES ET GRAPHES RELATIONNELS

Toute rgle peut tre interprte comme une production relationnelle. Les conditions
dans le corps de rgle reprsentent des restrictions (conditions de la forme x v, o
est un oprateur de comparaison et v une valeur), des jointures (prsence dune mme
variable dans deux prdicats relationnels), des diffrences (ngation de prdicats relationnels). Les implications correspondent des projections. Plusieurs rgles gnrant
le mme prdicat correspondent une union. Il est donc possible de reprsenter un
programme de rgle DATALOGneg par un graphe doprations relationnelles. Le
graphe est un arbre dans le cas o aucun prdicat nest rcursif.
Le type de nud correspondant chaque opration relationnelle est reprsent
figure XV.15. Une duplication est simplement une recopie en un ou plusieurs exemplaires dun rsultat intermdiaire. Une addition est une union dune relation avec la
relation cible (cas particulier dunion dans laquelle le rsultat est cumul dans une des
deux relations). Un arbre est gnr par combinaison de ces nuds. La figure XV.16
illustre la mthode de construction pour les rgles suivantes :
(r1)
PARENT(x,z) MERE(x,t,z), t >16
(r2)
PARENT(x,z) PERE(x,t,z), t > 16
(r3)
ANCETRE(x,z) PARENT(x,z)
(r4)
ANCETRE(x,z) ANCETRE(x,y), PARENT(y,z)
(r5)
REPONSE(x) ANCETRE(x,toto)

Union

Diffrence

Addition

Duplication

Restriction

Projection

Jointure

Figure XV.15 : Oprateurs de lalgbre relationnelle utiliss

Bases de donnes dductives 547

REPONSE

DESC = toto

ANCETRE
D

PARENT

t > 16

MERE

t > 16

PERE

Figure XV.16 : Calcul des anctres par un graphe doprateurs relationnels

Notez quen gnral, la possibilit de complter le graphe par un oprateur de duplication permet dviter de dupliquer des branches similaires de larbre et doptimiser
lexcution correspondante. Par exemple, si lon ajoute la rgle :
(r0)
AIME(x,z) MERE(x,t,z), t >16
il nest pas ncessaire de dupliquer toute la branche de restriction sur mre, mais seulement dintroduire un oprateur de duplication au niveau du rsultat de cette branche.
Celui-ci gnre les tuples de AIME. Soulignons aussi que le nom dun prdicat intermdiaire peut tre omis lorsque ce dernier ne doit pas tre gard. Finalement, un
graphe doprateurs relationnels donne un moyen de gnrer par simple traduction un
programme bottom-up calculant la rponse une question dductive. Tout le problme doptimisation de questions dductives peut tre vu comme un problme
doptimisation de graphes relationnels. Pour rsumer, nous dfinirons informellement
la notion de graphe relationnel de rgles comme suit :

548 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XV.19 : Graphe relationnel de rgles (Relational Rule Graph)

Graphe doprateurs relationnels reprsentant lexcution bottom-up dun programme de rgles
pour rpondre une question.

6.2. ARBRES ET/OU ET GRAPHES RGLE/BUT

Le modle le plus connu vient de lintelligence artificielle, o il est utilis pour reprsenter lexcution de rgles en chanage arrire. Il sagit des arbres ET/OU.
Notion XV.20 : Arbre ET/OU (AND/OR tree)
Arbre compos de deux sortes de nuds, les nuds OU reprsentant les prdicats et les nuds ET
reprsentant les rgles, dans lesquels la racine reprsente une question et les arcs lvaluation topdown de la question.

tant donn un programme DATALOG sans ngation et une question, un arbre

ET/OU est construit comme suit. Chaque occurrence de prdicat est reprsente par
un ou plusieurs nuds OU. Une rgle correspond un ou plusieurs nuds ET. La
racine de larbre est le prdicat de la question, donc un nud OU. Les enfants dun
nud OU sont toutes les rgles dont la tte sunifie avec le prdicat reprsent par le
nud OU ; ce sont donc des nuds ET. Les enfants dun nud ET sont toutes les
occurrences des prdicats relationnels qui apparaissent dans le corps de la rgle reprsente. En principe, larbre est dvelopp jusqu ce que les prdicats de la base
extensionnelle apparaissent comme des feuilles. Pour spcifier les unifications (passages de paramtres) effectues lorsque lon passe dune rgle une autre, la substitution qui unifie la tte de rgle avec le prdicat parent (apparaissant dans le corps de la
rgle prcdente) peut tre mmorise comme une tiquette sur larc allant du nud
reprsentant la rgle au prdicat sunifiant avec sa tte.
Par exemple, considrons le programme DATALOG suivant :
(r1) PARENT(x,z) MERE(x,t,z)
(r2) PARENT(x,z) PERE(x,t,z)
(r3) GRANDPARENT(x,z) PARENT(x,y), PARENT(y,z)
(q) ? GRANDPARENT(x,Jean)
Larbre ET/OU associ la rsolution de la question (q) en drivation top-down est
reprsent figure XV.17. Un nud ET est reprsent par un rectangle et un nud OU
par une ellipse.
Un arbre ET/OU montre la propagation des constantes depuis la question vers les
relations de la base extensionnelle en chanage arrire. Malheureusement, dans le cas
de rgles rcursives, un arbre ET/OU peut devenir infini car de nouvelles occurrences

Bases de donnes dductives 549

de rgles sont ajoutes pour dvelopper les nuds qui correspondent des relations
rcursives. Nous dvelopperons la rcursion dans la section suivante. Cependant, il
apparat dj que des graphes plus sophistiqus sont ncessaires pour reprsenter les
rgles rcursives.
GRANDPARENT (x,Jean)
z /Jean
r3

PARENT (x,y)

PARENT (y,z)

z/y

z/y

x/y

x/y

r1

r2

r1

r2

MERE (x,t,z)

PERE (x,t,z)

MERE (x,t,z)

PERE (x,t,z)

Figure XV.17 : Exemple darbre ET/OU

Une extension de larbre ET/OU pour viter les branches infinies en cas de prdicats
rcursifs est le graphe rgle/but. Un graphe rgle/but est aussi associ une question
qui spcifie un prdicat valuer. Il contient en outre des nuds circulaires reprsentant les prdicats et des nuds rectangulaires reprsentant les rgles. Les seuls arcs
dun graphe rgle/but sont dfinis par la rgle suivante : sil existe une rgle r de la
forme P P1, P2 Pn dans le programme de rgles, alors il existe un nud allant
du nud r au nud P et, pour chaque Pi, il existe un arc allant du nud Pi au nud r.
Dans sa forme la plus simple, un graphe rgle/but peut tre dfini comme une variation dun graphe ET/OU :
Notion XV.21 : Graphe rgle/but (Rule/goal graph)
Graphe reprsentant un ensemble de rgles driv dun arbre ET/OU en remplaant lexpansion de
tout prdicat driv dj dvelopp dans larbre par un arc cyclique vers la rgle correspondant
ce dveloppement.

Ainsi, un graphe rgle/but ne peut tre infini. En prsence de rgles rcursives, il

contient simplement un cycle. Il correspond donc un graphe ET/OU dans lequel une
expansion dj faite est remplace par une rfrence cette expansion. La
figure XV.18 reprsente le graphe rgle/but correspondant au programme suivant :
{ (r1)
PARENT(x,z) MERE(x,t,z), t >16
(r2)
PARENT(x,z) PERE(x,t,z), t > 16
(r3)
ANCETRE(x,z) PARENT(x,z)
(r4)
ANCETRE(x,z) ANCETRE(x,y), PARENT(y,z) }.

550 BASES DE DONNES : OBJET ET RELATIONNEL

ANCETRE

r1

r4

PARENT

r1

MERE

PARENT

ANCETRE

r2

PERE

Figure XV.18 : Exemple de graphe rgle/but

6.3. AUTRES REPRSENTATIONS

Plusieurs autres reprsentations graphiques dun ensemble de rgles ont t proposes, parmi lesquelles les graphes de connexion de prdicats (PCG) [McKay81] et
les rseaux de Petri prdicats (PrTN) [Gardarin85, Maindreville87].
Un graphe de connexion de prdicats (PCG) modlise toutes les unifications possibles entre les prdicats dun programme de rgles. Plus prcisment, une rgle est
modlise comme un nud multiple du PCG ; un tel nud est reprsent par un rectangle contenant le prdicat de tte puis les prdicats du corps. Un arc reprsente
une unification entre un prdicat apparaissant en tte de rgle et un prdicat apparaissant dans le corps dune rgle ; un arc est orient et tiquet par la substitution
de variables ralisant lunification. La figure XV.19 reprsente le PCG associ au
programme :
(r1)
PARENT(x,z) MERE(x,t,z)
(r2)
PARENT(x,z) PERE(x,t,z)
(r3)
ANCETRE(x,z) PARENT(x,z)
(r4)
ANCETRE(x,z) ANCETRE(x,y), PARENT(y,z)
Un PCG actif correspond un parcours simulant le chanage arrire du PCG partir
dune question reprsente comme un nud singulier sans tte [McKay81].

Bases de donnes dductives 551

PARENT(x,z)

MERE(x,t,z)
x/x,
z/z

x/x,
z/z

x/x,
z/z
ANCETRE(x,z)

PARENT(x,z)

x/x,
z/z

PARENT(x,z)
x/x,
z/y

x/x,
y/z
ANCETRE(x,z)

PERE(x,t,z)

ANCETRE(x,y)

x/y,
z/z
x/y,
z/z

y/x,
z/z

y/x,
z/z

ANCETRE(y,z)

x/x,
y/z
x/x, z/y

Figure XV.19 : Un exemple de PCG

Un rseau de Petri prdicats (PrTN) modlise directement une valuation bottomup (en chanage avant) dun programme de rgles. Chaque relation (prdicat intentionnel ou extentionnel) est modlise par une place ; les jetons de marquage correspondent aux tuples des relations. Chaque rgle est modlise par une transition ; le
prdicat correspond la condition de la rgle. Les rgles gnrent en sortie de nouveaux jetons (tuples) ; pour reprer quels jetons sont gnrs, on tiquette en gnral
les arcs sortant des transitions avec des variables qui reprsentent les attributs des
tuples gnrs. Les arcs entrants sont aussi tiquets afin de faciliter lcriture des
conditions. Une excution du PrTN modlise un calcul de point fixe en chanage
avant. Afin dviter la destruction des tuples dans les places lors dun dclenchement
dune transition, il faut ajouter un arc qui remet le jeton aprs excution de la transition. Pour allger, nous notons par un point le fait que le jeton doit tre conserv dans
sa place lors de lexcution dune transition. Labsence de point permet de modliser
les mises jour par les rgles. La figure XV.20 illustre le PrTN correspondant au programme de rgles dj modlis figure XV.18 et XV.19.
La figure XV.21 prsente une synthse des principales caractristiques des diffrents
modles graphiques introduits ci-dessus. Notez que llment dterminant apparat
finalement tre lorientation top-down (dirige par les questions) ou bottom-up (dirige par les donnes) du modle. Diffrentes variantes de ces modles ont aussi t

552 BASES DE DONNES : OBJET ET RELATIONNEL

proposes ; elles permettent en gnral de mieux prendre en compte une fonctionnalit du langage de rgles modlis.

PERE

MERE

x,t,z

x,z
x,z

x,t,z

x,z

PARENT

yp,z
x,z

ANCETRE
ya = yp
x,z

Figure XV.20 : Un exemple de PrTN

Caract.

Modle

Graphe
Relationnel

Graphe
Rgle/but

PCG
Actif

PrTN
Etendu

Fonction

oui

non

non

oui

Negation

oui

non

non

oui

Mise jour

oui

non

non

oui

Condition Non Horn

oui

non

non

oui

Bottom up

oui

non

non

oui

Top Down

non

oui

oui

non

Recursion

oui

oui

oui

oui

Figure XV.21 : Comparaison des modles de graphes

Bases de donnes dductives 553

7. VALUATION DES RGLES RCURSIVES

Cette section prsente les techniques essentielles permettant doptimiser des requtes
dans le cas de rgles rcursives.

7.1. LE PROBLME DES RGLES RCURSIVES

Le problme de loptimisation et de lvaluation de requtes portant sur des prdicats
drivs rcursifs est tudi depuis longtemps [Gallaire78, Minker82]. Il sagit dun
problme difficile et important compte tenu de linfluence de la rcursion, notamment
dans les applications dintelligence artificielle. [Bancilhon86b] expose les premires
solutions connues.
Un exemple typique, dj vu ci-dessus, de prdicat driv rcursif est la dfinition des
anctres ANC partir dune relation de base parent note PAR(PARENT,ENFANT)
comme suit :
(r1)
ANC(x,y) PAR(x,y)
(r2)
ANC(x,y) PAR(x,z), ANC(z,y).
Un tel exemple est linaire car la relation ANC est dfinie en fonction dune seule
occurrence de la relation ANC dans la seule rgle rcursive (r2). Il est possible de
donner une dfinition non linaire des anctres en remplaant la rgle r2 par :
ANC(x,y) ANC(x,z),ANC(z,y)
Cette rgle est quadratique car ANC apparat deux fois dans le corps.
Un exemple typique est celui du calcul des cousins de mme gnration. Pour initialiser la relation MG(PERSONNE,PERSONNE) dfinissant les cousins de mme gnration, il est commode de constater que chacun est son propre cousin de mme gnration. Toutes les personnes connues tant stockes dans une relation unaire HUM
(humains), on obtient la rgle dinitialisation :
(r1)
MG(x,x) HUM(x)
Notez que la relation humain (HUM) peut tre obtenue par les deux rgles :
HUM(x) PAR(x,y)
HUM(y) PAR(x,y)
Pour complter la relation MG, on dira quune personne x est le cousin de mme gnration quune personne y si deux de leurs parents sont aussi cousins de mme gnration. On aboutit alors la rgle :
(r2)
MG(x,y) PAR(xp,x),MG(xp,yp),PAR(yp,y)
Il existe plusieurs autres manires de dfinir les cousins de mme gnration. En particulier, comme MG est une relation symtrique (MG(x,y) MG(y,x)), il est

554 BASES DE DONNES : OBJET ET RELATIONNEL

possible dintervertir les variables xp et yp intrieur de MG dans r2. Cela conduit la

dfinition suivante des cousins de mme gnration :
(r1)
MG(x,x) HUM(x)
(r2)
MG(x,y) PAR(xp,x),MG(yp,xp),PAR(yp,y)
Un exemple plus complexe car quadratique est la dfinition des personnes au mme
niveau hirarchique par un prdicat dduit MC(EMPLOYE,EMPLOYE), spcifie
partir dune relation SER(SERVICE,EMPLOYE) et dune relation
CHEF(EMPLOYE,EMPLOYE) :
(r1) MSER(x,y) SER(s,x),SER(s,y)
(r2) MC(x,y) MSER(x,y)
(r3) MC(x,y) CHEF(x,z1),MC(z1,z2),MSER(z2,z3),MC(z3,z4),CHEF(y,z4)
Cet exemple est quadratique car la rgle rcursive r3 dfinit le prdicat driv MC en
fonction de deux occurrences du mme prdicat. Elle est illustre figure XV.22. Il est
videmment possible de dfinir la relation MC de manire plus simple, la complexit
ayant ici pour but de mieux illustrer dans des cas non triviaux les diffrents algorithmes que nous verrons ci-dessous.
MSER
MC
CHEF

z1
x

MC
z2

z3

CHEF

z4
y

Figure XV.22 : Dfinition de la relation rcursive Mmes Chefs

Il est aussi possible dutiliser DATALOGfonc afin de dfinir des prdicats rcursifs
avec calculs de fonctions. Des exemples typiques sont drivs des problmes de parcours de graphes. Un graphe valu peut tre reprsent par une relation :
ARC (SOURCE, CIBLE, VALUATION).
Chaque tuple de la relation reprsente un arc. Les rgles suivantes dduisent une relation CHEMIN reprsentant tout les chemins du graphe, avec une valuation compose
calcule par une fonction f :
CHEMIN(x,y,z) ARC(x,y,z)
CHEMIN(x,y,f(z1,z2)) ARC(x,z,z1), CHEMIN(z,y,z2)
Par exemple, si f(z1,z2) = z1 + z2 et si les valuations reprsentent des distances, les
rgles prcdentes dfinissent tous les chemins du graphe avec leur longueur associe.
Une autre application possible des fonctions dans les rgles rcursives est la manipulation dobjets structurs. Par exemple, des listes peuvent tre manipules avec la
fonction concatnation de deux listes X et Y, note X|Y. La base de donnes peut tre
compose dun prdicat dfinissant lensemble des listes constructibles partir de n

Bases de donnes dductives 555

lments. On spcifie lajout (par la fin) dune liste X une liste Y comme tant une
liste Z dfinie par le prdicat AJOUT(X,Y,Z), puis linversion des lments dune
liste X comme tant une liste Y dfinie par le prdicat INVERSE(X,Y). Les rgles
suivantes dfinissent ces prdicats drivs ([] dsigne la liste vide) :
(r1)
AJOUT(X,[],X|[]) LISTE(X)
(r2)
AJOUT(X,W|Y,W|Z) AJOUT(X,Y,Z),LISTE(W)
(r3)
INVERSE([],[])
(r4)
INVERSE(W|X,Y) INVERSE(X,Z),AJOUT(W,Z,Y)
AJOUT et INVERSE sont ainsi deux prdicats rcursifs linaires.
Le problme qui se pose est bien sr dvaluer des questions portant sur des prdicats
rcursifs. Ces questions spcifient en gnral des constantes pour certaines variables,
ou des ensembles de constantes (question avec , <, ,>). Voici quelques questions
typiques sur les prdicats dfinis prcdemment :
(1) Qui sont les anctres de Jean ?
? ANC(x,Jean)
(2) Pierre est-il un anctre de Jean ?
? ANC(Pierre,Jean)
(3) Qui sont les cousins de mme gnration de Jean ?
? MG(Jean,x)
(4) Qui sont les chefs au mme niveau que Jean ?
? MC(Jean,x)
(5) Quel est linverse de la liste [1,2,3,4,5] :
? INVERSE([1,2,3,4,5], x)
Il est bien sr possible de remplacer par des constantes tout sous-ensemble de paramtres afin de retrouver les autres (cependant, selon les instanciations, DATALOGfonc
peut conduire des rponses infinies comme vu ci-dessus), ou encore dinstancier
tous les paramtres afin dobtenir une rponse boolenne du type VRAI/FAUX.
Dans la suite, nous allons tudier les principales solutions proposes, en commenant par les solutions simples, en gnral peu performantes ou incompltes. Nous
tudierons ensuite les solutions interprtes qui transforment progressivement la
requte en sous-requtes adresses au SGBD, puis les solutions compiles qui, dans
un premier temps, gnrent un programme dalgbre relationnelle et dans un
deuxime temps demandent lexcution de ce programme. Bien que dcrivant les
principales approches, notre tude est loin dtre complte. En particulier, nous
ignorons des approches importantes bases sur des rgles de rcriture [Chang81],
des automates [Marque-Pucheu84] ou une mthode de rsolution adapte
[Henschen84].

556 BASES DE DONNES : OBJET ET RELATIONNEL

7.2. LES APPROCHES BOTTOM-UP

7.2.1. La gnration nave
La solution la plus nave pour valuer la rponse une requte consiste simplement
dans un premier temps appliquer un chanage avant direct partir des prdicats de
base jusqu saturation des prdicats drivs. Dans un deuxime temps, une slection
sur les prdicats drivs instancis permet de retenir les tuples rpondant la question. Cette solution est connue sous le nom de gnration nave.
Notion XV.22 : Gnration nave (Nave Generation)
Technique dvaluation bottom-up calculant une relation dduite par application de toutes les rgles
tous les tuples produits chaque tape du processus de gnration, jusqu saturation de la relation dduite.

Cette mthode de calcul de point fixe part donc des faits de la base et calcule les instances des prdicats drivs par application des rgles afin de rpondre la question.
En gnral, une valeur R0 est calcule pour le prdicat rcursif partir des rgles
dinitialisation. Puis, par un programme de lalgbre relationnelle qui rsulte dune
compilation lmentaire de la rgle rcursive, on effectue un calcul itratif
R = R E(R), o E est lexpression de lalgbre relationnelle traduisant la rgle
rcursive. Le processus sarrte quand lapplication de E R ne permet pas de gnrer
de nouveau tuple : on a alors le point fixe du prdicat rcursif dfini par R = E(R). Ce
point fixe existe en DATALOG [Aho-Ullman79]. Un programme de calcul naf dune
relation rcursive R scrit donc comme reprsent figure XV.23, E tant une expression de lalgbre relationnelle drive de la rgle rcursive.
Procedure Nave (R) {
R:= R0 ;
Tant que R change Faire
R := R E(R) ;
}

Figure XV.23 : Programme de gnration nave

Par exemple, dans le cas des anctres, on initialisera ANC par la rgle r1 avec les
parents, puis on appliquera la rgle r2 en effectuant une boucle de jointures de la relation ANC avec la relation PAR, et ce jusqu ce que lon ne gnre plus de nouvel
anctre. Le calcul est illustr figure XV.24. Le processus sera similaire pour gnrer la
relation MC : les rgles r1 et r2 permettent de lui attribuer une valeur initiale MC0, puis
les jointures des relations CHEF,MC0,MSER,MC0,CHEF permettront de calculer MC1.
De manire itrative, les jointures de CHEF,MCi,MSER,MCi,CHEF permettront de calculer MCi+1. Le calcul sarrtera quand aucun nouveau tuple sera gnr : on aura

Bases de donnes dductives 557

obtenu le point fixe de la relation MC qui dcrit toutes les personnes de la base un
mme niveau hirarchique.
RGLES
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y)
PROGRAMME NAF
ANC := ;
while "ANC changes" do
ANC := ANC PAR

AN

CALCULS SUCCESSIFS
PARENT

ANCETRE

ASC

DESC

Jack
Jack
Ted
Pierre

Jean
Marie
Jack
Ted

ASC

DESC

Jack
Jack
Ted
Pierre
Ted
Ted
Pierre

Jean
Marie
Jack
Ted
Jean
Marie
Jack

ANCETRE(x,Jean) ASC

DESC

Jack
Ted
Pierre

Jean
Jean
Jean

ANCETRE

ANCETRE

ASC

DE

Jack
Jack
Ted
Pierre

Je
Ma
Ja
T

ASC

DE

Jack
Jack
Ted
Pierre
Ted
Ted
Pierre
Pierre
Pierre

Je
Ma
Ja
T
Je
Ma
Ja
Je
Ma

Figure XV.24 : valuation nave des anctres de Jean

Si les programmes de rgles sont en DATALOG pur, comme pour ANC et MC, il
nexiste pas de fonction pour gnrer des valeurs qui ne sont pas dans la base : ceci
garantit la finitude du processus de gnration [Aho-Ullman79]. Dans le cas des listes,
la stratgie bottom-up ne peut tre applique telle quelle ; en effet, par ajout de listes,
on gnre des listes sans fin. Le processus de gnration ne se termine pas.

558 BASES DE DONNES : OBJET ET RELATIONNEL

Une tude plus dtaille du processus de gnration naf dmontre plusieurs faiblesses
de la mthode, outre le fait quune terminaison nest garantie quen cas dabsence de
fonction :
1. chaque itration, un travail redondant est effectu, qui consiste refaire les infrences de litration prcdente ; cela provient du fait que lon cumule les rsultats
avec les anciens et que lon applique nouveau la jointure tous les rsultats sans
distinction.
2. Dans le cas o des constantes figurent dans la question, un travail inutile est effectu car la gnration produit des rsultats qui ne figurent pas dans la rponse ; ils
sont limins par la slection finale. Par exemple, pour calculer les seuls anctres de
Jean, le processus conduit gnrer les anctres de toutes les personnes de la base.
Voici maintenant les principales mthodes qui rpondent ces critiques.

7.2.2. La gnration semi-nave

Afin dviter des calculs redondants, il est possible de considrer chaque itration
les seules infrences nouvelles, cest--dire celles incluant au moins un tuple gnr
ltape prcdente qui nexistait pas dj dans la relation drive. Ainsi, en utilisant
les tuples nouveaux litration i-1, il est possible de calculer les tuples nouveaux
litration i sans refaire des infrences dj faites ltape i-1. Cette mthode est
appele gnration semi-nave.
Notion XV.23 : Gnration semi-nave (Seminave generation)
Technique dvaluation bottom-up calculant une relation dduite par application itrative des rgles
seulement aux nouveaux tuples produits chaque tape du processus dinfrence, jusqu saturation de la relation dduite.

Dans le cas de rgles linaires, lapproche consiste remplacer litration i la relation rcursive Ri produite jusque-l par Ri = Ri Ri1. Si E(R) est lexpression de
lalgbre relationnelle reprsentant le corps de la rgle rcursive, on calcule alors
Ri+1 = E(Ri) Ri, puis Ri+1 = Ri Ri+1. Dans le cas de rgles non linaires (par
exemples quadratiques), le problme est plus complexe car il faut aussi considrer les
infrences possibles entre les anciens tuples de Ri et les nouveaux de Ri. tant donn
lexpression Ri+1 = E(Ri) o E est une expression de lalgbre relationnelle, il est toujours possible de calculer Ri+1 = E(Ri) par drivation de E. On peut ainsi transformer un programme dalgbre relationnelle effectuant un chanage avant naf en un
programme effectuant un chanage avant semi-naf, ce qui permet dviter le travail
redondant.
Par exemple, dans le cas des anctres, il suffira deffectuer chaque itration la jointure de la relation parent avec les nouveaux tuples anctres gnrs ltape prcdente. Dans le cas de la relation MC, il faudra effectuer litration i les jointures :

Bases de donnes dductives 559

CHEF
CHEF
CHEF

MCi
MCi
MCi

MSER
MSER
MSER

MCi
MCi
MCi

CHEF
CHEF
CHEF

afin de considrer toutes les infrences nouvelles possibles, puis lunion des rsultats
et la diffrence avec les rsultats dj connus pour obtenir Ri+1. Le processus diffrentiel apparat donc ici comme assez lourd, mais il vite la jointure CHEF MCi
MSER MCi CHEF.
Fond sur les principes prcdents, lalgorithme semi-naf [Bancilhon86b] effectue
donc un calcul diffrentiel de la relation rcursive R comme reprsent figure XV.25.
Quand les mmes tuples ne peuvent tre produits deux fois par deux itrations diffrentes, la diffrence R = R R nest pas ncessaire. Ce cas ncessite lacyclicit
des rgles et des donnes [Gardarin87], comme dans le cas du calcul des anctres de
Jean illustr figure XV.26 (page suivante).
Procedure SemiNave (R) {
R := R0
R := R ;
Tant que R faire {
R = E(R,R) ;
R = R R ;
R = R R ;
};
} ;

Figure XV.25 : Programme de gnration semi-naf

Lalgorithme semi-naf peut tre implant directement au-dessus dun SGBD.

Cependant, une telle implantation ne sera pas trs efficace car lalgorithme accomplit
des boucles de jointures, unions et diffrences afin datteindre la saturation. Pour amliorer les performances, une gestion de mmoire judicieuse tirera profit du fait que les
relations dans la boucle restent les mmes (R, R, relations de E). Nammoins, pas
plus que le chanage avant naf, le chanage avant semi-naf ne sapplique aux listes,
ceci tant d au problme de gnration infinie.

7.3. DIFFICULTS ET OUTILS POUR LES APPROCHES

TOP-DOWN
7.3.1. Approches et difficults
Au lieu dappliquer le chanage avant pour gnrer la rponse une question, il est
possible de travailler en chanage arrire la PROLOG . Une telle approche part

560 BASES DE DONNES : OBJET ET RELATIONNEL

RGLES
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y)
PROGRAM SEMI-NAF
PARENT

ASC

DESC

Jack
Jack
Ted
Pierre

Jean
Marie
Jack
Ted

ANC := PARENT ;
ANC := ANC;
Tantque " ANC changes" faire
ANC := PARENT
ANC
ANC := ANC ANC ;

CALCULS SUCCESSIFS
ANC

ASC

DESC

Jack
Jack
Ted
Pierre

Jean
Marie
Jack
Ted

ASC

DESC

Ted
Ted
Pierre

Jean
Marie
Jack

ASC

DESC

Pierre
Pierre

Jean
Marie

ANC (x,Jean) ASC

DESC

Jack
Ted
Pierre

Jean
Jean
Jean

ANC

ANC

ANC

ANC

ANC

ASC

DESC

Jack
Jack
Ted
Pierre

Jean
Marie
Jack
Ted

ASC

DESC

Jack
Jack
Ted
Pierre
Ted
Ted
Pierre

Jean
Marie
Jack
Ted
Jean
Marie
Jack

ASC

DESC

Jack
Jack
Ted
Pierre
Ted
Ted
Pierre
Pierre
Pierre

Jean
Marie
Jack
Ted
Jean
Marie
Jack
Jean
Marie

Figure XV.26 : valuation semi-nave des anctres de Jean

Bases de donnes dductives 561

de la question pour remonter aux faits via les rgles. En consquence, elle est qualifie de stratgie top-down comme vu ci-dessus. Malheureusement, dans le cas de
rgles rcursives la mthode top-down peut conduire boucler.
Nous allons tout dabord montrer une application de la mthode dans le cas favorable.
Par exemple, avec la rgle :
ANC(x,y) PAR(x,z), ANC(z,y)
la question ANC(Jean,y) gnre la sous-question PAR(Jean,z),ANC(z,y). Tenter de
rsoudre directement ANC(z,y) en chanage arrire conduit boucler. Par contre, si
lon value PAR(Jean,z) sur la relation de base PARENT, on obtient des constantes
c0, c1... pour z. Il devient alors possible de rsoudre en chanage arrire
ANC(c0,y),ANC(c1,y)...
qui gnrent les sous-questions
PAR(c0,z),ANC(z,y),PAR(c1,z),ANC(z,y), etc. Le processus sarrte
quand il nexiste plus de sous-question gnrable du type PAR(ci,z) ayant une
rponse non vide.
La mthode nest cependant applicable que dans le cas particulier o la constante de
la question se propage pour regnrer la mme sous-question. Par exemple, dans le
cas de la rgle :
ANC(x,y) ANC(x,z), PAR(z,y)
la question ANC(Jean,y) conduit gnrer la sous-question ANC(Jean,z).
Changer y en z ne fait pas progresser le problme et le processus boucle totalement.
Nous verrons dans la suite des extensions de cette approche la Prolog qui permettent dviter le bouclage en utilisant les autres rgles et en mlant chanage
arrire-chanage avant. Auparavant, nous allons tudier plus en dtail la propagation
des constantes dans les rgles.

7.3.2. La remonte dinformations via les rgles

Quand elles sappliquent, les mthodes par chanage arrire remontent les constantes
depuis la question vers les relations de base et permettent donc deffectuer les restrictions avant la rcursion. Afin de mieux comprendre la remonte des constantes dans le
corps des rgles, il est possible de lillustrer par un graphe appel graphe de propagation. Il sagit l dune reprsentation des propagations dinformations entre prdicats au sein dune rgle [Beeri87], appeles en anglais Sideways Information
Passing [Ullman86].
Notion XV.24 : Propagation dinformations (Information Passing)
Passage de constantes instanciant une variable x dun prdicat P(,xy) un autre prdicat
Q(,y) en effectuant une slection sur P avec les valeurs de x, suivie dune jointure avec Q sur y.

562 BASES DE DONNES : OBJET ET RELATIONNEL

Les propagations dinformations dans les rgles se reprsentent donc par des graphes.
Un graphe de propagation pour une rgle est un graphe tiquet qui dcrit comment
les constantes obtenues par la tte de la rgle se propagent aux autres prdicats de la
rgle. Il existe plusieurs graphes de propagation possibles pour une rgle, suivant les
choix de propagation effectus. Pour faciliter la comprhension et viter de rpter
des morceaux de rgles, une reprsentation simplifie avec des bulles reprsentant les
sommets du graphe est propose. Les prdicats de la rgle sont crits de gauche
droite, depuis la tte jusquau dernier prdicat de la condition. Un sommet du graphe
(donc reprsent par une bulle) est, soit un groupe de prdicats, soit un prdicat rcursif. Un arc N p relie un groupe de prdicats N une occurrence dun prdicat
rcursif p. Larc N p est tiquet par des variables dont chacune apparat dans un
prdicat de N et dans p. Un graphe de propagation est valide sil existe un ordre des
sommets (appel ici ordre de validit) tel que, pour chaque arc, tout membre de sa
source apparaisse avant sa cible. Pour faciliter la visualisation dun graphe de propagation valide, il est souhaitable dcrire les occurrences de prdicats selon lordre de
validit. Les figures XV.27 et XV.28 prsentent deux graphes de propagation valides
pour les rgles rcursives des exemples Anctres et Chefs.
z

ANC (z,y)

ANC (x,y) PAR (x,z)

Figure XV.27 : Un graphe de propagation valide pour la rgle

ANC(x,y) PAR(x,z), ANC(z,y)

z1

MC (x,y) CHEF (x,z1)

z3

MC (z1,z2)

MSER (z2,z3)

MC (z3,z4)

CHEF (y,z4)

Figure XV.28 : Un graphe de propagation valide pour la rgle

MC(x,y) CHEF(x,z1), MC(z1,z2),MSER(z2,z3),MC(z3,z4),CHEF(y,z4)

La signification intuitive dun graphe de propagation valide est la suivante : en supposant instancie la jointure des prdicats entours par une bulle source dun arc, il
serait possible de propager les valeurs des variables tiquettes vers le prdicat cible de
larc. Si la bulle source contient le prdicat de tte de la rgle, un arc modlise la pro-

Bases de donnes dductives 563

pagation de constantes vers un prdicat rcursif en chanage arrire suite une instantiation dune variable de la tte. Une telle propagation est donc une propagation par
effet de bord.
Un graphe de propagation valide est linaire si pour tout arc N p, N contient tous
les nuds qui prcdent p selon lordre de validit. Suivant [Beeri87], nous dirons
quun graphe de propagation valide linaire est total si toute variable dun prdicat
rcursif r cible dun arc apparaissant dans un prdicat qui prcde r tiquette un arc
entrant dans r. Nous utiliserons les graphes de propagation de constantes dans la suite,
notamment pour la mthode des ensembles magiques gnraliss [Beeri87].

7.3.3. Les rgles signes

Une signature (en anglais adornment [Ullman86]) consiste associer un prdicat
un vecteur de bits qui indique par des 1 les variables lies par des constantes et par
des 0 les variables libres (nous suivons ici la mthode de [Rohmer86], [Ullman86]
ayant pour sa part utilis les lettres b (bounded) et f (free) pour 1 et 0). Par exemple, le
prdicat ANC(Jean,x) peut tre crit sous forme dun prdicat sign par un index
binaire ANC10(Jean,x). Les rgles sont souvent rcrites avec des prdicats signs ;
elles sont alors appeles rgles signes [Beeri87]. Ainsi, si P110(x,y,z) apparat en tte
dune rgle, cela signifie que la rgle sera invoque avec x et y instancis par des
constantes.
Notion XV.25 : Rgle signe (Adorned Rule)
Rgle rcrite avec des prdicats signs (indexs par des 1 signifiant position instancie et des 0
signifiant position libre) selon une question et un graphe de propagation.

La tte de la rgle est tout dabord signe selon lunification ralise avec la question.
La signature est ensuite propage aux autres prdicats rcursifs en suivant les arcs du
graphe de propagation et en marquant 1 les variables correspondant aux tiquettes
dans les prdicats cibles [Beeri87]. Lutilisation de rgles signes permet de distinguer
des prdicats de mmes noms ayant des variables instancies diffrentes. Cela est trs
utile dans le cas de rgles non stables, o les constantes changent de position dans les
occurrences dun mme prdicat [Henschen-Naqvi84]. Voici les rgles rcursives
signes pour les Anctres et les Chefs, selon les graphes de propagation reprsents respectivement figure XV.27 et XV.28, pour les questions ? ANC(Jean,x)
et ? MC(Jean,y) :
ANC10(x,y) PAR(x,z), ANC10(z,y)
MC10(x,y) CHEF(x,z1),MC10(z1,z2),MSER(z2,z3),
MC10(z3,z4),CHEF(y,z4)
Dans la suite, nous utiliserons les rgles signes pour tous les algorithmes bass sur la
rcriture de rgles.

564 BASES DE DONNES : OBJET ET RELATIONNEL

7.4. LA MTHODE QoSaQ

Les mthodes interprtes sont des extensions des mthodes de chanage arrire
la Prolog qui traitent correctement les rgles rcursives, dune part en utilisant bien
les rgles dinitialisation et dautre part en incluant un tantinet de chanage avant pour
gnrer des sous-questions. Elles sont caractrises par le fait quelles sont appliques
lors de lexcution dune question et non pas lors de lentre des rgles, la compilation.
Lapproche QSQ (Query Sub-Query) dcrite dans [Vieille86] a t implante
lECRC (Munich). Elle est devenue QoSaQ lorsquelle a t gnralise au support
complet de DATALOG. Elle peut tre vue comme une amlioration de la mthode de
chanage arrire consistant mmoriser les sous-questions gnres lors de lunification et appliquer globalement les sous-questions de mme forme, afin de limiter le
nombre de sous-questions traiter. Un ensemble de sous-questions {? R(ai,y) | i
[1,n] } est ainsi remplac par une seule sous-question avec critre disjonctif ?
R({a1 a2 ... an},y). La remonte des constantes pour dterminer les faits relevants
seffectue par chanage arrire comme en PROLOG. De plus, une sous-question nest
excute que si elle ne la pas dj t. Le critre darrt est donc double : pas de nouvelle sous-question gnre ou pas de nouveau fait relevant gnr.
Ces techniques de mmorisation conduisent une mthode rapide en temps dexcution, mais relativement consommatrice en mmoire puisque faits relevants et sousquestions doivent tre mmoriss. Deux versions de la mthode ont t implantes,
lune itrative qui parcourt la liste des sous-questions traiter, lautre rcursive qui se
rappelle chaque sous-question avec critre disjonctif gnr. Notez que la mthode
QoSaQ rsout les problmes de cycles dans les donnes (par exemple, une personne
qui serait son propre anctre) puisque elle nexcute que des sous-questions nouvelles.

7.5. LES ENSEMBLES MAGIQUES

La mthode des ensembles magiques est une mthode compile permettant de gnrer
un programme dalgbre relationnel tendu avec des boucles. Elle se compose dune
phase de rcriture des rgles puis dune seconde phase appliquant la gnration seminave vue ci-dessus. Elle est base sur lide dun petit gnie [Bancilhon86a] qui,
avant application du chanage avant semi-naf, marque les tuples utiles du prdicat
rcursif R laide dun prdicat associ, appel magique et not MAGIQUE_R.
Ainsi, les calculs en chanage avant ne sont effectues que pour les tuples susceptibles
de gnrer des rponses, qui sont marqus par le prdicat magique. La premire version des ensembles magiques [Bancilhon86a] ne sappliquait gure quaux rgles
rcursives linaires. Une version gnralise a t publie sous le nom densembles
magiques gnraliss [Beeri87]. Nous allons prsenter maintenant cette version.

Bases de donnes dductives 565

Le point de dpart est un programme de rgles signes comme vu ci-dessus et un

graphe SIP de propagation de constantes par effets de bord. Lintention est de gnrer
un programme de rgles qui, laide du ou des prdicats magiques, modlise le passage des informations entre prdicats selon le graphe SIP choisi. Pour chaque prdicat
rcursif sign Rxx, un prdicat magique est cr, not MAGIQUE_Rxx dont les
variables sont celles lies dans Rxx ; larit du prdicat MAGIQUE_Rxx est donc le
nombre de bits 0 dans la signature xx. Ainsi, un prdicat magique contiendra des
constantes qui permettront de marquer les tuples de Rxx utiles. Chaque rgle est modifie par addition des prdicats magiques sa partie condition, pour restreindre linfrence aux tuples marqus par les prdicats magiques. Par exemple, une rgle :
B1xx,B2xx...R10,C1xx,C2xx... R10(x,y)
sera transforme en :
MAGIC_R10(x), B1xx,B2xx...R10,C1xx,C2xx... R10(x,y)
qui signifie que la condition ne doit tre excute que pour les tuples de R10 marqus
par le prdicat MAGIC_R10(x).
Le problme un peu plus compliqu rsoudre est de gnrer les constantes du (ou
des) prdicat(s) magique(s) pour marquer tous les tuples utiles et, si possible, seulement ceux-l. Une premire constante est connue pour un prdicat magique : celle
drive de la question ; par exemple, avec la question ? R(a,x), on initialisera le processus de gnration des prdicats magiques par MAGIC_R10(a). La gnration des
autres tuples du (ou des) prdicat(s) magique(s) seffectue en modlisant les transmissions de constantes tous les prdicats drivs par le graphe SIP choisi. Plus prcisment, pour chaque occurrence de prdicat driv Rxx apparaissant dans le corps dune
rgle, on gnre une rgle magique dfinissant les variables lies de Rxx comme suit :
la conclusion de la rgle est MAGIQUE_Rxx(...) et la condition est compose de tous
les prdicats qui prcdent Rxx dans le graphe SIP, les prdicats drivs dont certaines
variables sont lies tant remplacs par les prdicats magiques correspondants. Les
variables sont dtermines par le graphe SIP et par les bits 1 des signatures pour les
prdicats magiques. Vous trouverez une explication plus dtaille et une preuve partielle de la mthode dans [Beeri87].
Nous traitons les exemples des anctres et des mmes chefs avec la mthode des
ensembles magiques gnraliss figure XV.29. Les rsultats montrent que les rgles
de production gnres rptent pour partie la condition de la rgle prcdente. Ce
nest pas optimal, car on est conduit rvaluer des conditions complexes. Une solution consistant mmoriser des prdicats intermdiaires de continuation a t propose sous le nom d ensembles magiques gnraliss supplmentaires [Beeri87].
Cette mthode est voisine de celle dAlexandre propose par ailleurs [Rohmer86].
Pour le cas des rgles linaires, une version amliore des ensembles magiques a aussi
t propose [Naughton89]. Le mrite de la mthode reste cependant la gnralit.

566 BASES DE DONNES : OBJET ET RELATIONNEL

(1)

Les anctres dfinis linairement (question ?ANC(Jean,y)):

(r1) MAGIC_ANC10(x),PAR(x,y) ANC10(x,y)
(r2) MAGIC_ANC10(x),PAR(x,z) MAGIC_ANC10(z)
MAGIC_ANC10(x),PAR(x,z),ANC10(z,y) ANC10(x,y)

La question permet dinitialiser le chanage avant avec:

MAGIC_ANC10(Jean).
(2)

Les mmes chefs dfinis quadratiquement (question ?MC(Jean,y)) :

(r1) SER(s,x),SER(s,y) MSER(x,y)
(r2) MAGIC_MC10(x),MSER(x,y) MC10(x,y)
(r3) MAGIC_MC10(x),CHEF(x,z1) MAGIC_MC10(z1)
MAGIC_MC10(x),CHEF(x,z1),MC10(z1,z2),MSER(z2,z3) MAGIC_MC10(z3)
MAGIC_MC10(x),CHEF(x,z1),MC10(z1,z2),MSER(z2,z3),MC10(z3,z4),
CHEF(y,z4)MC10(x,y)

Le prdicat MAGIC_MC10 sera initialis comme suit par la question :

MAGIC_MC10(Jean)

Figure XV.29 : Application des ensembles magiques

7.6. QUELQUES MTHODES DOPTIMISATION

MOINS GNRALES
7.6.1. La mthode fonctionnelle
Les deux mthodes prsentes prcdemment conduisent rcrire un programme de
rgles avec des prdicats problmes ou magiques, pour pouvoir lexcuter de manire
optimise en chanage avant semi-naf. Malheureusement, le programme de rgles
obtenu est en gnral complexe (plus de rgles que le programme initial, rcursion
mutuelle) et lexcution semi-nave peut tre lourde. Par exemple, dans le cas des
anctres, la question ?ANC(Jean,y) conduit trois rgles vues ci-dessus, alors que la
solution consiste simplement calculer la fermeture transitive de la relation parent
partir de Jean. Ces remarques, avec en plus le fait que la dmonstration de la compltude des mthodes prcdentes est complexe, nous ont conduit dvelopper une
mthode plus formelle base sur des quations au point fixe qui sapplique dans un
contexte gnral avec fonctions [Gardarin87].
Une mthode dvaluation simple qui dcoule de la smantique de DATALOG
consiste crire des quations au point fixe en algbre relationnelle.
Malheureusement, la propagation directe des constantes nest pas possible dans de
telles quations ds que celles-ci se reportent sur une condition de jointure. Afin de
modliser dans les quations au point fixe la propagation des constantes, nous utilisons des fonctions arguments ensemblistes. Lide intuitive de la mthode est

Bases de donnes dductives 567

quune instance de relation dfinit en fait des fonctions ; chaque fonction transforme
un ensemble de valeurs dune colonne dans lensemble de valeurs correspondant dans
une autre colonne. Ainsi toute question ? R(a,y) est interprte comme une fonction r
appliquant lensemble des parties du domaine de a dans lensemble des parties du
domaine de y, cest--dire avec des notations classiques, r : 2dom(a) 2dom(y). valuer
la question ? R(a,y) revient alors valuer la fonction r({a}).
Etant donns une question et un ensemble de rgles, un algorithme permet de gnrer
une quation fonctionnelle au point fixe du type r = F(r), o F est une expression
fonctionnelle. Pour ce faire, des oprations monotones entre fonctions ont t introduites :
1. la composition de deux fonctions f o g (X) = f(g(X)) modlise en fait une jointure
suivie dune projection ;
2. laddition (f+g) (X) = f(X) g(X) modlise lunion ;
3. lintersection (f g) (X) = f(X) g(X) permet de modliser des jointures
cycliques.
Dans le cas de rgles prdicats binaires sans fonction, lalgorithme est simple et
repose sur un graphe de connexion des variables dans la rgle. Ce graphe reprsente
simplement par un nud chaque variable et par un arc les prdicats (ou un hyper arc
dans le cas de prdicats non binaires). Il est orient pour visualiser les passages
dinformation en chanage arrire. Ce graphe peut tre peru comme une simplification du graphe de propagation dinformation vu ci-dessus.
La gnration dquation fonctionnelle seffectue par un algorithme de cheminement
dans le graphe, chaque arc tant interprt comme une fonction de calcul du nud
cible en fonction du nud source. Cet algorithme dcrit dans [Gardarin86] est appliqu ci-dessous aux cas des anctres et des chefs. Pour simplifier les notations, pour
toute relation binaire R(x,y), R(X) dnote la fonction qui applique {x} sur {y} et
R(Y) celle qui applique {y} sur {x}. Aprs obtention, lquation fonctionnelle au
point fixe est simplement rsolue par application du thorme de Tarski [Tarski55].
Nous illustrons tout dabord la mthode avec le problme des anctres. La
figure XV.30 reprsente les graphes de connexion des variables des rgles :
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y).
PAR
x

PAR
y

ANC

ANC
y

ANC

Figure XV.30 : Graphes de connexion des variables pour les anctres

568 BASES DE DONNES : OBJET ET RELATIONNEL

Lquation fonctionnelle au point fixe rsultante est :

ANC(X) = PAR(X) + ANC(PAR(X)).
En appliquant le thorme de Tarski cette quation, la solution obtenue est :
ANC(X) = PAR(X) + PAR(PAR(X)) +... + PAR(PAR(PAR...(PAR(X))))
qui peut tre traduite directement en algbre relationnelle par un retour aux notations
classiques (nous supposons ici la relation ANC acyclique ; une hypothse contraire
ncessite dlaborer le test darrt). Le programme rsultant (figure XV.31) calcule
ainsi les anctres dun ensemble de personnes X dans ANC.
PROCEDURE CALCUL(ANC,X); {
ANC := ;
DELTA := X;
Tant que DELTA faire {
DELTA := PAR.2(PAR.1DELTA(PAR));
ANC := ANC DELTA;
} ;
};

Figure XV.31 : Calcul des anctres de X

De manire plus gnrale, la mthode sapplique trs simplement aux rgles fortement linaires de la forme :
R(X,Y) B1(X,Y)
R(X,Y) B2(X,X1),R(X1,Y1),B3(Y1,Y)
o B1, B2 et B3 sont des relations de base ou simplement des jointures/restrictions de
relations de base et o X, Y, X1, Y1 reprsentent des variables ou des n-uplets de
variables. Le graphe de connexion des variables de ce type de rgles est reprsent
figure XV.32.
B1
x

B2
y

x1

y1

B3
y

Figure XV.32 : Graphe de connexion des variables de rgles fortement linaires

Lquation fonctionnelle au point fixe est, pour des questions du type ? R(a,Y) :
r(X) = b1(X) + b3(r(b2(X))).
Le thorme de Tarski permet dobtenir la forme gnrale de la solution :
r(X) = b1(X) + b3(b1(b2(X))) +... + b3n(b1(b2n(X))).

Bases de donnes dductives 569

Le calcul de ce polynme est effectu par le programme de lalgbre relationnelle

optimis suivant dont la terminaison suppose lacyclicit des donnes de la relation
B2 (sinon, il faut ajouter une diffrence). Pour obtenir la rponse une question du
type ? R(a,Y), il suffit de remplacer X par a dans le programme de la figure XV.33.
Celui-ci est utilisable quand X est instanci par un ensemble de valeurs.
PROCEDURE CALCUL(R,X); {
i,n : integer;
n:= 0 ;
R := B1.2(B1.1 X(B1));
B2N := X;
Tant que B2N faire {
n := n + 1;
B2N := B2.2(B2.1 B2N(B2));
DELTA := B1.2(B1.1 B2N(B1));
Pour i : = 1 n faire {
DELTA := B3.2(B3.1 B2N(B3));
R := R DELTA;
} ;
} ;
} ;

Figure XV.33 : Calcul des rponses des requtes sur rgles fortement linaires

7.6.2. Les mthodes par comptages

La mthode par comptages a t propose dans [Sacca86]. Elle sapplique aux rgles
fortement linaires de la forme :
R(X,Y) B1(X,Y)
R(X,Y) B2(X,X1),R(X1,Y1),B3(Y1,Y)
o B1, B2 et B3 sont des relations de base ou simplement des jointures et restrictions
de relations de base et o X, Y, X1, Y1 reprsentent des variables ou des n-uplets de
variables. Ce type de rgles assez triviales (mais nest-ce pas le seul type qui corresponde des exemples pratiques ?) a dj t tudi ci-dessus avec la mthode fonctionnelle. partir dune question ? R(a,Y), lide est de rcrire les rgles en ajoutant
des compteurs qui mmorisent la distance parcourue depuis a en nombre dinfrences
vers le haut via B2 et en nombre dinfrence vers le bas via B3. On ne retiendra alors que les tuples obtenus par le mme nombre dinfrences dans les deux sens,
puisque seulement ceux-ci peuvent participer au rsultat (rappelons que le rsultat
scrit en forme fonctionnelle b3n(b1(b2n(a))) : il faut donc effectuer n infrences via
b2, passer par b1 puis effectuer n autres infrences via b3). Le systme de rgles
modifi pour gnrer la rponse devient :
COMPTE(0,a)

570 BASES DE DONNES : OBJET ET RELATIONNEL

COMPTE_B2(J,X), B2(X,X1) COMPTE_B2(J+1,X1)

COMPTE_B2(J, X), B1(X,Y) DECOMPTE_B3(J,Y)
DECOMPTE_B3(J,Y1),B3(Y1,Y) DECOMPTE_B3(J-1,Y)
DECOMPTE_B3(0,Y) R(Y)
Ce programme de rgles compte partir de a en effectuant la fermeture de B2 : il
conserve dans COMPTE_B2 les lments de la fermeture avec leur distance a .
Puis il effectue la jointure avec B1 et commence un dcompte en effectuant la fermeture descendante via B3 partir des lments trouvs. Lorsque le compteur atteint 0,
cest quun tuple rsultat est trouv. La mthode ne fonctionne bien videmment
quen prsence de donnes acycliques. Une extension pour rsoudre le problme des
donnes cycliques consiste borner le compteur, mais ceci seffectue au dtriment des
performances. La mthode est donc assez peu gnrale : il sagit dune criture par
rgles dun algorithme de double fermetures transitives, montante puis descendante,
pour des graphes acycliques. La mthode est certes efficace; de plus, elle peut tre
combine avec les ensembles magiques pour donner des mthodes de type comptage
magique [Sacca86].

7.6.3. Les oprateurs graphes

Une mthode base sur des parcours de graphes est applicable au moins dans le cas
de rgles fortement linaires. Lide est de reprsenter lauto-jointure dune relation
par un graphe qui peut tre construit en mmoire partir de lindex de jointure de la
relation avec elle-mme. Les nuds correspondent aux tuples et les arcs aux infrences (donc aux jointures) possibles entres ces tuples. La rsolution dun systme de
rgles fortement linaires du type vu ci-dessus se rduit alors des parcours de mme
longueur des deux graphes dauto-jointures des relations B2 et B3 en mmoire, en
partant des nuds reprsentant des tuples du type B2(a,y) et en transitant par les
tuples de B1 pour passer de B3 B2. Il est possible de dtecter les cycles par marquage et de faire fonctionner les algorithmes avec des donnes cycliques. En addition,
des calculs de fonctions peuvent tre effectus chaque nud, les graphes tant
valus par les valeurs des tuples. Ceci conduit des mthodes trs efficaces pour traiter des problmes du type plus court chemin ou calcul de prix dans des relations du
type composant-compos.

8. RGLES ET OBJETS
De nombreuses tentatives pour combiner les bases de donnes objet et les rgles ont
t effectues. Citons notamment IQL [Abiteboul90], Logres [Ceri90], Coral

Bases de donnes dductives 571

[Srivastava93]et Rock&Roll [Barja94]. Le sigle DOOD (Deductive Object-Oriented

Databases) a mme t invent et une confrence portant ce sigle est ne. Aucun systme na rellement dbouch sur un produit, lexception sans doute de Validity
[Nicolas97]. Linfrence sur les objets est cependant un problme ancien, dj trait
par les systmes experts au dbut des annes 80, par exemple OPS 5 et NexpertObject.

8.1. LE LANGAGE DE RGLES POUR OBJETS ROL

Afin dillustrer la problmatique, nous introduisons ici le langage ROL (Rule Object
Language) prototyp au laboratoire PriSM au dbut des annes 1990 [Gardarin94].
ROL sappuie sur le modle objet de C++. Un schma de bases de donnes est dfini
par une description dans un langage analogue ODL de lODMG. La figure XV.34
illustre un schma ROL. Celui-ci est directement implment en C++. Pour les calculs
intermdiaires, il est possible de dfinir des classes temporaires par le mot cl TRANSIENT.
CLASS Point { Float Abs ; Float Ord ;} ;
CLASS Personne {String Nom; String Prnom;
LIST<Point> Caricature; };
CLASS Acteur : Personne { Real Salaire;
Real Augmenter (Real Montant) ; };
CLASS Film {Int Numf; String Titre; SET<String> Categories;
Relationship Set<Acteur> Joue ;};
CLASS Domine { Int Numf; Acteur Gagnant; Acteur Perdant; };
TRANSIENT CLASS Calcul { } ;

Figure XV.34 : Exemple de schma ROL

Les rgles en ROL sont organises en modules. Chaque module commence par des
dfinitions de variables valables pour tout le module, de la forme :
VAR <nom> IN <collection>.

Le nom dune variable est gnralement une lettre, alors quune collection est une
extension de classe ou une collection dpendantes, comme en OQL. Il est aussi possible dutiliser des variables symboliques (chanes de caractres), afin damliorer la
clart des programmes. Nous dfinissons simplement les variables :
VAR X IN Film, VAR Y IN X.Categories ;
VAR Z IN Calcul ;

Les rgles sont perues comme des rgles de production de la forme :

IF <condition > THEN <action>.

572 BASES DE DONNES : OBJET ET RELATIONNEL

La condition est analogue une qualification de requtes OQL. Cest une combinaison logique de conditions lmentaires. Une condition lmentaire permet de comparer deux termes. Un terme est une constante, un attribut, une expression de chemin ou
de mthode. Les actions sont :
Des insertion de valeurs. Une valeur ventuellement complexe (tuple par exemple)
est insre dans une collection temporaire ou persistante par la construction +<collection>(<valeurs>).
Des crations dobjets. Un objet est cr dans une collection temporaire ou persistante par la construction +<classe>(<paramtres>). La classe doit tre dfinie auparavant. Laction provoque simplement lappel au constructeur dobjet avec les paramtres indiqus.
Des destruction de valeurs. Une valeur dune collection est dtruite par la
construction <collection>(<valeurs>).
Des destructions dobjets. Un objet est dtruit dans une collection temporaire ou
persistante par la construction <classe>(). La classe doit tre dfinie auparavant.
Laction provoque simplement lappel au destructeur de lobjet avec les paramtres
indiqus sur les objets de la classe slectionns par la condition.
Des appels de mthodes. Toute mthode dfinie au niveau du schma est valide en
partie action prcde de + pour faciliter la lecture des expressions.
Un bloc dactions lmentaires (cration et destruction dobjets et/ou valeurs,
appels de mthodes). Une rgle peut avoir en consquence une suite dactions spares par des + et des . Elle peut donc accomplir des mises jour, des impressions,
etc.
Une smantique ensembliste type point fixe est donne au langage par traduction en
algbre dobjet complexe [Gardarin94]. Les difficults des langages objets est quils
intgrent la fois la cration de nouveaux objets (linvention dobjets daprs
[Abiteboul90]) et les fonctions. De ce fait, il est facile dcrire des programmes infinis
ds quon utilise des rgles rcursives. notre connaissance, aucun compilateur nest
capable de dtecter les programmes non sains.
titre dillustration, nous dfinissons figure XV.35 deux rgles en ROL. La premire
ralise une suite dactions pour tous les films daventure dans lesquels joue Quinn
avec un salaire suprieur 1 000 $ de lheure. La seconde calcule la fermeture transitive de la relation Domine, puis imprime qui fut (transitivement) meilleur que
Marilyn. Il ny a pas de boucle infinie car MEILLEUR est dfini comme un ensemble.
Il nen serait rien avec une liste. Notons aussi que la structure de blocs imbriqus permet de dfinir des ordres de calcul, donc une certaine stratification. De tels langages
sont complexes, mais puissants. Les perspectives dapplications sont importantes
daprs [Nicolas97].

Bases de donnes dductives 573

{ VAR F IN Film, A IN F.Joue, C IN F.Categorie ;

IF A.Name=Quinn AND A.salary1000 AND C=Aventure)
THEN {
+Calcul(F.Titre, F.Categories, A.Salaire)
+F.Categories(cher)
-F.categories(gratuit)
+Print(F.titre, Mon cher Quinn) };
{ TRANSIENT SET Meilleur (Gagnant String, Perdant string);
VAR Domine D, Meilleur B, C ;
{ IF EXISTS(D) THEN +Meilleur(D.Gagnant, D.Perdant);
IF B.Perdant = C.Gagnant THEN
+Meilleur(B.Gagnant, C.Perdant);}
IF B.Perdant.Nom =Marilyn THEN
+Print(B.Gagnant, fut meilleur que, B.Perdant); } ;

Figure XV.35 : Exemples de rgles ROL

8.2. LE LANGAGE DE RGLES POUR OBJETS DEL

DEL est le langage support par le systme Validity, commercialis par la socit
Next Century Media [Next98]. DEL signifie Datalog Extended Language. DEL tend
en effet Datalog avec des objets typs, des prdicats prdfinis (built-in), des quantificateurs et des ordres impratifs. Lensemble est un langage dductif trs puissant, permettant dinfrer sur de grandes bases dobjets.
Le modle de donnes est un modle objet. Les types DEL sont organiss selon une
hirarchie dhritage. Ils sont atomiques ou composites. Les types composites comportent les collections classiques de lobjet (set, bag et list) et les tuples. Les types
atomiques sont les boolens, les littraux numriques (entiers et flottants), les chanes
de caractres et les rfrences aux objets. Il est possible de dfinir des types utilisateurs en tendant la hirarchie.
Les types peuvent tre encapsuls dans des mthodes et fonctions crites dans le langage impratif de DEL, en C ou en C++. Le langage impratif est un langage structur
par blocs, analogue aux langages classiques. Il est possible de calculer des expressions
et deffectuer des contrles. Un ordre foreach est disponible pour parcourir les collections. Une collection peut tre lextension dun prdicat driv par des rgles.
Le langage de rgles permet dcrire des rgles en DATALOG tendu avec des fonctions et des rfrences. Les rgles ne sont pas limites aux clauses de Horn : il est possible dutiliser des connecteurs logiques AND, OR et NOT, et des quantificateurs
EXISTS et FORALL. En outre, le calcul de prdicats est tendu pour manipuler des
identifiants dobjets, des oprations dagrgats et des expressions de chemins limites.
Une tte de rgle est un prdicat driv. DEL supporte les rgles rcursives.

574 BASES DE DONNES : OBJET ET RELATIONNEL

Au-del des corps de rgles, les conditions permettent dexprimer des contraintes
dintgrit et peuvent tre utilises dans les ordres impratifs conditionnels (if et
while). DEL supporte aussi de nombreux prdicats prdfinis appelables depuis les
conditions ou les ordres impratifs. Le temps est galement support sous diffrentes
formes. DEL apparat donc comme un langage trs puissant, capable damliorer la
productivit des dveloppeurs dapplications intelligentes. Limplmentation du systme dductif a t ralise Bull, partir des travaux effectus la fin des annes 80
lECRC Munich. Un grant dobjets spcifique avec des mthodes de reprise et de
gestion des accs concurrents efficaces sert de support au moteur dinfrence qui
applique un driv de la mthode QoSaQ vue ci-dessus.

9. CONCLUSION
Ce chapitre a propos une synthse des recherches et dveloppements en matire de
bases de donnes dductives. Parmi les multiples approches, nous avons surtout
insist sur lintgration dun langage de rgles au sein dun SGBD relationnel tendu.
Cette approche est probablement valable long terme, bien que quelques produits
commencent apparatre. Une approche plus immdiate consiste coupler un interprteur de rgles un SGBD relationnel. De nombreux produits offrent de tels couplages. Ils constituent une approche trs primitive aux bases de donnes dductives.
Plusieurs caractristiques souhaitables dun langage de rgles pour bases de donnes
ont t tudies. La plupart ont t intgres un langage de programmation logique
appel DATALOG, qui a une smantique de type point fixe. Les extensions essentielles de DATALOG ncessaires la programmation sont finalement les fonctions et
les attributs multivalus (ensembles). Lapproche DATALOG est utile pour la comprhension des problmes, mais sans doute difficile utiliser vu sa syntaxe plutt formelle. Un langage plus pratique que DATALOG peut tre driv de SQL, partir des
qualifications de questions et des actions dinsertion et de mise jour. Il sagit essentiellement dun choix de syntaxe. De mme, avec les objets il est possible de driver
un langage de rgles du langage OQL, comme le montre le langage ROL bauch cidessus. DEL est une autre variante plus proche de DATALOG. La puissance de tous
ces langages est rsume figure XV.36.
Le problme de loptimisation des requtes dans un contexte de rgles rcursives est
complexe. Vous pouvez consulter [Ceri91] pour un approfondissement. Loptimisation
en prsence de fonctions et dobjets complexes est encore mal connue. De plus, les
techniques de maintenance de la cohrence des rgles et des donnes sont peine tudies. Finalement, il nexiste encore gure de SGBD dductif fonctionnant avec des
applications en vraie grandeur, sans doute lexception de Validity. Cependant, les

Bases de donnes dductives 575

techniques essentielles pour tendre un SGBD relationnel ou objet avec des rgles
sont connues. Elles ont t prsentes dans ce chapitre.

IQL
ROL
DEL

DATALOGFonc, Neg, Neg

Invention d'objet

Mise jour

DATALOGFonc, Neg

Algbre relationnelle
avec fonctions

Rcursion

Figure XV.36 : Puissance des langages de rgles

10. BIBLIOGRAPHIE
[Abiteboul89] Abiteboul S., Kanellakis P., Object Identity as a Query Language
Primitive , ACM SIGMOD Intl. Conf. on Management of Data, p. 159-173,
1989.
Une prsentation des fondements du langage IQL, un langage de rgles
capable de crer de nouveaux objets. IQL utilise des identifiants dobjets pour
reprsenter des structures de donnes partages avec de possibles cycles, pour
manipuler les ensembles et pour exprimer toute question calculable. IQL est un
langage typ capable dtre tendu pour supporter des hirarchies de types.
[Abiteboul90] Abiteboul S., Towards a Deductive Object-Oriented Database
Language , Data and Knowledge Engineering, vol. 5, n 2, p. 263-287, 1990.
Une extension dIQL vers un langage plus praticable. Un langage de rgles
pour objets complexes est prsent, incluant toutes les extensions de Datalog,
linvention dobjets, lappel de mthodes et la construction de fonctions drives.
[Abiteboul91] Abiteboul S., Simon E., Fundamental Properties of Deterministic and
Nondeterministic Extensions of Datalog , Theoretical Computer Science,
n 78, p. 137-158, 1991.

576 BASES DE DONNES : OBJET ET RELATIONNEL

Une tude des diffrentes extensions de Datalog avec ngations et mises jour.
La puissance des diffrents langages obtenus est caractrise en termes de
complexit.
[Abiteboul95] Abiteboul S., Hull R., Vianu V., Foundations of Databases, AddisonWesley Pub. Comp., Reading, Mass, USA, 1995.
Ce livre prsente les fondements thoriques des bases de donnes. Une large
place est donne Datalog et ses extensions, ainsi qu la smantique de tels
langages.
[Aho79] Aho A.V., Ullman J.D., Universality of data retrieval languages , Conf.
POPL, San-Antonio, Texas, 1979.
Cet article est lun des premiers souligner lincapacit des langages dinterrogation de bases de donnes supporter la rcursion. La notion de plus petit
point fixe dune quation de lalgbre est notamment introduite.
[Aiken92] Aiken A., Widom J., Hellerstein J., Behavior of Database Production
Rules: Termination, Confluence, and Observable Determinism , ACM SIGMOD Int. Conf. on Management of Data, San Diego, Calif., 1992.
Des mthodes danalyse statiques dun programme de rgles sont prsentes
pour dterminer si un ensemble de rgles de production rfrenant une base
de donnes : (1) se terminent ; (2) produisent un tat base de donnes unique ;
(3) produisent une chane dactions observables unique.
[Apt86] Apt C., Blair H., Walker A., Towards a theory of declarative knowledge ,
Foundations of Deductive Databases and Logic Programming, Minker J. Ed.,
Morgan Kaufmann, Los Altos, 1987, aussi IBM Research Report RC 11681,
avril 1986.
Une tude sur les points fixes minimaux et la stratification. Il est montr quun
programme avec ngation plusieurs points fixes minimaux et que la stratification consiste choisir le plus naturel.
[Bancilhon86a] Bancilhon F., Maier D., Sagiv Y., Ullman J.D., Magic sets and other
strange ways to implement logic programs , 5 th ACM Symposium on
Principles of Database Systems, Cambridge, USA, 1986.
Cet article expose la mthode des ensembles magiques pour effectuer les restrictions avant la rcursion lors de lvaluation de questions dductives.
Comme la mthode dAlexandre, les ensembles magiques rcrivent les rgles
en simulant un chanage arrire partir de la question. Une valuation en
chanage avant permet alors de ne sintresser quaux seuls faits capables de
gnrer des rponses (les faits relevants).
[Bancilhon86b] Bancilhon F., Ramakrishnan R., An Amateurs Introduction to
Recursive Query Processing Strategies , ACM SIGMOD Intl. Conf. on
Management of Data, Washington D.C., mai 1986.

Bases de donnes dductives 577

Une vue densemble des mthodes dvaluation de rgles rcursives proposes

en 1986. Les mthodes Query-Subquery et Magic Set sont particulirement bien
dcrites.
[Barja94] Barja L. M., Paton N. W., Fernandes A.A., Williams H.M., Dinn A., An
Effective Deductive Object-Oriented Database Through Language
Integration , 20th Very Large Data Bases International Conference, Morgan
Kaufman Pub., Santiago, Chile, p. 463-474, aot 1994.
Cet article dcrit une approche au dveloppement dun SGBD objet dductif
(DOOD) ralise lUniversit dEdinburgh. Le prototype comporte notamment un composant ROCK & ROLL constitu du modle dobjets, dun langage
impratif et dun langage de type DATALOG associs.
[Beeri86] Beeri C. et. al. Sets and negation in a logical database language (LDL1) ,
Proc. of ACM PODS, 1987; aussi MCC Technical Report, novembre 1986.
Lauteur discute de lintroduction des ensembles et de la ngation dans le langage LDL1. Il montre que les deux fonctionnalits ncessitent la stratification.
De nombreux exemples sont proposs.
[Beeri87] Beeri C., Ramakrishnan R., On the Power of Magic , ACM PODS 1987,
aussi Technical Report DB-061-86, MCC.
Cet article dveloppe diffrentes variantes de la mthode des ensembles
magiques pour optimiser les rgles rcursives. Il montre quune extension plus
performante de cette mthode est identique la mthode dAlexandre pralablement propose par J.M. Kerisit [Rohmer86].
[Bidoit91] Bidoit N., Negation in Rule-Based Database Languages : A Survey ,
Theoretical Computer Science, n 78, p. 1-37, 1991.
Une vue densemble de la ngation en Datalog et des diverses smantiques
possibles.
[Ceri90] Ceri S., Widom J., Deriving Production Rules for Constraint
Maintenance , 16th Very Large Data Bases International Conference, Morgan
Kaufman Pub., Brisbane, Australie, aot 1990.
Un ensemble de mthodes diffrentielles pour gnrer des triggers afin de
maintenir des contraintes dintgrit dans une base de donnes relationnelle.
Un article similaire a t publi par les mmes auteurs au VLDB 91 afin de
maintenir cette fois des vues concrtes.
[Ceri91] Ceri S., Gottlob G., Tanca L., Logic Programming and Databases, Surveys
in Computer Sciences, Springer Verlag, 1990.
Un livre fondamental sur le modle logique. Il introduit Prolog comme un langage dinterrogation de donnes, les bases de donnes relationnelles vues dun
point de vue logique, et enfin les couplages de Prolog et des bases de donnes.
Dans la deuxime partie, Datalog et ses fondements sont prsents. La troi-

578 BASES DE DONNES : OBJET ET RELATIONNEL

sime partie est consacre aux techniques doptimisation de Datalog et un

survol des prototypes implmentant ces techniques.
[Chang86] Chang C. L., Walker A., PROSQL: A Prolog Programming Interface
with SQL/DS , 1st Int. Workshop on Expert Database Systems, Benjamin/
Cummings Pub., L. Kerschberg Ed., 1986.
La description dune intgration de SQL Prolog. Un prototype a t ralis
IBM selon ces principes permettant daccder DB2 depuis Prolog.
[Clark78] Clark C. Negation as failure Logic and databases, dit par Gallaire et
Minker, Plenum Press, New York, 1978.
Un article de base sur la ngation en programmation logique. Il est propos
daffirmer quun fait est faux sil ne peut tre dmontr vrai (ngation par
chec). Cela conduit interprter les rgles comme des quivalences : si
peut tre lu comme si et seulement si condition de collecter toutes les
rgles menant un mme but comme une seule.
[Clocksin81] Clocksin W.F., Mellish C.S., Programming in Prolog, Springer Verlag,
Berlin-Heidelberg-New York, 1981.
Un livre de base sur le langage Prolog.
[Gallaire78] Gallaire H., Minker J., Logic and Databases, Plenum Press, 1978.
Le premier livre de base sur la logique et les bases de donnes. Il sagit dune
collection darticles prsents Toulouse lors dun premier workshop tenu en
1977 sur le sujet.
[Gallaire81] Gallaire H., Minker J., Nicolas J.M., Advances in database theory, vol. 1,
Plenum Press, 1981.
Le second livre de base sur la logique et les bases de donnes. Il sagit dune
collection darticles prsents Toulouse lors dun second workshop tenu en
1979 sur le sujet.
[Gallaire84] Gallaire H., Minker J., Nicolas J.M., Logic and databases: a deductive
approach , ACM Computing Surveys, vol. 16, n 2, juin 1984.
Un tat de lart sur les bases de donnes et la logique. Diffrents types de
clauses (fait positif ou ngatif, contrainte dintgrit, loi dductive) sont isols.
Linterprtation des bases de donnes comme un modle ou comme une thorie
de la logique est discute. Les diffrentes variantes de lhypothse du monde
ferm sont rsumes.
[Gardarin85] Gardarin G., De Maindreville C., Simon E., Extending a Relational
DBMS towards a Rule Base Systems : A PrTN based Approach , CRETE
WORKSHOP on AI and DB, June 1985, THANOS and SCHMIDT Ed., aussi
dans Database and Artificial Intelligence, Springer Verlag Ed, 1989.
Cet article prsente les premires ides qui ont permis de dvelopper le langage RDL1 lINRIA. Citons comme apports importants lintroduction des

Bases de donnes dductives 579

mises jour en ttes de rgles avec lexemple du circuit lectrique et la modlisation du processus dvaluation de questions par les rseaux de Petri prdicats. Les principales techniques doptimisation de rseaux par remonte des
slections sont dcrites.
[Gardarin86] Gardarin G., de Maindreville C., Evaluation of Database Recursive
Logic Programs as Recurrent Function Series , ACM SIGMOD Intl. Conf. on
Management of Data, Washington D.C., May 1986.
Cet article introduit lapproche fonctionnelle dcrite ci-dessus. La rcriture est
base sur des graphes de connexion de variables.
[Gardarin87] Gardarin G., Magic functions : A technique for Optimization of
Extended Datalog Recursive Programs , Intl. Conf. on Very Large Data Bases,
Brighton, England, septembre 1987.
Cet article propose une deuxime version de lapproche fonctionnelle plus
gnrale. Une question et les rgles associes sont rcrites en systmes
dquations fonctionnelles. Le systme est alors optimis puis valu sur la
base de donnes. La technique est particulirement adapte aux rgles rcursives.
[Gardarin94] Gardarin G., Object-Oriented Rule Language and Optimization
Techniques , Advances in Object-Oriented Systems, Springer Verlag,
Computer and Systems Sciences Series, vol. 130, p. 225-249, 1994.
Cet article compare les diffrents langage de rgles et introduit le langage ROL
pour BD objet de type C++ persistant.
[Hanson92] Hanson E., Rule Condition Testing and Action Execution in Ariel ,
ACM SIGMOD Int. Conf. on Management of Data, San Diego, Calif., 1992.
Cet article dcrit les tests des conditions des rgles et lexcution des actions
dans le SGBD actif Ariel. Pour tester les conditions, Ariel utilise un rseau de
discrimination maintenu en mmoire proche du rseau Rete, bien connu dans
les systmes de production en intelligence artificielle. Ce rseau est une version
modifie du rseau Treat qui vite de maintenir les donnes correspondant
certaines jointures.
[Hayes-Roth85] Hayes-Roth F., Rule Based systems , Communications of the
ACM, vol. 28, n 9, septembre 1985.
Une introduction aux systmes de rgles de production et leurs applications.
[Kiernan90] Kiernan J., de Maindreville C., Simon E., Making Deductive Database
a Practical Technology: A Step Forward , ACM SIGMOD Intl. Conf. on
Management of Data, Atlantic City, juin 1990.
Une prsentation du langage RDL1 et de son implmentation. Le langage
RDL1 supporte toutes les extensions de Datalog vues dans ce chapitre avec une
syntaxe plus proche du calcul relationnel de tuples. De plus, il possde une par-

580 BASES DE DONNES : OBJET ET RELATIONNEL

tie contrle permettant de spcifier les priorits dexcution des rgles. RDL1 a
t implant lINRIA laide de rseaux de Petri prdicats tendus rsultant de la compilation des rgles. Ces rseaux sont interprts sur la couche
basse du systme SABRINA qui offre une interface proche dune algbre relationnelle tendue avec des types abstraits.
[Kifer87] Kifer M., Lozinskii E., Implementing Logic Programs as a Database
System , IEEE Intl. Conf. on Data Engineering, Los Angeles, 1987.
Une prsentation dun prototype supportant Datalog. Lide essentielle de cet
article est de compiler un programme logique en un rseau de transitions (le
system graph ) reprsentant les rgles. Le rseau peut alors tre optimis
par des techniques de gnration de sous-questions.
[Kifer89] Kifer M., Lausen G., F-Logic : A Higher-Order Language for Reasoning
about Objects, Inheritance and Schema , ACM SIGMOD Intl. Conf. on
Management of Data, Portland, 1989.
Une logique pour objets complexes. Cet article dfinit un langage de rgles
supportant hritage, mthodes et objets complexes. Une mthode de rsolution
tendue est propose pour dmontrer un thorme dans un tel contexte.
[Kuper86] Kuper G., Logic programming with sets , Proc. ACM PODS, 1987.
Cet article discute du support des ensembles en programmation logique.
[Lloyd87] Lloyd J., Foundations of logic programming, 2e dition, Springer Verlag, 1987.
Le livre de base sur les fondements de la programmation logique. Les diffrentes smantiques dun programme logique sont introduites. Les techniques de
preuve de type rsolution avec ngation par chec sont dveloppes.
[McKay81] MacKay D., Shapiro S., Using active connection graphs for reasoning
with recursive rules , Proc. Intl. Conf. on Artificial Intelligence IJCAI, 1981.
Cet article introduit les PCG comme support danalyses de rgles et mthodes
de preuves.
[Minker82] Minker J., Nicolas J.M., On Recursive Axioms in Deductive
Databases , Information Systems Journal Vol.8, n 1, p. 1-13, Jan. 1982.
Un des premiers articles sur le problme des rgles rcursives.
[Naqvi89] Naqvi S., Tsur S., A Logical Language for Data and Knowledge Bases ,
Principles of Computer Science, Computer Science Press, New York, 1989.
Ce livre dcrit le langage LDL. LDL est un langage driv de Prolog pour
manipuler les bases de donnes relationnelles supportant des objets complexes
(ensembles). Il est assez proche de Datalog tendu avec la ngation, des mises
jour et des ensembles. Une version oprationnelle a t dveloppe MCC et
distribue dans les universits amricaines. Le livre est illustr de nombreux
exemples.

Bases de donnes dductives 581

[Next98] Next Century Media, Validity Database System, DEL Language Reference
Manual, Next Century Media Inc., Versailles, France
Ce document prsente le langage DEL du SGBD dductif (DOOD) Validity,
commercialis par Next Century Media, une start-up issue du groupe Bull.
[Nicolas97] Nicolas J-M., Deductive Object Oriented Databases Technology,
Products and Applications : Where are we ? , Intl. Symp. On Digital Media
Information Base DBIM97, Nara, Japan, Nov. 1997.
Cet article donne une vue quelque peu optimiste du pass, du prsent et du
futur des bases de donnes dductives. Il est crit par le prsident de Next century Media.
[Nilsson80] Nilsson N., Principles of Artificial Intelligence, Tioga Publication, 1980.
Un des livres de base sur lintelligence artificielle. Les systmes de rgles de
production pertinents aux bases de donnes dductives sont particulirement
dvelopps.
[Przymusinski88] Przymusinski T., On the declarative semantics of stratified deductive databases and logic programs , in Foundations of Deductive Databases
and Logic Programming, Morgan & Kaufmann, Los Altos, 1988.
Une discussion de la smantique des programmes de rgles stratifis. La
smantique inflationniste o toutes les rgles sont dclenches en parallle est
notamment introduite.
[Ramakrishnan95] Ramakrishnan R., Ullman J.D., A Survey of Deductive Database
Systems , Journal of Logic Programming, vol. 23, n 2, Elsevier Science Pub.
Comp., New York, 1995.
Une vue densemble rcente des bases de donnes dductives et de leurs
apports et perspectives thoriques.
[Reiter78] Reiter R., On closed world data bases , in Logic and databases, dit
par Gallaire et Minker, Plenum Press, New York, 1978.
Larticle de base sur lhypothse du monde ferm.
[Reiter84] Reiter R., Towards a Logical Reconstruction of Relational Database
Theory , in On Conceptual Modelling, p. 191-234, Springer Verlag, 1984.
Une redfinition des bases de donnes relationnelles en logique. Les diffrents
axiomes ncessaires linterprtation dune base de donnes comme une thorie en logique sont prsents : fermeture des domaines, unicit des noms,
axiomes dgalit, etc. Les calculs relationnels sont unifis et gnraliss.
[Rohmer86] Rohmer J., Lescur R., Kerisit J.M., The Alexander Method A
Technique for the Processing of Recursive Axioms in Deductive Databases ,
New Generation Computing, n 4, p. 273-285, Springer-Verlag, 1986.
Les auteurs introduisent la mthode dAlexandre, premire mthode propose
ds 1985 lors du stage de J.M. Kerisit pour transformer les rgles rcursives en

582 BASES DE DONNES : OBJET ET RELATIONNEL

rgles de production appliques aux seuls faits relevants. Cette mthode est trs
proche de la mthode des ensembles magiques propose un peu plus tard par
Bancilhon et Ullman.
[Sacca86] Sacca D., Zaniolo C., Magic Counting Methods , MCC Technical Report
DB-401-86, Dec. 1986.
Cet article dcrit la mthode de comptage tudie ci-dessus pour optimiser les
rgles rcursives.
[Simon92] Simon E., Kiernan J., de Maindreville C., Implementing High Level
Active Rules on top of Relational DBMS , Proc. of the 18th Very Large Data
Bases Int. Conf., Morgan Kaufman, Vancouver, Canada, 1992.
Cet article prsente le langage de dfinition de dclancheurs driv du langage
de rgle RDL1. Les rgles deviennent actives du fait quelles sont dclenches
suite des vnements (par exemple des mises jour). Elles sont dfinies dans
un langage de haut niveau avec une smantique de point fixe. Un grant dvnements implment au-dessus du SGBD SABRINA dclenche lvaluation des
rgles.
[Srivastava93] Srivastava D., Ramakrishnan, Seshadri P., Sudarshan S., Coral++ :
Adding Object-Orientation to a Logic Database Language , Proc. of the
19th Very Large Data Bases Int. Conf., Morgan Kaufman, p. 158-170, Dublin,
Ireland, 1993.
Cet article prsente le langage de rgles CORAL, extension de Datalog avec
des concepts objet. Le modle objet de CORAL est inspir de C++. Les
mthodes sont crites en C++. CORAL est compil en C++. Ce langage a t
ralis luniversit du Maddisson aux USA.
[Stonebraker86] Stonebraker M., Rowe A.L., The Postgres Papers , UC Berkeley,
ERL M86/85, BERKELEY, novembre 1986.
Une collection darticles sur POSTGRES. Ce systme supporte la dfinition de
rgles exploites lors des mises jour. Les rgles sont donc utilises pour dfinir des dclencheurs. Elles permettent de rfrencer des objets complexes dfinis sous forme de types abstraits de donnes. Elles se comportent comme des
rgles de production de syntaxe if <opration> on <relation> then <oprations>. Les oprations incluent bien sr des mises jour. Un systme de priorit est propos pour rgler les conflits en cas de rgles simultanment dclenchables. Ce mcanisme de rgles est aujourdhui commercialis au sein du
SGBD INGRES.
[Tarski55] Tarski A., A lattice theoretical fixpoint theorem and its applications ,
Pacific journal of mathematics, n 5, p. 285-309, 1955.
Larticle de base sur la thorie du point fixe. Il est notamment dmontr que
toute quation au point fixe construite avec des oprations monotones sur un

Bases de donnes dductives 583

treillis a une plus petite solution unique. Ce thorme peut tre appliqu pour
dmontrer que lquation au point fixe R = F(R) sur le treillis des relations, o
F est une expression de lalgbre relationnelle sans diffrence, a un plus petit
point fixe.
[Tsur86] Tsur D., Zaniolo C., LDL: a Logic-Based Data Language , Very Large
Databases Int. Conf., Kyoto, Japon, septembre 1986.
Une prsentation synthtique du langage LDL1 implment MCC. Cet article
insiste notamment sur le support de la ngation, des ensembles et des fonctions
externes.
[Ullman85] Ullman J.D., Implementation of logical query languages for
Databases , ACM SIGMOD Intl. Conf. on Management of Data, aussi dans
ACM TODS, vol. 10, N. 3, p. 289-321, 1986.
Une description des premires techniques doptimisation de programmes
Datalog. Le passage dinformations de ct est notamment introduit pour
remonter les constantes dans les programmes Datalog, y compris les programmes rcursifs.
[VanEmden76] Van Emden M., Kowalski R., The semantics of predicate logic as a
programming language , Journal of the ACM Vol.23, n 4, octobre 1976.
Une premire tude sur la smantique du point fixe, dveloppe dans le
contexte de la programmation logique. Plus tard, cette approche a t retenue
pour dfinir la smantique de Datalog.
[Vieille86] Vieille L., Recursive axioms in deductive databases : the query subquery approach , Proc. First Intl. Conference on Expert Database Systems,
Charleston, 1986.
Cet article dcrit la mthode QSQ, dont lextension QoSaQ a t implment
dans le prototype EKS lECRC entre 1986 et 1990. Ce prototype a t ensuite
repris pour donner naissance au produit Validity, un des rares DOOD.
[Zaniolo85] Zaniolo C., The representation and deductive retrieval of complex
objects , 11th Int Conf. on Very Large Data Bases, aot 1985.
Une extension de lalgbre relationnelle au support de fonctions. Cet article
prsente une extension de lalgbre relationnelle permettant de rfrencer des
fonctions symboliques dans les critres de projection et de slection, afin de
manipuler des objets complexes. Des oprateurs dductifs de type fermeture
transitive tendue sont aussi intgrs.
[Zaniolo86] Zaniolo C., Safety and compilation of non recursive horn clauses ,
MCC Tech. Report DB-088-85, 1986.
Une discussion des conditions assurant la finitude des prdicats gnrs par
des clauses de Horn et des questions poses sur ces prdicats.

Chapitre XVI

GESTION DE TRANSACTIONS
1. INTRODUCTION
En bases de donnes, le concept de transaction a t introduit depuis prs de trente ans
[Bjork72]. Ce concept est aussi dactualit dans les systmes dexploitation. Dans ce
chapitre, nous tudions les problmes lis la gestion de transactions dans les systmes de bases de donnes. Le concept de transaction est fondamental pour maintenir
la cohrence des donnes. Une transaction est une unit de mise jour compose de
plusieurs oprations successives qui doivent tre toutes excutes ou pas du tout. En
gestion, les transactions sont courtes (quelques secondes). En conception, elles peuvent tre beaucoup plus longues (quelques minutes voire quelques heures). Le SGBD
doit garantir les fameuses proprits ACID des transactions. Outre latomicit mentionne, les transactions effectuent des accs concurrents aux donnes qui doivent tre
contrls afin dviter les conflits entre lecteurs et crivains. Cela ncessite disoler
les mises jour dont les effets doivent par ailleurs tre durables. En consquence, la
gestion de transactions mlange intimement les problmes de fiabilit et de reprise
aprs panne avec les problmes de concurrence daccs. Les problmes de scurit
qui recouvrent la confidentialit sont aussi connexes.
Ce chapitre essaie de faire le point sur tous les aspects de la gestion de transactions
dans les SGBD centraliss. Aprs quelques rappels de base, nous traitons dabord les
problmes de concurrence. Nous introduisons la thorie de la concurrence, qui
sappuie sur le concept de srialisation, conduisant naccepter que les excutions
simultanes de transactions produisant les mmes rsultats quune excution squen-

586 BASES DE DONNES : OBJET ET RELATIONNEL

tielle des transactions, cest--dire lune aprs lautre. Nous exposons la technique de
verrouillage qui est une mthode prventive de conflits plutt pessimiste. Bien
quentranant des difficults telles que le verrou mortel, cette mthode est de loin la
plus applique. Cependant, nous analysons aussi les mthodes optimistes qui laissent
les conflits se produire et les corrigent aprs, telles que lordonnancement par estampille, la certification et les contrles avec versions multiples.
Nous tudions ensuite les principes de la gestion de transactions. Tout repose sur les
algorithmes de validation et de reprise aprs panne. Nous approfondissons les outils
ncessaires ces algorithmes puis les diffrents algorithmes de validation et de
reprise, en incluant la validation en deux tapes, gnralement applique mme dans
les systmes centraliss. Comme exemple de mthode de reprise intgre, nous dcrivons la mthode ARIES implmente IBM, la rfrence en matire de reprise. Nous
terminons la partie sur les transactions proprement dites en prsentant les principaux
modles de transactions tendus introduits dans la littrature. Ces modles sont destins permettre un meilleur support des transactions longues, en particulier pour les
applications de conception qui ncessitent de longs travaux sur des objets complexes.
Ces modles sophistiqus commencent tre introduits dans les SGBD, notamment
dans les SGBD objet ou objet-relationnel.
Pour terminer ce chapitre, nous traitons du problme un peu orthogonal de confidentialit. Beaucoup peut tre dit sur la confidentialit. Nous rsumons lessentiel des
mthodes DAC (Discretionary Access Control) et MAC (Mandatory Access Control).
La premire permet dattribuer des autorisations aux utilisateurs et de les contrler, la
seconde fonctionne avec des niveaux de confidentialit. Nous concluons par quelques
mots sur le cryptage des donnes.

2. NOTION DE TRANSACTION
Un modle simplifi de SGBD se compose de programmes utilisateurs, dun systme
et de mmoires secondaires. Les programmes accdent aux donnes au moyen doprations du SGBD (Select, Insert, Update, Delete), gnralement en SQL. Ces oprations dclenchent des actions de lecture et criture sur disques (Read, Write), qui sont
excutes par le systme, et qui conduisent des entres-sorties sur les mmoires
secondaires. Afin de pouvoir dterminer les parties de programmes correctement excutes, le concept de transaction a t propos depuis longtemps.

2.1. EXEMPLE DE TRANSACTION

Les oprations classiques ralises par une transaction sont les mises jour ponctuelles de lignes par des crans prdfinis. Les transactions sont souvent rptitives.

Gestion de transactions 587

Elles sappliquent toujours sur les donnes les plus rcentes. Un exemple typique de
transaction est fourni par le banc dessais TPC A [Gray91]. Il sagit de raliser le
dbit/crdit sur une base de donnes bancaire. Le benchmark a pour objectif la mesure
des performances du SGBD en nombre de transactions excutes par seconde.
La base se compose des tables Agences, Comptes, Caissiers et Historique (voir
figure XVI.1). Une agence gre 100 000 comptes, possde 100 caissiers et comporte
un systme avec 10 terminaux.
1

100000

Agences

Comptes

Caissiers

Historique

100
Taille pour 10 terminaux, avec rgle d'chelle (scaling rule)

Figure XVI.1 : Schma de la base TPC A

Le code de la transaction TPC A apparat figure XVI.2. Il ralise le crdit ou le dbit

dun compte dun montant Delta et rpercute cette mise jour dans les autres tables.
On voit quil sagit bien dun groupe de mises jour ponctuelles mais lies. Le benchmark suppose que chaque terminal lance lexcution dune transaction toute les
10 secondes. 90 % des transactions doivent avoir un temps de rponse infrieur
2 secondes.
Begin-Transaction
Update Account Set Balance = Balance + Delta
Where AccountId = Aid ;
Insert into History (Aid, Tid, Bid, Delta, TimeStamp) ;
Update Teller Set Balance = Balance + Delta
Where TellerId = Tid ;
Update Branch Set Balance = Balance + Delta
Where TellerId = Tid ;
End-Transaction.

Figure XVI.2 : La transaction TPC

La performance est obtenue en divisant le nombre de transactions excutes par le

temps dexcution moyen. On obtient ainsi un nombre de transactions par seconde.

588 BASES DE DONNES : OBJET ET RELATIONNEL

Ces vingt dernires annes, lobjectif de tous les SGBD a t dexcuter un maximum
de telles transactions par seconde.
En pratique, les transactions doivent souvent cohabiter avec des requtes dcisionnelles, traitant un grand nombre de tuples en lecture, souvent pour calculer des agrgats. Par exemple, une requte dcisionnelle pourra calculer la moyenne des avoir des
comptes par agence comme suit :
SELECT B.BRANCHID, AVG(C.BALANCE)
FROM BRANCH B, ACCOUNT C
WHERE B.BRACHID = C.BRANCHID
GROUP BY B.BRANCHID ;

Une telle requte parcourt tous les comptes et peut en consquence empcher les transactions dbit/crdit de sexcuter. Elle peut aussi tre bloque par les transactions
dbit/crdit. Nous allons tudier les solutions aux problmes des transactions ci-dessous.

2.2. PROPRIT DES TRANSACTIONS

Une transaction est donc compose dune suite de requtes dpendantes la base qui
doivent vrifier les proprits datomicit, de cohrence, disolation et de durabilit,
rsumes par le vocable ACID.
Notion XVI.1 : Transaction (Transaction)
Squence doprations lies comportant des mises jour ponctuelles dune base de donnes
devant vrifier les proprits datomicit, cohrence, isolation et durabilit (ACID).

Nous analysons brivement les proprits ACID ci-dessous.

2.2.1. Atomicit
Une transaction doit effectuer toutes ses mises jour ou ne rien faire du tout. En cas
dchec, le systme doit annuler toutes les modifications quelle a engages. Latomicit est menace par les pannes de programme, du systme ou du matriel, et plus
gnralement par tout vnement susceptible dinterrompre une transaction en cours.

2.2.2. Cohrence
La transaction doit faire passer la base de donnes dun tat cohrent un autre. En
cas dchec, ltat cohrent initial doit tre restaur. La cohrence de la base peut tre
viole par un programme erron ou un conflit daccs concurrent entre transactions.

Gestion de transactions 589

2.2.3. Isolation
Les rsultats dune transaction ne doivent tre visibles aux autres transactions quune
fois la transaction valide, afin dviter les interfrences avec les autres transactions.
Les accs concurrents peuvent mettre en question lisolation.

2.2.4. Durabilit
Ds quune transaction valide ses modifications, le systme doit garantir quelles
seront conserves en cas de panne. Le problme essentiel survient en cas de panne,
notamment lors des pannes disques.
Ces proprits doivent tre garanties dans le cadre dun systme SGBD centralis,
mais aussi dans les systmes rpartis. Elles ncessitent deux types de contrle, qui
sont intgrs dans un SGBD : contrle de concurrence, rsistance aux pannes avec
validation et reprise. Nous allons les tudier successivement, puis nous tudierons la
mthode intgre ARIES qui est une des plus efficaces parmi celles implmentes
dans les SGBD.

3. THORIE DE LA CONCURRENCE
Cette section aborde les problmes de gestion des accs concurrents. Les solutions
proposes permettent de garantir la cohrence et lisolation des mises jour des transactions (le C et le I de ACID). Elles sont bases sur la thorie de la srialisabilit des
transactions, que nous examinons maintenant.

3.1. OBJECTIFS
Lobjectif gnral est de rendre invisible aux clients le partage simultan des donnes.
Cette transparence ncessite des contrles des accs concurrents au sein du SGBD.
Ceux-ci seffectuent au moyen de protocoles spciaux permettant de synchroniser les
mises jour afin dviter les pertes de mises jour et lapparitions dincohrences.
Une perte de mise jour survient lorsquune transaction T1 excute une mise jour
calcule partir dune valeur prime de donne, cest--dire dune valeur modifie
par une autre transaction T2 depuis la lecture par la transaction T1. La mise jour de
T2 est donc crase par celle de T1. Une perte de mise jour est illustre
figure XVI.3. La mise jour de la transaction T2 est perdue.

590 BASES DE DONNES : OBJET ET RELATIONNEL

T1 : Read A->a;
T2 : Read A->b;
T2 : b+1 -> b;
T2 : Write b->A;
T1: a*2 ->a;
T1: Write a -> A;

temps

Figure XVI.3 : Exemple de perte de mise jour

Une incohrence apparat lorsque des donnes lies par une contrainte dintgrit
sont mises jour par deux transactions dans des ordres diffrents, de sorte
enfreindre la contrainte. Par exemple, soient deux donnes A et B devant rester
gales. Lexcution de la squence doprations {T1 : A = A+1 ; T2 : B = B*2 ; T2 :
A = A*2; T1: B=B+1} rend en gnral A diffrent de B, du fait de la non-commutativit de laddition et de la multiplication. Elle provoque donc lapparition dune incohrence. Cette situation est illustre figure XVI.4.
A=B
T1 : A*2->A;
T2 : A+1->A;
T2 : B+1 -> B;
T1 : B*2 -> B;

temps

Figure XVI.4 : Exemple dintroduction dincohrence

Un autre problme li aux accs concurrents est la non-reproductibilit des lectures : deux lectures dune mme donne dans une mme transaction peuvent
conduire des valeurs diffrentes si la donne est modifie par une autre transaction
entre les deux lectures (voir figure XVI.5). Le problme ne survient pas si les mises
jour sont isoles, cest--dire non visibles par une autre transaction avant la fin de la
transaction. Il en va de mme de lapparition dincohrences. Pour les pertes de mise

Gestion de transactions 591

jour, lisolation des mises jour nest pas suffisante : il faut aussi ne pas laisser deux
transactions modifier simultanment une mme donne.
T1 : Read A->a;
T2 : Read A->b;
T2 : b+1 -> b;
T2 : Write b->A;
T1: Read A -> a

temps

Figure XVI.5 : Exemple de non-reproductibilit des lectures

La rsolution dans un systme des problmes voqus ncessite la mise en place

dalgorithmes de contrle de concurrence spcialiss. Ces algorithmes sappuient sur
la thorie de la concurrence, que nous examinons ci-dessous.

3.2. QUELQUES DFINITIONS DE BASE

Pour viter perte doprations, incohrences et non reproductibilit des lectures, le
SGBD doit contrler laccs aux donnes. Lunit de donnes contrle dpend du
SGBD. De plus en plus de SGBD permettent des contrles variables selon le type de
transactions. Nous appellerons cette unit granule de concurrence ; le terme objet est
parfois aussi employ.
Notion XVI.2 : Granule de concurrence (Concurrency granule)
Unit de donnes dont les accs sont contrls individuellement par le SGBD.

Un granule au sens de la concurrence peut tre une ligne, une page ou une table dans
un systme relationnel. Ce peut tre un objet ou une page dans un SGBD objet. Nous
discuterons de la taille du granule de concurrence plus loin.
Les granules de concurrence sont lus et crits par les utilisateurs, ventuellement par
parties. On appelle action un accs lmentaire un granule.
Notion XVI.3 : Action (Action)
Unit indivisible excute par le SGBD sur un granule pour un utilisateur, constitue gnralement
par une lecture ou une criture.

592 BASES DE DONNES : OBJET ET RELATIONNEL

Un systme de bases de donnes excute donc une suite dactions rsultant de transactions concurrentes. Aprs compltude dun ensemble de transactions (T1, T2Tn),
une histoire du systme peut tre reprsente par la suite des actions excutes. Plus
gnralement, toute suite dactions pouvant reprsenter une histoire possible sera
appele simplement excution.
Notion XVI.4 : Excution de transactions (Schedule, ou Log, ou History)
Squence dactions obtenues en intercalant les diverses actions des transactions T1, T2 Tn tout en
respectant lordre interne des actions de chaque transaction.

Une excution respecte donc lordre des actions de chaque transaction participante et
est, par dfinition, squentielle. Par exemple, considrons les transactions T1 et T2
figure XVI.6, modifiant les donnes A et B relies par la contrainte dintgrit A = B ;
A et B appartiennent deux granules distincts, maximisant ainsi les possibilits de
concurrence. Une excution correcte de ces deux transactions est reprsente
figure XVI.7 (a). Une autre excution est reprsente figure XVI.7 (b), mais celle-l
est inacceptable car elle conduit une perte doprations.
T1
Read A a1
a1+1 a1
Write a1 A
Read B b1
b1+1 b1
Write b1 B

T2
Read A a2
a2*2 a2
Write a2 A
Read B b2
b2*2 b2
Write b2 B

Figure XVI.6 : Deux transactions T1 et T2

T1 :
T1 :
T1 :
T2 :
T2 :
T2 :
T1 :
T1 :
T1 :
T2 :
T2 :
T2 :
(a)

Read A a1
a1+1 a1
Write a1 A
Read A a2
a2*2 a2
Write a2 A
Read B b1
b1+1 b1
Write b1 B
Read B b2
b2*2 b2
Write b2 B

T2 :
T2 :
T1 :
T1 :
T2 :
T2 :
T2 :
T1 :
T1 :
T1 :
T1 :
T2 :
(b)

Read A a2
a2*2 a2
Read A a1
a1+1 a1
Write a2 A
Read B b2
b2*2 b2
Write a1 A
Read B b1
b1+1 b1
Write b1 B
Write b2 B

Figure XVI.7 : Deux excutions des transactions T1 et T2

Gestion de transactions 593

3.3. PROPRITS DES OPRATIONS SUR GRANULE

Un granule accd concurremment obit des contraintes dintgrit internes. Lors
des modifications de la base de donnes, les granules sont modifis par des suites
dactions constituant des units fonctionnelles appeles oprations. Les oprations
respectent la cohrence interne du granule, cest--dire les contraintes dintgrit qui
relient les donnes appartenant au granule.
Notion XVI.5 : Opration (Operation)
Suite dactions accomplissant une fonction sur un granule en respectant sa cohrence interne.

Par exemple, si le granule est la page, les oprations de base sont souvent LIRE
(page) et ECRIRE (page), qui sont galement dans bien des systmes des actions indivisibles. Si le granule est larticle, des oprations plus globales ncessitant plusieurs
actions indivisibles sont LIRE (article) et ECRIRE (article), mais aussi MODIFIER
(article) et INSERER (article). Avec ces oprations de base, il est possible den
construire dautres plus globales encore. Sur un objet typ, tel un compte en banque,
on peut distinguer des oprations, crer, crditer, dbiter, dtruire, etc.
Lapplication doprations des granules conduit des rsultats. Le rsultat dune
opration est constitu par ltat du granule concern aprs lapplication de lopration considre et par les effets de bords quelle provoque. Par exemple, le rsultat
dune opration LIRE est reprsent par la valeur du tampon rcepteur aprs excution, alors que le rsultat dune transaction modifiant une base de donnes est ltat
des granules modifis aprs excution ainsi que la valeur des messages dits.
Les oprations sont enchevtres au niveau des actions lors de lexcution simultane
de transactions. Deux oprations qui ne modifient aucun granule et qui appartiennent
deux transactions diffrentes peuvent tre enchevtres de manire quelconque sans
modifier les rsultats de leur excution. Autrement dit, toute intercalation doprations
neffectuant que des lectures conduit des rsultats identiques une excution successive de ces oprations. Plus gnralement, il est possible de dfinir la notion
doprations compatibles.
Notion XVI.6 : Oprations compatibles (Compatible operations)
Oprations 0i et 0j dont toute excution simultane donne le mme rsultat quune excution
squentielle 0i suivie de 0j ou de 0j suivie de 0i ( noter que les rsultats 0i puis 0j, et 0j puis 0i
peuvent tre diffrents).

Considrons par exemple les oprations reprsentes figure XVI.8. Les oprations
O11 et O21 sont compatibles ; O11 et O12 ne le sont pas.
Il est important de remarquer que deux oprations travaillent sur deux granules diffrents sont toujours compatibles. En effet, dans ce cas aucune perte doprations ne

594 BASES DE DONNES : OBJET ET RELATIONNEL

peut survenir si lon intercale les oprations. Or il est simple de voir que deux oprations sont incompatibles lorsque quil existe une possibilit dintercalation gnrant
une perte doprations.
O11
{ Read A a1
a1+1 a1
Write a1 A
O21
{ Read B b1
b1+1 b1
Write b1 B
O31
{ Read A a1
a1+10 a1
Write a1 A }

O12
{ Read A a2
a2*2 a2
}
Write a2 A
O22
{ Read B b2
b2*2 b2
}
Write b2 B }

Figure XVI.8 : Exemple doprations

Les problmes surviennent avec les oprations incompatibles, lorsquune au moins

modifie un granule auquel lautre a accd. Lordre dexcution des deux oprations
peut alors changer les rsultats. Dans dautres cas, il peut tre indiffrent. Plus gnralement, nous dfinirons la notion doprations permutables, quil faut bien distinguer de celle doprations compatibles (la premire est une notion indpendante de
lordre dexcution, alors que la seconde est dfinie partir de la comparaison des
ordres dexcution).
Notion XVI.7 : Oprations permutables (Permutable operations)
Oprations 0i et 0j telles que toute excution de 0i suivie par 0j donne le mme rsultat que celle
de 0j suivie par 0i.

Par exemple, les oprations O11 et O31 reprsentes figure XVI.8 sont permutables
alors que les oprations O11 et O12 ne le sont pas. Soulignons que deux oprations
travaillant sur des granules diffrents sont toujours permutables. En effet, dans ce cas,
lexcution de la premire ne peut modifier le rsultat de la seconde et rciproquement. Par exemple, O11 et O12 sont permutables. Plus gnralement, deux oprations
compatibles sont permutables, mais la rciproque nest pas vraie.

3.4. CARACTRISATION DES EXCUTIONS CORRECTES

Certaines excutions introduisent des pertes doprations ou des inconsistances,
comme nous lavons vu ci-dessus. Lobjectif du contrle de concurrence consiste ne

Gestion de transactions 595

laisser sexcuter que des excutions sans pertes doprations ou inconsistances. Il est
bien connu que lexcution successive de transactions (sans simultanit entre transactions) est un cas particulier dexcution sans perte doprations ni inconsistances.
Une telle excution est appele succession et peut tre dfinie plus formellement
comme suit :
Notion XVI.8 : Succession (Serial Schedule)
Excution E dun ensemble de transactions {T1, T2Tn} telle quil existe une permutation de
(1,2n) telle que :
E = < T (1) ; T(2) ; T (n) >

Afin dassurer labsence de conflit, il est simple de ne tolrer que les excutions qui
donnent le mme rsultat quune succession pour chaque transaction. De telles excutions sont dites srialisables.
Notion XVI.9 : Excution srialisable (Serialisable Schedule)
Excution E dun ensemble de transactions {T1, T2Tn} donnant globalement et pour chaque transaction participante le mme rsultat quune succession de (T1, T2Tn).

Le problme du contrle de concurrence est donc dassurer quun systme centralis

(ou rparti) ne peut gnrer que des excutions srialisables. Cest l une condition
suffisante pour assurer labsence de conflit dont la ncessit peut tre discute
[Gardarin77]. En fait, la condition est ncessaire si le systme na pas de connaissances sur la smantique des oprations.
Afin de caractriser les excutions srialisables, nous introduisons deux transformations de base dune excution de transactions. Tout dabord, la sparation doprations
compatibles Oi et Oj excutes par des transactions diffrentes consiste remplacer
une excution simultane des oprations E (Oi, Oj) par la squence donnant le mme
rsultat, soit < Oi ; Oj > ou < Oj ; Oi >. La sparation doprations permet donc de
mettre en succession des oprations compatibles excutes par des transactions diffrentes. Ensuite, la permutation doprations permutables Oi et Oj excutes par des
transactions diffrentes consiste changer lordre dexcution de ces oprations ; par
exemple la squence < Oi ; Oj > est remplace par la squence < Oj ; Oi >.
Une condition suffisante pour quune excution soit srialisable est quelle puisse tre
transforme par sparation des oprations compatibles et permutations des oprations
permutables en une succession des transactions composantes. En effet, par dfinition,
sparations et permutations conservent les rsultats. Par suite, si lexcution peut tre
transforme en une succession, elle donne le mme rsultat que cette succession pour
chaque transaction et est donc srialisable. La condition nest pas ncessaire car, au
moins pour certaines valeurs des donnes, des oprations incompatibles ou non permutables peuvent tre excutes simultanment sans conflits.

596 BASES DE DONNES : OBJET ET RELATIONNEL

titre dexemple, considrons lexcution reprsente figure XVI.7(a). En reprsentant seulement globalement les oprations, cette excution scrit :
T1 : A + 1 A
T2 : A * 2 A
T1 : B + 1 B
T2 : B * 2 B
Les oprations A *2 A et B + 1 B sont permutables car elles agissent sur des
granules diffrents. Par suite, cette excution peut tre transforme en :
T1 : A + 1 A
T1 : B + 1 B
T2 : A * 2 A
T2 : B * 2 B
qui est une succession de T1 puis T2. Par suite, lexcution figure XVI.7(a) est srialisable.

3.5. GRAPHE DE PRCDENCE

Une excution srialisable est correcte car elle donne un rsultat que lon obtiendrait
en excutant les transactions lune aprs lautre. Lorsquon examine une squence
doprations rsultant dune excution simultane dun ensemble de transactions, il
apparat que lordre de certaines oprations ne peut tre chang sans changer le rsultat, du fait de la non-commutativit des oprateurs excuts (par exemple, addition et
multiplication).
Les chercheurs ont ainsi abouti dfinir la notion de prcdence de transactions dans
une excution simultane.
Notion XVI.10 : Prcdence (Precedence)
Proprit stipulant quune transaction a accompli une opration Oi sur une donne avant quune
autre transaction accomplisse une opration Oj, Oi et Oj ntant pas commutatives ({Oi; Oj} {Oj;
Oi}).

La notion de prcdence est gnrale et sapplique tout type dopration. En pratique, les systmes ne considrent dordinaire que les oprations de lecture et dcriture. Les prcdences sont alors cres par les squences dactions de base lecture et
criture. Les squences non commutatives lecture puis criture, criture puis lecture,
criture puis criture, dune mme donne introduisent des prcdences. Plus prcisment, lune des squences :
Ti : lire(D) Tj : crire(D) ;

Gestion de transactions 597

Ti : crire(D) Tj : crire(D) ;
Ti : crire(D) Tj : lire(D) ;
implique que Ti prcde Tj.
Considrons une excution simultane de transactions. La relation de prcdence
entre transactions peut tre reprsente par un graphe :
Notion XV.11 : Graphe de prcdence (Precendency graph)
Graphe dont les nuds reprsentent les transactions et dans lequel il existe un arc de Ti vers Tj si Ti
prcde Tj dans lexcution analyse.

Une excution simultane des transactions T1, T2 et T3 et le graphe de prcdence

associ sont illustrs figure XVI.9.
Il est simple de montrer quune condition suffisante de srialisabilit est que le graphe
de prcdence soit sans circuit. En effet, dans ce cas, il est toujours possible de transformer lexcution simultane en une succession en sparant puis permutant les oprations. Lordre des transactions dans la succession est induit par le graphe sans circuit. Par exemple, lexcution simultane reprsente figure XVI.9 nest pas srialisable puisque le graphe de prcdence possde un circuit.
{ T1 : Lire A ;
T2 : Ecrire A ;
T2 : Lire B ;
T2 : Ecrire B ;
T3 : Lire A ;
T1 : Ecrire B }

T1
A

B
T2
A

T3

Figure XVI.9 : Exemple de graphe de prcdence

4. CONTRLE DE CONCURRENCE
PESSIMISTE
Deux types de techniques ont t dveloppes pour garantir la srialisabilit des transactions : les techniques de prvention des conflits qui empchent leur apparition et

598 BASES DE DONNES : OBJET ET RELATIONNEL

les techniques de dtection qui laissent les conflits se produire mais les dtectent et
annulent leurs effets. Les premires sont dites pessimistes car elles prviennent des
conflits qui ne surviennent en gnral pas. Elles sont bases sur le verrouillage. Les
secondes sont dites optimistes. Dans cette partie, nous tudions le verrouillage qui est
de loin la technique la plus applique.

4.1. LE VERROUILLAGE DEUX PHASES

Le verrouillage deux phases est une technique de prvention des conflits base sur le
blocage des objets par des verrous en lecture ou criture avant deffectuer une opration de slection ou de mise jour. En thorie, une transaction ne peut relcher de verrous avant davoir obtenu tous ceux qui lui sont ncessaires, afin de garantir la correction du mcanisme [Eswaran76].
Notion XVI.12 : Verrouillage deux phases (Two Phase Locking)
Technique de contrle des accs concurrents consistant verrouiller les objets au fur et mesure
des accs par une transaction et relcher les verrous seulement aprs obtention de tous les verrous.

Une transaction comporte donc deux phases (voir figure XVI.10) : une phase dacquisition de verrous et une phase de relchement. Cette condition garantit un ordre identique des transactions sur les objets accds en mode incompatible. Cet ordre est celui
dexcution des points de verrouillage maximal . En pratique, afin de garantir lisolation des mises jour, les verrous sont seulement relchs en fin de transaction, lors
de la validation.
Nombre
de verrous

temps

Figure XVI.10 : Comportement des transactions deux phases

Les verrous sont demands au moyen de lopration Lock(G,M) et relchs au

moyen de lopration Unlock(G), G tant le granule verrouiller/dverrouiller et M
le mode de verrouillage. Les compatibilits entre oprations dcoulent des prcdences ; elles sont dcrites par la matrice reprsente figure XVI.11. Les algorithmes
Lock et Unlock sont dtaills figure XVI.12. Lors dune demande de verrouillage,

Gestion de transactions 599

si lobjet demand est verrouill, la transaction demandante est mise en attente

jusqu libration de lobjet. Ainsi, toute transaction attend la fin des transactions
incompatibles, ce qui garantit un graphe de prcdence sans circuit. Une analyse fine
montre que les circuits sont transforms en verrous mortels.
L

Figure XVI.11 : Compatibilit des oprations de lecture/criture

Bool Function Lock(Transaction t, Granule G, Mode M){
Cverrou := 0 ;
Pour chaque transaction i t ayant verrouill lobjet G faire {
Cverrou := Cverrou t.verrou(G) }; // cumuler verrous sur G
si Compatible (Mode, Cverrou) alors {
t.verrou(G) = t.verrou(G) M; // marquer lobjet verrouill
Lock := true ; }
sinon {
insrer (t, Mode) dans queue de G ; // mise en attente de t
bloquer la transaction t ;
Lock := false ; } ;
} ;
Procdure Unlock(Transaction t, Granule G){
t.verrou(G) := 0 ; // Remise 0 du verrou de la transaction sur G
Pour chaque transaction i dans la queue de G faire {
si Lock(i, G,M) alors { // Tentative de verrouillage pour Ti
enlever (i,M) de la queue de G ;
dbloquer i ; } ; };
} ;

Figure XVI.12 : Algorithmes de verrouillage et dverrouillage

Lapplication du verrouillage dans un systme pose le problme du choix du granule

de verrouillage. Dans une base de donnes relationnelle, les objets verrouiller peuvent tre des tables, des pages ou des tuples. Une granularit variable des verrous est
souhaitable, les transactions manipulant beaucoup de tuples pouvant verrouiller au
niveau table ou page, celles accdant ponctuellement quelques tuples ayant la capacit de verrouiller au niveau tuple. Nous examinerons ci-dessous le problme des granules de taille variable. Le choix dune unit de verrouillage fine (par exemple le
tuple) minimise bien sr les risques de conflits. Elle maximise cependant la complexit et le cot du verrouillage.

600 BASES DE DONNES : OBJET ET RELATIONNEL

4.2. DEGR DISOLATION EN SQL2

Le verrouillage, tel que prsent ci-dessus, est trs limitatif du point de vue des excutions simultanes possibles. Afin de proposer une approche plus permissive et de laisser sexcuter simultanment des transactions prsentant des dangers limits de corruption des donnes, le groupe de normalisation de SQL2 a dfini des degrs disolation embots, du moins contraignant au plus contraignant, ce dernier correspondant
au verrouillage deux phases. Le groupe distingue les verrous courts relchs aprs
excution de lopration et les verrous longs relchs en fin de transaction. Le degr
de verrouillage souhait est choisi par le dveloppeur de la transaction parmi les suivants :
Le degr 0 garantit les non pertes des mises jour ; il correspond la pose de verrous courts exclusifs lors des critures.
Le degr 1 garantit la cohrence des mises jour ; il gnre la pose de verrous longs
exclusifs en criture par le systme.
Le degr 2 assure la cohrence des lectures individuelles ; il ajoute la pose de verrous courts partags en lecture ceux du degr 1.
Le degr 3 atteste de la reproductibilit des lectures ; il complte le niveau 2 avec la
pose de verrous longs partags en lecture.
Ainsi, le dveloppeur peut contrler la pose des verrous. Un choix autre que le degr
3 doit tre effectu avec prcaution dans les transactions de mises jour, car il
implique des risques dincohrence. Seul en effet le degr 3 assure la srialisabilit
des transactions.

4.3. LE PROBLME DU VERROU MORTEL

4.3.1. Dfinition
Le verrouillage soulve quelques problmes. Le problme essentiel est le risque de
verrous mortels entre transactions.
Notion XVI.13 : Verrou mortel (Deadlock)
Situation dans laquelle un groupe de transactions est bloqu, chaque transaction du groupe attendant quune autre transaction du groupe relche un verrou pour pouvoir continuer.

Une transaction Ti attend une transaction Tj si Ti a demand lobtention dun verrou

sur un objet verrouill par Tj en mode incompatible. La figure XVI.13 donne un
exemple de verrou mortel.

Gestion de transactions 601

T1

T2

Lock(T1, G1, ECRITURE)

Lock(T2, G2, ECRITURE)

Lock(T1, G2, ECRITURE)

Lock(T2, G1, LECTURE)

T1
attend

T2
attend

temps

Figure XVI.13 : Exemple de verrou mortel

Deux classes de solutions sont possibles dans les SGBD afin de rsoudre le problme
du verrou mortel : la premire, appele prvention, empche les situations de verrous
mortels de survenir ; la seconde, appele dtection, est une solution curative qui
consiste supprimer les verrous mortels par reprise de transactions.

4.3.2. Reprsentation du verrou mortel

Nous prsentons ci-dessous deux types de graphes reprsentant les verrous mortels :
le graphe des attentes et le graphe des allocations.

4.3.2.1. Graphe des attentes

Le graphe des attentes [Murphy68] est un graphe G (T,) o T est lensemble des
transactions concurrentes {T1, T2 Tn} se partageant les granules G1, G2Gm et
est la relation attend dfinie par : Tp attend Tq si et seulement si Tp attend le
verrouillage dun objet Gi alors que cette requte ne peut pas tre accepte parce que
Gi a dj t verrouill par Tq.
Notion XVI.14 : Graphe des attentes (Waiting graph)
Graphe dont les nuds correspondent aux transactions et les arcs reprsentent les attentes entre
transactions.

Le thorme suivant a t introduit ds 1968 [Murphy68] : il existe une situation de

verrou mortel si et seulement si le graphe des attentes possde un circuit. La
figure XVI.14 illustre ce thorme sur lexemple introduit ci-dessus. La preuve est

602 BASES DE DONNES : OBJET ET RELATIONNEL

simple. En effet, si le graphe des attentes possde un circuit, cest quil existe un
groupe de transactions tel que : T1 attend T2, T2 attend T3,Tk attend T1. Chaque
transaction du groupe est donc bloque en attente dun objet du fait de lutilisation de
cet objet par une autre transaction du groupe. La fin dexcution de toutes les transactions nappartenant pas au groupe ne permet donc pas de dbloquer une transaction du
groupe.

T1

T2

Figure XVI.14 : Exemple de graphe dattente avec circuit

Rciproquement, lexistence dune situation de verrou mortel implique lexistence

dau moins un circuit. Sil nen tait pas ainsi, tout groupe de transaction serait tel que
le sous-graphe des attentes quil engendre ne possderait pas de circuit. Aprs excution de toutes les transactions nappartenant pas au groupe, il serait donc possible de
dbloquer une transaction du groupe puisquun graphe sans circuit possde au moins
un sommet pendant. Toutes les transactions appartenant un circuit sont en situation
de verrou mortel ; de plus, une transaction attendant une transaction en situation de
verrou mortel est elle-mme en situation de verrou mortel (voir figure XVI.15).
T1

T4

T2

T3

T5

Figure XVI.15 : Transactions en situation de verrou mortel

Il est intressant dtablir le rapport entre graphes des attentes et graphe de prcdence. Par dfinition, si une transaction Ti attend une transaction Tj, alors Tj a verrouill un objet O dont le verrouillage est demand par Ti dans un mode incompatible.
Ainsi, lopration pour laquelle Tj a verrouill O sera excute avant celle demande
par Tj car les deux oprations sont incompatibles et donc non permutables. Donc Tj
prcde Ti. Toutefois, la relation de prcdence nimplique gnralement pas la
relation dattente. Donc, en changeant lorientation des arcs du graphe des attentes, on
obtient un sous-graphe du graphe de prcdence. Cela implique que si le graphe des
attentes a un circuit, il en sera de mme pour le graphe de prcdence. En consquence, une situation de verrou mortel ne peut pas donner lieu une excution srialisable mme sil tait possible de terminer les transactions interbloques.

Gestion de transactions 603

4.3.2.2. Graphe des allocations

Le graphe des allocations [Holt72] est compos de deux ensembles de sommets :
1. lensemble T des transactions
2. lensemble O des objets.
Un arc relie lobjet Oi la transaction Tp si et seulement si Tp a obtenu le verrouillage de Oi dans au moins un mode dopration ; larc est valu par les modes
doprations allous. Un arc relie la transaction Tp lobjet Oi si et seulement si Tp a
demand et na pas encore obtenu lallocation de ce granule ; larc est valu par les
modes doprations demands. La figure XVI.16 reprsente le graphe des allocations
de lexemple de la figure XVI.13.
T1

T2

G1

G2

Figure XVI.16 : Exemple de graphe des allocations

Il est simple de dmontrer le thorme suivant : une condition ncessaire dexistence

de verrou mortel est la prsence dun circuit sur le graphe des allocations. Cette
condition nest en gnral pas suffisante. La preuve seffectue par labsurde. En effet,
il est possible de prouver que sil nexiste pas de circuits sur le graphe des allocations,
il ne peut y avoir dinterblocage. En effet, soit T un groupe quelconque de transactions. Du fait que le graphe des allocations est sans circuit, le sous-graphe obtenu
aprs excution des transactions nappartenant pas T est sans circuit. Il possde donc
un sommet pendant. Ce sommet ne peut tre un granule car un granule non verrouill
ne peut tre attendu. Dans tout groupe de transactions T, lexcution suppose de
toutes les transactions nappartenant pas au groupe T conduit donc dbloquer une
transaction du groupe. Il ny a donc pas situation de verrou mortel.
Il faut remarquer que la condition est suffisante dans le cas o les seuls modes de lecture et dcriture sont distingus. Ceci permet en gnral de dtecter les situations de
verrou mortel par dtection de circuits dans le graphe des allocations dans la plupart
des systmes classiques. Nous pouvons noter quen gnral il ny a pas de rapport
direct entre graphe de prcdence et graphe des allocations. Cependant, si les seuls
modes existants sont lecture et criture, la prsence dun circuit dans le graphe des
allocations est quivalente lexistence dune situation de verrou mortel et donc

604 BASES DE DONNES : OBJET ET RELATIONNEL

celle dun circuit dans le graphe des attentes. Sous cette condition, la prsence dun
circuit dans le graphe des allocations entrane ainsi celle dun circuit dans le graphe de
prcdence.

4.3.3. Prvention du verrou mortel

La prvention consiste appliquer une stratgie de verrouillage garantissant que le
problme ne survient pas. Il existe classiquement deux approches, lune base sur
lordonnancement des ressources, lautre sur celui des transactions. Lordonnancement des ressources (tables, pages, objets, tuples) pour les allouer dans un ordre fix
aux transactions est impraticable vu le grand nombre dobjets distribus. Lordonnancement des transactions est possible partir dune estampille.
Notion XVI.15 : Estampille de transaction (Transaction Timestamp)
Numro unique attribu une transaction permettant de lordonner strictement par rapport aux
autres transactions.

En gnral, lestampille attribue une transaction est son horodate de lancement

concatne avec le numro de processeur sur lequel elle est lance, ceci afin dempcher lgalit des estampilles pour deux transactions lances au mme instant : cellesci diffrent alors par le numro de processeur en poids faibles. Le numro de processeur nest utile que dans les architectures parallles.
partir des estampilles, deux algorithmes ont t proposs [Rosenkrantz77] pour prvenir les verrous mortels. Tous deux consistent dfaire plus ou moins directement
une transaction dans le cas dattente, de sorte ne permettre que des attentes sans
risque de circuit. Lalgorithme WAIT-DIE consiste annuler les transactions qui
demandent des ressources tenues par des transactions plus anciennes. La transaction la
plus rcente est alors reprise avec la mme estampille ; elle finit ainsi par devenir
ancienne et par passer. Il ne peut y avoir de verrou mortel, les seules attentes possibles
tant dans lordre o une transaction ancienne attend une transaction rcente. Le
contrle des attentes impos par lalgorithme est prcis figure XVI.17.
// Algorithm WAIT-DIE
Procdure Attendre (Ti,Tj) {
// Ti rclame un verrou tenu par Tj
si ts(Ti) < ts(Tj) alors Ti waits sinon Ti dies ; }

Figure XVI.17 : Contrle des attentes dans lalgorithme WAIT-DIE

Lalgorithme WOUND-WAIT est un peu plus subtil. Tout type dattente est permis.
Mais si une transaction plus ancienne attend une plus rcente, la rcente est blesse
(wounded), ce qui signifie quelle ne peut plus attendre : si elle rclame un verrou

Gestion de transactions 605

tenu par une autre transaction, elle est automatiquement dfaite et reprise. Le contrle
des attentes impos par lalgorithme est reprsent figure XVI.18 ; une transaction
blesse ne peut donc attendre.
// Algorithm WOUND-WAIT
Procdure Attendre (Ti,Tj) {
// Ti rclame un verrou tenu par Tj
si ts(Ti) < ts(Tj) alors Tj is wounded sinon Ti waits ; }

Figure XVI.18 : Contrle des attentes dans lalgorithme WOUND-WAIT

Les deux algorithmes empchent les situations de verrous mortels en donnant priorit
aux transactions les plus anciennes. Lalgorithme WOUND-WAIT provoque en principe moins de reprises de transactions et sera en gnral prfr.

4.3.4. Dtection du verrou mortel

La prvention provoque en gnral trop de reprises de transactions, car les mthodes
dfont des transactions alors que les verrous mortels ne sont pas srs dapparatre. Au
contraire, la dtection laisse le problme se produire, dtecte les circuits dattente et
annule certaines transactions afin de rompre les circuits dattente.
Un algorithme de dtection de linterblocage peut se dduire dun algorithme de
dtection de circuits appliqu au graphe des attentes ou des allocations. Nous prsentons ici une mise en uvre de lalgorithme qui consiste tester si un graphe est sans
circuit par limination successive des sommets pendants.
Sur le graphe des attentes, un sommet est pendant si la transaction quil reprsente
nattend le verrouillage daucun granule. Soit N(k) le nombre de granules dont la transaction Tk attend le verrouillage. Une premire rduction du graphe peut tre obtenue par
limination des sommets pendants, donc tels que N(k) = 0. Le problme est alors de
recalculer les nombres de granules attendus N(k) aprs rduction pour pouvoir effectuer
la rduction suivante. Ceci peut tre fait en comptant les demandes qui peuvent tre satisfaites aprs chaque rduction, et en dcrmentant N(k) chaque fois que lon compte une
demande de la transaction Tk. Lapplication de la mthode ncessite deux prcautions :
1. marquer les demandes comptes pour ne pas les compter deux fois ;
2. disposer dune procdure permettant de tester si une demande peut tre satisfaite
compte tenu de ltat des verrouillages des transactions non encore limines du
graphe des attentes.
Soit donc SLOCK (k, G, M) une procdure boolenne permettant de tester si la
demande du granule G en mode M de la transaction Tk peut tre satisfaite compte
tenu de ltat dallocation des granules aux transactions prsentes dans le graphe des
attentes. Cette procdure rpond VRAI si la demande peut tre satisfaite et FAUX

606 BASES DE DONNES : OBJET ET RELATIONNEL

sinon. Le code de cette procdure est analogue celui de lalgorithme LOCK vu cidessus, ceci prs que seule les transactions de T sont prises en compte (les autres
sont supposes excutes et termines) et que ltat de verrouillage nest pas modifi.
La figure XVI.19 prsente une procdure DETECTER rpondant VRAI sil y a situation de verrou mortel et FAUX sinon. Cette procdure limine donc progressivement
les transactions pendantes du graphe des attentes.
Bool Procedure Detecter {
T = {Liste des transactions telles que N(k) 0 }
G = {liste des granules alloues aux transactions dans T}
Pour chaque entre g de G faire
Pour chaque demande non marque M de Tk en attente de g faire {
Si SLOCK(k, g, Q) = VRAI alors {
Marquer Q ;
N(k) = N(k) 1 ;
Si N(k) = 0 alors {
Eliminer Tk de T ;
Ajouter les granules verrouills par Tk G ;
} ;
} ;
} ;
Si T = alors DETECTER = FAUX
Sinon DETECTER = VRAI ;
} ;

Figure XVI.19 : Algorithme de dtection du verrou mortel

Quand une situation dinterblocage est dtecte, le problme qui se pose est de choisir
une transaction recycler de faon briser les circuits du graphe des attentes. Lalgorithme de dtection prsent ci-dessus fournit la liste des transactions en situation
dinterblocage. Il faut donc choisir une transaction de cette liste. Cependant, tous les
choix ne sont pas judicieux, comme le montre la figure XVI.20. Une solution ce
problme peut tre de recycler la transaction qui bloque le plus grand nombre dautres
transactions, cest--dire qui correspond au sommet de demi-degr intrieur le plus
lev sur le graphe des attentes. Le choix de la transaction reprendre doit aussi chercher minimiser le cot de reprise.
T1

T2

T3

Figure XVI.20 : Exemple de choix difficile de transaction reprendre

Gestion de transactions 607

Le cot dune solution de type dtection avec reprise peut tre rduit. En effet, il est
possible de dclencher un algorithme dtection seulement quand une transaction
attend un verrouillage depuis un temps important (par exemple, quelques secondes),
plutt qu chaque dbut dattente.
Dautres algorithmes de dtection sont possibles. Le graphe dallocation est souvent
utilis dans les systmes rpartis. Lors dune attente qui dure, un algorithme envoie
une enqute le long des arcs du graphe des allocations. Cette enqute est transmise au
granule attendu, puis aux transactions bloquant ce granule, puis aux granules attendus
sil en existe, etc. Si lenqute revient la transaction initiale, cest quil y a un verrou
mortel. Cet algorithme est moins efficace en centralis.

4.4. AUTRES PROBLMES SOULEVS

PAR LE VERROUILLAGE
Un autre problme soulev par le verrouillage est le problme de famine, encore
appel blocage permanent. Ce problme survient ds quun groupe de transactions se
coalise, en effectuant des oprations compatibles entre elles (par exemple des lectures), contre une transaction individuelle qui dsire effectuer une opration incompatible avec les prcdentes (par exemple une criture). La transaction individuelle peut
alors attendre indfiniment. Les solutions ce problme consistent en gnral mettre
en file dattente les demandes de verrouillage dans leur ordre darrive et naccepter
une requte de verrouillage que si elle est compatible avec les verrouillages en cours
et ceux demands par les requtes les plus prioritaires en attente. Il faut noter que les
algorithmes de prvention DIE-WAIT et WOUND-WAIT ne conduisent jamais une
transaction lattente infinie. En effet, une transaction qui meurt garde son ancienne
estampille lorsquelle est relance. Elle devient ainsi plus vieille et finit toujours par
passer, le principe tant davorter les transactions les plus jeunes.
Le problme des fantmes a galement t soulev [Eswaran76]. Il survient lorsquun
objet est introduit dans la base de donnes et ne peut tre pris en compte par une transaction en cours qui devrait logiquement le traiter. Par exemple, soit la base de donnes
de rservation de places davions, reprsente figure XVI.21, compose de deux relations : PASSAGER (nom, numro de vol, numro de sige) et OCCUPATION (numro
de vol, nombre de passagers). Considrons maintenant les transactions suivantes :
T1 (1re partie) : lister la relation PASSAGER en lisant tuple tuple ;
T1 (2e partie) : lister la relation OCCUPATION dun seul tuple ;
T2 : insrer dans PASSAGER le tuple (Fantomas, 100, 13) et incrmenter le
nombre de passagers du vol numro 100.
Les transactions sont supposes verrouiller les tuples. Supposons que les transactions
senchevtrent dans lordre : T1 (1re partie), T2, T1 (2e partie). Cest une excution

608 BASES DE DONNES : OBJET ET RELATIONNEL

valide puisque T2 accde un granule non verrouill qui nexiste mme pas lorsque
T1 excute sa 1re partie : le tuple Fantomas . Toutefois, le rsultat de T1 est une
liste de 4 noms alors que le nombre de passagers est 5. Fantomas est ici un fantme pour T1.
Passagers

Nom

NVol

NSige

Dubois

100

Durand

100

Dupont

100

10

Martin

100

15

Occupation

NVol

NbrePass

100

Figure XVI.21 : Illustration du problme des fantmes

Ce problme, ainsi que la difficult de citer les granules verrouiller, peuvent tre
rsolus par la dfinition de granules logiques (dans lexemple, les passagers du
vol 100) au moyen de prdicats [Eswaran76]. Le verrouillage par prdicat permet galement de dfinir des granules de tailles variables, ajustes aux besoins des transactions. Malheureusement, il ncessite des algorithmes pour dterminer si deux prdicats sont disjoints et ce problme de logique na pas de solution suffisamment efficace
pour tre appliqu dynamiquement lors du verrouillage des objets. De plus, les prdicats sont dfinis sur des domaines dont les extensions ne sont pas consultables dans la
base pour des raisons videntes de performance. Donc, il est trs difficile de dterminer si deux prdicats sont disjoints ; par exemple, PROFESSION = Ingnieur et
SALAIRE < 7000 seront dtermins logiquement non disjoints, alors quils le sont
dans la plupart des bases de donnes. Le verrouillage par prdicat est donc en pratique
source dattentes inutiles et finalement inapplicable.

4.5. LES AMLIORATIONS DU VERROUILLAGE

Malgr le grand nombre de solutions proposes par les chercheurs, les systmes continuent appliquer le verrouillage deux phases avec prvention ou dtection des verrous mortels. Les degrs disolation choisis par les transactions permettent de maximiser le partage des donnes en limitant le contrle. Le verrouillage est cependant trs
limitatif. Un premier problme qui se pose est le choix de la granularit des objets
verrouiller. Au-del, la recherche sur lamlioration du verrouillage continue et des
solutions parfois applicables ont t proposes. Nous analysons les plus connues cidessous.

Gestion de transactions 609

4.5.1. Verrouillage granularit variable

Une granularit variable est possible. La technique consiste dfinir un graphe acyclique dobjets embots et verrouiller partir de la racine dans un mode dintention
jusquaux feuilles dsires qui sont verrouilles en mode explicite. Par exemple, une
transaction dsirant verrouiller un tuple en mode criture verrouillera la table en intention dcriture, puis la page en intention dcriture, et enfin le tuple en mode criture.
Les modes dintentions obissent aux mmes rgles de compatibilits que les modes
explicites, mais sont compatibles entre eux. Le verrouillage en intention permet simplement dviter les conflits avec les modes explicites. Sur un mme objet, les modes
explicites rglent les conflits. La figure XVI.22 donne la matrice de compatibilit
entre les modes lecture (L), criture (E), intention de lecture (IL) et intention dcriture (IE).
L

IL

IE

IL

IE

Figure XVI.22 : Compatibilits entre les modes normaux et dintention

Une telle mthode peut tre applique dans les bases relationnelles, mais aussi objet.
Le graphe dinclusion pour une base de donnes objet peut tre base, extension de
classe, page ou groupe (cluster) et objet. Il est reprsent figure XVI.23.
base

classe

cluster

page

objet

Figure XVI.23 : Granules variables pour une BD objet

610 BASES DE DONNES : OBJET ET RELATIONNEL

4.5.2. Verrouillage multi-versions

Le verrouillage multi-versions suppose lexistence dau moins une version prcdente dun objet en cours de modification. Cest gnralement le cas dans les systmes puisque, comme nous le verrons ci-dessous, un journal des images avant mise
jour est gr en mmoire. Le principe est simple : lors dun verrouillage en lecture, si le granule est occup par une transaction en mode incompatible (donc en
criture en pratique), la version prcdente du granule est dlivre lutilisateur.
Une telle technique est viable lorsque les granules verrouills sont des pages ou des
tuples. Au-del, il est difficile de constituer une version cohrente du granule rapidement.
Avec le verrouillage multi-versions, tout se passe comme si la transaction qui lit
avait t lance avant la transaction qui crit. Malheureusement, la srialisabilit
nest pas garantie si la transaction qui accde la version ancienne crit par ailleurs.
En effet, la mise jour de la transaction en quelque sorte saute nest pas prise en
compte par la transaction lisant, qui risque dobtenir des rsultats dpasss ne pouvant servir aux mises jour. Seule les transactions neffectuant que des lectures peuvent utiliser ce mcanisme, aussi appel lecture dans le pass. Si lon veut de plus
garantir la reproductibilit des lectures, il faut grer au niveau du systme un cache
des lectures effectues dans le pass, afin de les retrouver lors de la deuxime lecture. Ce type de verrouillage est rserv au dcisionnel qui ainsi nest pas perturb
par les mises jour.

4.5.3. Verrouillage altruiste

Le verrouillage altruiste suppose connu les patterns daccs aux granules des transactions, cest--dire au moins lordre daccs aux granules et les granules non accds. Il devient alors possible de relcher les verrous tenus par une transaction longue
lorsquon sait quelle nutilisera plus un granule. Ce granule est alors ajout
lensemble des granules utiliss par la transaction, appele la trane (wake) de la
transaction. En cas de reprise, toutes les transactions dans la trane dune transaction
sont aussi reprises (cest--dire celles ayant accd des objets dans la trane). Cest
leffet domino, selon lequel une transaction implique la reprise dautres pour compenser la non isolation (voir ci-dessous). Par exemple, figure XVI.24, on voit que T2
peut sexcuter alors que T1 nest pas termine car on sait que T1 ne reviendra pas sur
c et que T2 naccdera pas a. Si T3 est reprise, T4 doit ltre aussi car elle a modifi c,
lui-mme modifi par T3.
Le verrouillage altruiste est difficile appliquer en pratique car on ne connat pas les
patterns daccs des transactions. De plus, leffet domino reste mal matris. Cette
technique pourrait tre intressante pour faire cohabiter des transactions longues avec
des transactions courtes [Barghouti91].

Gestion de transactions 611

Objets
d
c
b

T1

w = write

T2
w

T3 w

w
Commit

T4 w
Abort

a
Commit

Abort

Temps

Figure XVI.24 : Exemple de verrouillage altruiste

4.5.4. Commutativit smantique doprations

Il est possible dexploiter la smantique des oprations, notamment dans les systmes objet ou objet-relationnel o il existe des types (ou classes) [Gardarin76,
Weihl88, Cart90]. Chaque type est caractris par une liste doprations (mthodes).
Comme nous lavons vu ci-dessus, les oprations commutatives sont permutables et
nentranent pas de conflits de prcdence. Il est donc intressant de distinguer des
modes de verrouillage plus fins que lecture et criture, permettant de prendre en
compte les oprations effectives sur les objets typs, et non pas les actions de base
lecture et criture.
Introduire la commutativit entre oprations est utile si les oprations de mises jour,
a priori incompatibles, sont souvent commutatives. Si lon regarde seulement le nom
de lopration, la commutativit est rare car elle dpend souvent des paramtres,
notamment de la rponse. Les chercheurs ont donc introduit des modes doprations
incluant les rponses. Par exemple, avec des ensembles, il est intressant de distinguer
insrer avec succs [Ins,ok], supprimer avec succs [Del,ok], tester lappartenance avec succs [In, true] et avec chec [In, False]. La matrice de commutativit est reprsente figure XVI.25.
Dans un systme typ, chaque objet peut possder en option un contrle de concurrence
dfini au niveau de la classe. Les verrouillages sont alors dlgus au contrleur du type
dobjet. Celui-ci laisse passer simultanment les verrouillages en modes doprations
commutatives. Par exemple, un ensemble pourra tre verrouill simultanment par deux
transactions en mode [Ins,ok], ou en [In,False] et [Del,ok]. Le contrleur
bloque seulement les oprations non commutatives (ordonnancement).
Les reprises en cas de panne ou dobtention dun rsultat invalide (non verrouill par
exemple) sont cependant difficiles. En effet, comme pour le verrouillage altruiste, le
modle est ouvert et permet des transactions de voir des donnes modifies par des

612 BASES DE DONNES : OBJET ET RELATIONNEL

transactions non encore termines. Il faut donc grer la porte des transactions, par
exemple sous forme de listes de transactions dpendantes. Leffet domino introduit cidessus survient : lors de la reprise dune transaction, toutes les transactions dpendantes doivent tre reprises.

[Ins,ok]

[Del,ok]

[In,true]

[In,False]

[Ins,ok]

[Del,ok]

[In,true]

[In,False]

Figure XVI.25 : Commutativit doprations sur ensemble

Certains auteurs [Weihl88] ont aussi considr la commutativit en avant et la commutativit en arrire. Par exemple [In,true] et [Insert,ok] commutent en
avant mais pas en arrire : si lon excute ces deux oprations partir dun tat s sur
lequel elles sont dfinies, on obtient bien le mme rsultat quel que soit lordre. Mais
si lon a lexcution [Insert, ok] [In, true], on nest pas sur que
[In,true] soit dfinie sur ltat initial (lobjet insr peut tre celui qui a permis le
succs de lopration In). Donc, on ne peut pas commuter lorsquon dfait et refait
une excution. Tout cela complique les procdures de reprises et lexploitation de la
commutativit des oprations.

5. CONTRLES DE CONCURRENCE
OPTIMISTE
Le verrouillage est une solution pessimiste : il empche les conflits de se produire, ou
plutt les transforme en verrou mortel. Analysons maintenant une autre gamme de

Gestion de transactions 613

solutions qualifies doptimistes qui laissent se produire les conflits et les rsout
ensuite.

5.1. ORDONNANCEMENT PAR ESTAMPILLAGE

Bien que le verrouillage avec prvention ou dtection du verrou mortel soit la technique gnralement applique dans les SGBD, de nombreuses autres techniques ont
t proposes. En particulier, lordonnancement par estampille peut tre utilis non
seulement pour rsoudre les verrous mortels comme vu ci-dessus, mais plus compltement pour garantir la srialisabilit des transactions.
Une mthode simple consiste conserver pour chaque objet accd (tuple ou page),
lestampille du dernier crivain W et celle du plus jeune lecteur R. Le contrleur de
concurrence vrifie alors :
1. que les accs en criture seffectuent dans lordre croissant des estampilles de transactions par rapport aux oprations crant une prcdence, donc lcrivain W et le
lecteur R.
2. que les accs en lecture seffectuent dans lordre croissant des estampilles de transactions par rapport aux oprations crant une prcdence, donc par rapport lcrivain W.
On aboutit donc un contrle trs simple dordonnancement des accs conformment
lordre de lancement des transactions [Gardarin78, Bernstein80]. En cas de
dsordre, il suffit de reprendre la transaction ayant cr le dsordre. Les contrles
ncessaires en lecture et criture sont rsums figure XVI.26.
// Contrle dordonnancement des transactions
Fonction Ecrire(Ti, O) { // la transaction Ti demande lcriture de O;
si ts(Ti) < W(O) ou ts(Ti) < R(O) alors abort(Ti)
sinon executer_ecrire(Ti,O) } ;
Fonction Lire(Ti,O) {// la transaction Ti demande la lecture de lobjet O;
si ts(Ti) < W(O) alors abort(Ti)
sinon executer_lire(Ti,O) } ;

Figure XVI.26 : Algorithme dordonnancement des accs par estampillage

Lalgorithme dordonnancement par estampillage soulve plusieurs problmes. De

fait, les estampilles W et R associes chaque objet remplacent les verrous. Il ny a
pas dattente, celles-ci tant remplaces par des reprises de transaction en cas daccs
ne respectant pas lordre de lancement des transactions. Ceci conduit en gnral

614 BASES DE DONNES : OBJET ET RELATIONNEL

beaucoup trop de reprises. Une amlioration possible consiste garder danciennes

versions des objets. Si lestampille du lecteur ne dpasse pas celle du dernier crivain,
on peut dlivrer une ancienne version, plus exactement, la premire infrieure
lestampille du lecteur. Ainsi, il ny a plus de reprise lors des lectures. La mthode est
cependant difficile mettre en uvre et nest gure utilise aujourdhui.

5.2. CERTIFICATION OPTIMISTE

La certification optimiste est une mthode de type curative, qui laisse les transactions
sexcuter et effectue un contrle garantissant la srialisabilit en fin de transaction.
Une transaction est divise en trois phases : phase daccs, phase de certification et
phase dcriture. Pendant la phase daccs, chaque contrleur de concurrence garde
les rfrences des objets lus/crits par la transaction. Pendant la phase de certification,
le contrleur vrifie labsence de conflits avec les transactions certifies pendant la
phase daccs. Sil y a conflit, la certification est refuse et la transaction dfaite puis
reprise. La phase dcriture permet lenregistrement des mises jour dans la base pour
les seules transactions certifies.
En rsum, nous introduirons ainsi la notion de certification qui peut tre effectue de
diffrentes manires :
Notion XVI.16 : Certification de transaction (Transaction certification)
Action consistant vrifier et garantir que lintgration dans la base de donns des mises jour
prpares en mmoire par une transaction prservera la srialisabilit des transactions.

Vrifier labsence de conflits pourrait seffectuer en testant la non-introduction de circuits dans le graphe de prcdence. Lalgorithme commun [Kung81] de certification
est plus simple. Il consiste mmoriser les ensembles dobjets lus (Read Set RS) et
crits (Write Set WS) par une transaction. La certification de la transaction Ti consiste
tester que RS(Ti) nintersecte pas avec WS(Tj) et que WS(Ti) nintersecte pas avec
WS(Tj) ou RS(Tj) pour toutes les transactions Tj lances aprs Ti. On vrifie donc
que les transactions nagissent pas en modes incompatibles avec les transactions
concurrentes avant de les valider. Lalgorithme est reprsent figure XVI.27.
En rsum, cette mthode optimiste est analogue au verrouillage, mais tous les verrous sont laisss passants et les conflits ne sont dtects que lors de la validation des
transactions. Lavantage est la simplicit du contrleur de concurrence qui se rsume
mmoriser les objets accds et un test simple dintersection densembles de rfrences lors de la validation. Linconvnient majeur est la tendance reprendre beaucoup de transactions en cas de conflits frquents. La mthode optimiste est donc seulement valable pour les cas o les conflits sont rares.

Gestion de transactions 615

Bool Fonction Certifier(Ti) {

Certifier = VRAI ;
Pour chaque transaction t concurrente faire {
Si RS(Ti) WS(t) ou WS(Ti) RS(t)
ou WS(Ti) WS(t)
Alors {
Certifier = FAUX ;
Abort(Ti) ;
} ;
} ;
} ;

Figure XVI.27 : Algorithme de certification optimiste

5.3. ESTAMPILLAGE MULTI-VERSIONS

Comme pour le verrouillage deux phases et mme mieux, la stratgie dordonnancement par estampillage vue ci-dessus peut tre amliore en gardant plusieurs versions
dun mme granule [Reed79]. Pour chaque objet O, le systme peut maintenir :
1. un ensemble destampilles en criture {EEi(O)} avec les valeurs associes { Oi },
chacune delles correspondant une version i ;
2. un ensemble destampilles en lecture {ELi(O)}.
Il est alors possible dassurer lordonnancement des lectures par rapport aux critures
sans jamais reprendre une transaction lisant. Pour cela, il suffit de dlivrer une transaction Ti demandant lire lobjet O la version ayant une estampille en criture
immdiatement infrieure i. Ainsi, Ti prcdera toutes les crations destampilles
suprieures crivant lobjet considr et suivra celles destampilles infrieures. Ti sera
donc correctement squence. Tout se passe comme si Tj avait demand la lecture
juste aprs lcriture de la version destampille immdiatement infrieure. Lalgorithme de contrle de lopration LIRE avec un dispositif dordonnancement partiel
multi-versions est reprsent figure XVI.28.
// Lecture de la bonne version dans le pass
Fonction Lire(Ti,O) {// la transaction Ti demande la lecture de lobjet O;
j = index de la dernire version de O ;
Tant que ts(Ti) < W(O) faire j = j-1 ; // chercher la version avant Ti
executer_lire(Ti,Oj) } ; // lire la bonne version
}

Figure XVI.28 : Algorithme de lecture avec ordonnancement multi-versions

616 BASES DE DONNES : OBJET ET RELATIONNEL

Il est en gnral trs difficile de refaire le pass. Cependant, il est parfois possible de
forcer lordonnancement des critures de Ti en insrant une nouvelle version cre par
Ti juste aprs celle destampille immdiatement infrieure, soit Oj. Malheureusement,
si une transaction Tk (k >i) a lu la version Oj, alors cette lecture doit aussi tre resquence. Ce nest possible que si la transaction Tk pouvait tre reprise. Afin dviter
la reprise de transactions termines, on prfrera reprendre lcrivain Tj avec une nouvelle estampille i suprieure k.
Lalgorithme de contrle de lopration WRITE correspondant est reprsent
figure XVI.29. Les notations sont identiques celles utilises ci-dessus, les indices
dsignant les numros de versions dobjets.
// Rordonnancement des critures dans le pass
Fonction Ecrire(Ti, O) { // la transaction Ti demande lcriture de O;
j = index de la dernire version de O ;
Tant que ts(Ti) < W(Oj) faire j = j-1 ; // chercher la version avant Ti
Si ts(Ti) < R(Oj) alors abort(Ti) // abort si lecture non dans lordre
sinon executer_ecrire(Ti,Oj) } ; // crire en bonne place
}

Figure XVI.29 : Algorithme dcriture avec ordonnancement multi-versions

La figure XVI.30 illustre lalgorithme.

W

10

Version 1

Version 5

Version 7

(a) Lecture de T3
La version 1 est dlivre
(b) criture de T3 : cration d une version 3 non lue

Version 3

(c) criture de T6
Impossible : T7 et T10 devraient tre rexcutes
T6 est annule et reprise plus tard comme T12

Figure XVI.30 : Exemple de resquencement

Gestion de transactions 617

Les transactions entrent en conflit sur un objet O unique dont les versions successives
sont reprsentes par des rectangles. La situation originale est reprsente en haut de
la figure. Trois versions de lobjet existent, successivement cres par les transactions
1, 5 et 7. La version 1 a t lue par la transaction 1, la version 5 par la transaction 7 et
la version 7 par la transaction 10. Nous supposons que T3 accomplit une criture sur
lobjet O aprs lavoir lu. La nouvelle version 3 cre est insre en bonne place.
Nous supposons ensuite que T6 procde une criture sur O. Lobjet ayant t lu par
T7, il faudrait refaire le pass. On prfrera annuler T6 et la relancer plus tard.
En rsum, beaucoup dalgorithmes bass sur des estampilles peuvent tre invents
pour contrler les accs concurrents. Il est mme possible de mixer estampilles et verrouillage, comme dj vu au niveau des algorithmes DIE-WAIT et WOUND-WAIT.
Cependant, les performances de ces algorithmes restent faibles car ils provoquent tous
des reprises qui deviennent de plus en plus frquentes lorsquil y a un plus grand
nombre de conflits, donc lorsque le systme est charg. Voil sans doute pourquoi la
plupart des SGBD utilisent le verrouillage deux phases.

6. LES PRINCIPES DE LA RSISTANCE

AUX PANNES
Nous avons tudi ci-dessus les mcanismes de contrle de concurrence permettant de
limiter les interfrences entre transactions. Abordons maintenant les techniques de
rsistance aux pannes, qui permettent aussi dassurer les proprits ACID des transactions, particulirement latomicit et la durabilit.

6.1. PRINCIPAUX TYPES DE PANNES

Ils existe diffrentes sources de pannes dans un SGBD. Celles-ci peuvent tre causes
par une erreur humaine, une erreur de programmation ou le dysfonctionnement dun
composant matriel. On peut distinguer [Gray78, Fernandez80] :
1. La panne dune action survient quand une commande au SGBD est mal excute.
En gnral, elle est dtecte par le systme qui retourne un code erreur au programme dapplication. Ce dernier peut alors tenter de corriger lerreur et continuer
la transaction.
2. La panne dune transaction survient quand une transaction ne peut continuer par
suite dune erreur de programmation, dun mauvais ordonnancement des accs
concurrents, dun verrou mortel ou dune panne daction non corrigeable. Il faut
alors dfaire les mises jour effectues par la transaction avant de la relancer.

618 BASES DE DONNES : OBJET ET RELATIONNEL

3. La panne du systme ncessite larrt du systme et son redmarrage. La mmoire

secondaire nest pas affecte par ce type de panne ; en revanche, la mmoire centrale est perdue par suite du rechargement du systme.
4. La panne de mmoire secondaire peut survenir soit suite une dfaillance matrielle, soit suite une dfaillance logicielle impliquant de mauvaises critures.
Alors, une partie de la mmoire secondaire est perdue. Il sagit du type de panne le
plus catastrophique.
Les diffrents types de panne sont de frquence trs diffrente. Par exemple, les deux
premiers peuvent survenir plusieurs fois par minute alors quune panne systme apparat en gnral plusieurs fois par mois et quune panne mmoire secondaire narrive
que quelquefois par an, voire moins. Aussi, seul le dernier type de panne conduit
faire appel aux archives et peut savrer, dans certains cas trs rares, non rcuprable.

6.2. OBJECTIFS DE LA RSISTANCE AUX PANNES

Lobjectif essentiel est de minimiser le travail perdu tout en assurant un retour des
donnes cohrentes aprs pannes. Compte tenu de laspect non instantan de lapparition dune panne et de sa dtection, nous considrerons gnralement que la transaction est lunit de traitement atomique, ou si lon prfre lunit de reprise.
Cependant, ceci nest pas toujours vrai et une unit plus faible a t retenue dans les
systmes bass sur SQL laide de la notion de point de reprise de transaction (savepoint). Une transaction est divise en tapes, encore appeles units duvre (voir
figure XVI.31). Latomicit de chaque unit duvre doit tre garantie par le systme
transactionnel. Une panne de transaction provoque le retour au dernier point de
reprise de la transaction. Lexcution dun point de reprise permet de conserver les
variables en mmoire de la transaction, bien que la reproductibilit des lectures ne soit
en gnral pas garantie entre les units duvre. Dans la suite, pour simplifier, nous
ne considrerons en gnral que des transactions composes dune seule unit
duvre.
Begin_Trans
update
update

unit d'uvre
Non-perte du contexte

savepoint
update
update

unit d'uvre

End_Trans

Figure XVI.31 : Transaction compose dunits duvre multiples

Gestion de transactions 619

Les objectifs premiers de la rsistance aux pannes sont de fournir un protocole aux
applications permettant dassurer latomicit. Pour ce faire, une application doit pouvoir commencer lexcution dune transaction et la terminer avec succs ou par un
chec. Des actions atomiques sont ainsi fournies par le systme de gestion de transactions aux applications. En plus de la cration dune transaction, ces actions correspondent aux trois notions de validation (encore appele commitment, consolidation ou
confirmation), dannulation (encore appele abort ou abandon ou retour arrire) et de
reprise (encore appele restauration ou redo). Nous dfinissons ci-dessous ces trois
notions.
Notion XVI.17 : Validation de transaction (Transaction commitment)
Action atomique spciale (appele Commettre ou Commit), excute en fin de transaction, provoquant lintgration dfinitive de toutes les mises jour non encore commise de la transaction excutante dans la base de donnes.

La validation est donc la terminaison avec succs dune transaction. Dans le cas de
transactions composes de plusieurs units duvre, une validation est effectue la
fin de chaque unit duvre. Loppos de la validation est lannulation.
Notion XVI.18 : Annulation de transaction (Transaction abort)
Action atomique spciale (appele Annuler ou Dfaire ou Abort ou Undo), gnralement excute
aprs une dfaillance, provoquant lannulation de toutes les mises jour de la base effectues par
la transaction et non encore commises.

Notez que seules les transactions non valides peuvent tre annules. Dfaire une
transaction valide est une opration impossible sauf utiliser des versions antrieures de la base. Par contre, une transaction dfaite peut tre refaite (on dit aussi
rejoue) : cest lobjet de la reprise.
Notion XVI.19 : Reprise de transaction (Transaction redo)
Excution dune action spciale (appele Refaire ou Redo) qui refait les mises jour dune transaction prcdemment annule dans la base de donnes.

La reprise peut seffectuer partir de journaux des mises jour, comme nous le verrons ci-dessous. Elle peut aussi ncessiter une nouvelle excution de la transaction.

6.3. INTERFACE APPLICATIVE TRANSACTIONNELLE

La mise disposition des fonctionnalits de validation, annulation et reprise a ncessit le dveloppement dune interface entre les applications et le systme transactionnel. Cette interface a t standardise par lX/OPEN dans le cadre de larchitecture

620 BASES DE DONNES : OBJET ET RELATIONNEL

DTP (Distributed Transaction Processing). Pour des transactions simples, elle se

rsume trois actions de base :
Trid Begin (context) permet de dbuter une transaction en fournissant un
contexte utilisateur ; elle retourne un identifiant de transaction Trid ;
Commit (TrId) valide la transaction dont lidentifiant est pass en paramtre ;
Abort(TrId) annule la transaction dont lidentifiant est pass en paramtre.
Des points de sauvegardes peuvent tre introduits, comme vu ci-dessus avec les oprations :
SaveId Save(TrId) dclare un point de sauvegarde pour la transaction et
demande la validation de lunit duvre en cours ; elle retourne un identifiant de
point de sauvegarde ;
Rollback (Trid, SaveId) permet de revenir au point de sauvegarde rfrenc, en gnral le dernier.
Quelques oprations de service supplmentaires sont proposes, telles par exemple :
ChainWork (context) valide la transaction en cours et ouvre une nouvelle
transaction ;
TrId MyTrId() retourne lidentifiant de la transaction qui lexcute ;
Status(TrId) permet de savoir quel est ltat de la transaction rfrence en
paramtre ; elle peut tre active, annule, commise, en cours dannulation ou de
validation.
En rsum, lobjectif dun systme transactionnel au sein dun SGBD est de raliser
efficacement les oprations prcdentes. En plus, celui-ci doit bien sr intgrer un
contrle de concurrence correct et efficace.

6.4. LMENTS UTILISS POUR LA RSISTANCE

AUX PANNES
Nous dcrivons maintenant les diffrents lments utiliss pour la validation et la
reprise de transactions.

6.4.1. Mmoire stable

Avant tout, il est ncessaire de disposer de mmoires secondaires fiables et sres. Plus
prcisment, la notion de mmoire stable recouvre lespace disque qui nest ni perdu
ni endommag lors dune panne simple, daction, de transaction ou de systme. La
mmoire stable est organise en pages. Une criture de page dans la mmoire stable
est atomique : une page est soit correctement crite sur mmoire secondaire, soit pas
du tout ; elle ne peut tre douteuse ou partiellement crite. De plus, si elle est crite,

Gestion de transactions 621

elle ne peut tre dtruite que par une panne catastrophique explicite ou par une rcriture.
Notion XVI.20 : Mmoire stable (Stable store)
Mmoire dcoupe en pages dans laquelle une criture de page est soit correctement excute, soit
non excute, garantissant la mmorisation de la page jusqu rcriture, donc sa non perte suite
des pannes simples.

Dans les SGBD, la mmoire stable est le disque ; il permet de mmoriser les donnes
persistantes. La ralisation dune mmoire sre garantissant latomicit des critures nest
pas triviale. Les techniques utilises sont en gnral les codes de redondances, ainsi que
les doubles critures. Dans la suite, nous considrons les mmoires stables comme sres.

6.4.2. Cache volatile

Les SGBD utilisent des caches des bases de donnes en mmoire afin damliorer les
performances. Comme vu ci-dessus, la mmoire centrale peut tre perdue en cas de
panne systme : le cache est donc une mmoire volatile.
Notion XVI.21 : Cache volatile (Transient cache)
Zone mmoire centrale contenant un cache de la base, considre comme perdue aprs une panne
systme.

Les transactions actives excutent des mises jour dont leffet apparat dans le cache
et nest pas instantanment report sur disque. En thorie, leffet dune transaction
devrait tre report de manire atomique lors de la validation. La figure XVI.32
illustre les mouvements entre mmoire volatile (le cache) et mmoire stable souhaitables lors de la validation ou de lannulation.
Cache volatile
Update
Update

Commit
Abort

Bases de donnes

Nant

Figure XVI.32 : Mouvements de donnes entre cache et mmoire stable

622 BASES DE DONNES : OBJET ET RELATIONNEL

Ceci est la vue logique donne lutilisateur. En pratique, les mcanismes pour assurer un tel fonctionnement logique sont plus complexes.

6.4.3. Journal des mises jour

un instant donn, ltat de la base est dtermin par ltat de la mmoire stable et
ltat du cache. En effet, des mises jour ont t effectues et ne sont pas encore
reportes sur disque. Certaines effectues par des transactions venant juste dtre valide peuvent tre en cours de report. Il faut cependant garantir la non-perte de mise
jour des transactions commises en cas de panne. Si le systme reporte des pages dans
la mmoire stable avant validation dune transaction, par exemple pour librer de la
place dans le cache, il faut tre capable de dfaire les reports de pages contenant des
mises jour de transactions annules.
La mthode la plus classique pour permettre la validation atomique, lannulation et la
reprise de transaction consiste utiliser des journaux [Verhofstad78]. On distingue le
journal des images avant et le journal des images aprs, bien que les deux puissent
tre confondus dans un mme journal.
Notion XVI.22 : Journal des images avant (Before image log)
Fichier systme contenant dune part les valeurs (images) avant modification des pages mises
jour, dans lordre des modifications avec les identifiants des transactions modifiantes, ainsi que des
enregistrements indiquant les dbuts, validation et annulation de transactions.

Le journal des images avant est utilis pour dfaire les mises jour dune transaction
(undo). Pour cela, il doit tre organis pour permettre daccder rapidement aux enregistrements correspondant une transaction. Un fichier hach sur lidentifiant de transaction (TrId) sera donc opportun.
Notion XVI.23 : Journal des images aprs (After image log)
Fichier systme contenant dune part les valeurs (images) aprs modifications des pages mises
jour, dans lordre des modifications avec les identifiants des transactions modifiantes, ainsi que des
enregistrements indiquant les dbuts, validation et annulation de transactions.

Le journal des images aprs est utilis pour refaire les mises jour dune transaction
(redo). Comme le journal des images aprs, il doit tre organis pour permettre
daccder rapidement aux enregistrements correspondant une transaction. Un fichier
hach sur lidentifiant de transaction (TrId) sera donc opportun.
En guise dillustration, la figure XVI.33 reprsente un enregistrement dun journal
contenant la fois les images avant et aprs. Les enregistrements sont prcds dune
lettre R (Redo) pour les images aprs, U (Undo) pour les images avant, et T
(Transaction) pour les changements dtats des transactions.

Gestion de transactions 623

(a) Types d enregistrements

Transactions

Undo

Redo

<Trid-T-{D, C, A}>

<Trid-U-TID-[Ai=valeur]*>

<Trid-R-TID-[Ai=valeur]*>

(b) Exemple de journal

T10-T-D; T10-U-t100-A4=5; T11-T-D; T10-R-t100-A4=7;

T10-T-C; T11-U-t150-A2=7; T11-T-A; T12-T-D; T12-U-t120-A2=7;

Figure XVI.33 : Enregistrements dans le journal global

Comme indiqu ci-dessus, les modifications sont tout dabord excutes dans des
caches en mmoire. Ces caches sont volatils, cest--dire perdus lors dune panne. Ce
nest bien souvent que lors de la validation que les mises jour sont enregistres dans
le journal et dans la base. Afin dtre capable dannuler une transaction dans tous les
cas, il faut crire les enregistrements dans le journal avant de reporter le cache dans la
base, comme illustr figure XVI.34.
Journal
2.Log

Page lue

4.Log

3.Update

1.Read

Page modifie

5.Write

Base persistante

Figure XVI.34 : Ordre denregistrement des mises jour

Lordre dans lequel les oprations doivent tre accomplies est indiqu sur la figure.
Les rgles suivantes sont souvent conseilles [Bernstein87] :
1. Avant dcrire une page modifie en mmoire stable, il faut enregistrer son image
avant dans le journal (pour pouvoir dfaire) ainsi que son image aprs (pour pou-

624 BASES DE DONNES : OBJET ET RELATIONNEL

voir refaire). Cette rgle est connue sous le nom de journalisation avant criture
(log ahead rule).
2. Toutes les pages modifies en mmoire volatile par une transaction doivent tre
crites en mmoire stable, donc sur disque, avant la validation de la transaction.
Cette dernire rgle est connue sous le nom de validation aprs criture (commit
after rule).
Lapplication de ces deux rgles conduit naturellement enregistrer journal puis page
modifie sur disques soit chaque mise jour, soit en fin de transaction avant le commit effectif. Elles sont donc trs limitatives. En consquence, la premire est gnralement suivie pour viter de ne pouvoir dfaire des transactions non valides ou refaire
des valides. La seconde peut tre relaxe avec quelques prcautions. Dans certains
cas, par exemple si les journaux sont doubls ou si la base est double par une base
miroir, ces deux rgles peuvent tre remplaces par des rgles plus souples.
Lutilisation dun journal cote trs cher : chaque mise jour ncessite a priori trois
entres-sorties. Afin damliorer les performances, les enregistrements du journal sont
gnralement gards dans un tampon en mmoire et vids sur disques lorsque le tampon est plein. Malheureusement, il faut crire le journal avant dcrire dans la base
pour pouvoir dfaire ou refaire les mises jour de la mmoire stable. La technique
utilise pour rsoudre ce problme consiste bloquer ensemble plusieurs validations
de transactions.
Notion XVI.24 : Validation bloque (Blocked commit)
Technique consistant valider plusieurs transactions ensemble pour pouvoir crire ensemble les
enregistrements dans le journal.

Ainsi, le systme peut attendre quun tampon du journal soit plein avant de le vider.
Lorsquune transaction commet, si le tampon nest pas plein, elle attend que dautres
transactions effectuent des mises jour pour remplir le tampon. Si le systme est peu
actif, un dlai maximal (time out) permet de forcer le vidage du tampon journal.
Soulignons que le journal est en gnral compress, pour rduire sa taille au maximum et aussi maximiser le nombre de transactions commises simultanment.
Un dernier problme concernant le journal est celui de sa purge. En effet, on ne peut
enregistrer indfiniment les enregistrements tudis sur un disque dans un fichier
hach. Mme avec du hachage extensible, le fichier risque de devenir important et difficile grer. En consquence, les systmes changent priodiquement de fichier journal. Il est possible par exemple de tourner sur N fichiers hachs, en passant au suivant
chaque fois que lun est plein ou au bout dune priode donne. Un fichier journal qui
nest plus actif est vid dans une archive. Il sera rutilis plus tard pour une nouvelle
priode de journalisation.

Gestion de transactions 625

6.4.4. Sauvegarde des bases

En cas de perte de la mmoire stable, donc dune panne des disques en gnral, il faut
pouvoir retrouver une archive de la base dtruite. Pour cela, des sauvegardes doivent
tre effectues priodiquement, par exemple sur un disque spar ou sur bandes
magntiques.
Notion XVI.25 : Sauvegarde (Backup copy)
Copie cohrente dune base locale effectue priodiquement alors que cette base est dans un tat
cohrent.

Une sauvegarde peut par exemple tre effectue en dbut de chaque semaine, de
chaque journe, de chaque heure. La prise de sauvegarde pendant le fonctionnement
normal du systme est un problme difficile. Pour cela, un mcanisme de verrouillage
spcifique ou mieux, un mcanisme de multi-versions [Reed79] peut tre utilis.

6.4.5. Point de reprise systme

Aprs un arrt normal ou anormal du systme, il est ncessaire de repartir laide
dun tat machine correct. Pour cela, on utilise en gnral des points de reprise systme.
Notion XVI.26 : Point de reprise systme (System checkpoint)
Etat davancement du systme sauvegard sur mmoires secondaires partir duquel il est possible
de repartir aprs un arrt.

Les informations sauvegardes sur disques comportent en gnral limage de la

mmoire, ltat des travaux en cours et les journaux. Un enregistrement point de
reprise systme est crit dans le journal. Celui-ci est recopi partir des fichiers le
contenant. Lors dune reprise, on repart en gnral du dernier point de reprise systme. Plus ce point de reprise est rcent, moins le dmarrage est coteux, comme nous
le verrons ci-dessous.

7. VALIDATION DE TRANSACTION
Comme indiqu ci-dessus, la validation de transaction doit permettre dintgrer toutes
les mises jour dune transaction dans une base de donnes de manire atomique,
cest--dire que toutes les mises jour doivent tre intgres ou quaucune ne doit
ltre. Latomicit de la validation de transaction rend les procdures dannulation de

626 BASES DE DONNES : OBJET ET RELATIONNEL

transactions non valides simples. Le problme est donc de raliser cette atomicit.
Plusieurs techniques ont t introduites dans les systmes afin de raliser une validation atomique. Elles peuvent tre combines afin damliorer la fiabilit [Gray81]. La
plupart des SGBD combinent dailleurs les critures en place et la validation en deux
tapes.

7.1. CRITURES EN PLACE DANS LA BASE

Avec cette approche, les critures sont effectues directement dans les pages de la
base contenant les enregistrements modifis. Elles sont reportes dans la base au fur et
mesure de lexcution des commandes Insert, Update et Delete des transactions. Ce
report peut tre diffr mais doit tre effectu avant la validation de la transaction.
Comme vu ci-dessus, les mises jour dune transaction sont crites dans le journal
avant dtre mises en place dans la base de donnes. Latomicit de la validation
dune transaction est ralise par criture dun enregistrement dans le journal
[Verghofstad78]. Les critures restent invisibles aux autres transactions tant quelles
ne sont pas valides ; pour cela, les pages ou les enregistrements sont verrouills au
fur et mesure des critures. La validation proprement dite consiste crire dans le
journal un enregistrement transaction valide . Ensuite, les mises jour sont rendues visibles aux autres transactions.
Dans tous les cas, la validation dune transaction ayant mis jour la base de donnes
gnre un nouvel tat, ainsi que des enregistrements dans le journal (images des pages
modifies et enregistrement transaction valide), comme indiqu figure XVI.35.
Ancien
tat

Validation

Nouvel
tat

Enregistrements
dans le journal

Nouvel
tat

Annulation

Ancien
tat

Enregistrements
dans le journal

Figure XVI.35 : Principes de la validation et de lannulation avec journal

Gestion de transactions 627

Lannulation dune transaction ayant mis en place des mises jour dans la base est
une procdure difficile. Elle seffectue partir du journal des images avant. Lannulation ncessite le parcours du journal lenvers, cest--dire en reculant dans le temps.

7.2. CRITURES NON EN PLACE

Avec cette approche, les pages modifies sont recopies dans de nouvelles pages en
mmoire et crites dans de nouveaux emplacements dans la base. Latomicit de la
validation dune transaction peut tre ralise par la technique des pages ombre
[Lorie77]. Les pages nouvelles spares et attaches la transaction modifiante sont
appeles pages diffrentielles. Les pages anciennes constituent les pages ombre.
Avant toute lecture, il faut alors que le SGBD consulte les pages diffrentielles valides et non encore physiquement intgres la base. Cela conduit alourdir les procdures de consultation et accrotre les temps de rponse.
Une solution plus efficace a t proposes dans [Lampson76]. Elle consiste raliser
une intgration physique atomique par basculement des tables des pages (voir
figure XVI.34). Pour cela, chaque fichier de la base de donnes possde un descripteur pointant sur la table des pages du fichier. Quand une transaction dsire modifier
un fichier, une copie de la table des pages est effectue et les adresses des pages modifies sont positionnes leurs nouvelles valeurs, de sorte que la copie de la table des
pages pointe sur la nouvelle version du fichier (anciennes pages non modifies et nouvelles pages modifies). La validation consiste alors simplement mettre jour le
descripteur du fichier en changeant ladresse de la table des pages.
Table des pages ombres

Nom
Fichier
Adresse
Table des Pages

Validation
Page ombre

Page ombre

Nouvelle table des pages

Nouvelles pages

Figure XVI.36 : Validation par basculement de la table des pages

628 BASES DE DONNES : OBJET ET RELATIONNEL

7.3. VALIDATION EN DEUX TAPES

Dans la plupart des systmes, un ensemble de processus collabore la vie dune transaction. Afin de coordonner la dcision de valider une transaction, un protocole de
validation en deux tapes est gnralement utilis. Ce protocole a t propos dans
un contexte de systme rparti [Lampson76, Gray78] mais est aussi utile dans un
contexte centralis multi-processus. La validation en deux tapes peut tre perue
comme une mthode de gestion des journaux. Lors de la premire tape, les images
avant et aprs sont enregistres dans le journal si bien quil devient ensuite possible de
valider ou dannuler la transaction quoi quil advienne (except une perte du journal) ;
cette tape est appele prparation la validation. La seconde tape est la ralisation
de la validation ou de lannulation atomique, selon que la premire tape sest bien ou
mal passe. La preuve de correction dun tel protocole dborde le cadre de cet
ouvrage et pourra tre trouve dans [Baer81].
Le protocole de validation en deux phases coordonne lexcution des commandes
COMMIT par tous les processus cooprant lexcution dune transaction. Le principe consiste diviser la validation en deux phases. La phase 1 ralise la prparation
de lcriture des rsultats des mises jour dans la BD et la centralisation du contrle.
La phase 2, ralise seulement en cas de succs de la phase 1, intgre effectivement
les rsultats des mises jour dans la BD rpartie. Le contrle du systme est centralis
sous la direction dun processus appel coordinateur, les autres tant des participants. Nous rsumons ces concepts ci-dessous.
Notion XVI.27 : Protocole de validation en deux tapes (Two Phase Commit)
Protocole permettant de garantir latomicit des transactions dans un systme multi-processus ou
rparti, compos dune prparation de la validation et de centralisation du contrle, et dune tape
dexcution.
Notion XVI.28 : Coordinateur de validation (Commit Coordinator)
Processus dun systme multi-processus ou rparti qui dirige le protocole en centralisant le contrle.
Notion XVI.29 : Participant validation (Commit Participant)
Processus dun systme multi-processus ou rparti qui excute des mises jour de la transaction et
obit aux commandes de prparation, validation ou annulation du coordinateur.

Le protocole de validation en deux tapes dcoule des concepts prcdents. Lors de

ltape 1, le coordinateur demande aux autres sites sils sont prts commettre leurs
mises jour par lintermdiaire du message PREPARER (en anglais PREPARE). Si
tous les participants rpondent positivement (prt), le message VALIDER (en anglais
COMMIT) est diffus : tous les participants effectuent leur validation sur ordre du
coordinateur. Si un participant nest pas prt et rpond ngativement (KO) ou ne
rpond pas (time out), le coordinateur demande tous les participants de dfaire la
transaction (message ANNULER, en anglais ABORT).

Gestion de transactions 629

Le protocole ncessite la journalisation des mises jour prpares et des tats des
transactions dans un journal local chaque participant, ceci afin dtre capable de
retrouver ltat dune transaction aprs une ventuelle panne et de continuer la validation ventuelle. Le protocole est illustr figure XVI.37 dans le cas favorable o un site
client demande la validation deux sites serveurs avec succs. Notez quaprs excution de la demande de validation (VALIDER), les participants envoient un acquittement (FINI) au coordinateur afin de lui signaler que la transaction est maintenant termine.
Coordinateur
Participant 1

prparer

prparer

prt

prt

valider

valider

fini

fini

Participant 2

Figure XVI.37 : Validation en deux tapes avec succs

Le cas de la figure XVI.38 est plus difficile : le participant 2 est en panne et ne peut
donc rpondre au message de demande de prparation. Une absence de rponse est
assimile un refus. Le coordinateur annule donc la transaction et envoie le message
ANNULER. Le participant 1 annule la transaction. Le participant 2 lannulera
lorsquil repartira aprs la panne, une transaction non prte tant toujours annule.
Coordinateur
Participant 1

prparer
prt
abandon

prparer
timeout

Participant 2

panne

abandon

fini
fini

reprise

Figure XVI.38 : Validation en deux tapes avec panne totale du participant 2

630 BASES DE DONNES : OBJET ET RELATIONNEL

Le cas de la figure XVI.39 est encore plus difficile : le participant 2 tombe en panne
aprs avoir rpondu positivement la demande de prparation. Le coordinateur
envoie donc le message COMMIT qui nest pas reu par le participant 2.
Heureusement, celui-ci a d sauvegarder ltat de la sous-transaction et ses mises
jour dans un journal fiable sur disque. Lors de la procdure de reprise, le journal sera
examin. La transaction tant dtecte prte commettre, son tat sera demand au
coordinateur (ou a un participant quelconque) par un message appel STATUS. En
rponse ce message, la validation sera confirme et les mises jour seront appliques partir du journal. Les deux sous-transactions seront donc finalement valides.
Coordinateur
Participant 1

prparer

prparer

prt

prt

valider

valider

fini
prt

Participant 2

panne
reprise

valider
prt

Figure XVI.39 : Validation en deux tapes avec panne partielle du participant 2

Au-del du protocole en deux tapes, il existe des protocoles en trois tapes qui vitent les blocages du protocole prcdent en cas de panne du coordinateur. Le plus courant est le protocole dit dabort suppos, qui en cas de panne du coordinateur suppose
labandon de la transaction. Ceci est mme possible en deux phases [Mohan86].
Le protocole en deux tapes a t standardis par lISO. TP est le protocole standard
propos par lISO dans le cadre de larchitecture OSI afin dassurer une validation
cohrente des transactions dans un systme distribu. Le protocole est arborescent en
ce sens que tout participant peut dclencher une sous-transaction distribue. Un site
responsable de la validation de la sous-transaction est choisi. Un coordinateur est responsable de ses participants pour la phase 1 et collecte les PREPARE. Il demande
ensuite la validation ou labort selon la dcision globale un site appel point de validation qui est responsable de la phase 2 : cest le point de validation qui envoie les
COMMIT aux participants. Lintrt du protocole, outre laspect hirarchique, est que
le point de validation peut tre diffrent du coordinateur : ce peut tre un nud critique dans le rseau dont la prsence la validation est ncessaire. La figure XVI.40
illustre ce type de protocole hirarchique avec point de validation.

Gestion de transactions 631

Coordinateur global

Coordinateur
local
Coordinateur
local

Point de validation
(Nud critique)

Figure XVI.40 : Le protocole hirarchique avec point de validation TP

8. LES PROCDURES DE REPRISE

Dans cette section, nous examinons les procdures de reprises. Aprs quelques considrations gnrales, nous introduisons divers protocoles de reprise possibles
[Bernstein87].

8.1. PROCDURE DE REPRISE

On appelle procdure de reprise la procdure excute lors du redmarrage du systme aprs un arrt ou une panne. Plusieurs types de reprises sont distingus et un
schma de principe possible pour chaque type est tudi ci-dessous. Ces procdures
consistent repartir partir du journal et ventuellement de sauvegardes, pour reconstituer une base cohrente en perdant le minimum du travail excut avant larrt. Afin
de prciser les ides, nous dfinissons la notion de procdure de reprise.
Notion XVI.30 : Procdure de reprise (Recovery procedure)
Procdure systme excute lors du redmarrage du systme ayant pour objectif de reconstruire
une base cohrente aussi proche que possible de ltat atteint lors de la panne ou de larrt du systme.

La reprise normale ne pose pas de problme. Elle a lieu aprs un arrt normal de la
machine. Lors de cet arrt, un point de reprise systme est crit comme dernier enre-

632 BASES DE DONNES : OBJET ET RELATIONNEL

gistrement du journal. La reprise normale consiste simplement restaurer le contexte

dexcution sauvegard lors de ce point de reprise. Une telle procdure est excute
lorsque le dernier enregistrement du journal est un point de reprise systme.

8.2. REPRISE CHAUD

La reprise aprs une panne du systme est appele reprise chaud. Rappelons
quune panne systme entrane la perte de la mmoire centrale sans perte de donnes
sur mmoires secondaires. Dans ce cas, le systme doit rechercher dans le journal le
dernier point de reprise systme et restaurer ltat machine associ. Le journal est
alors trait en avant partir du point de reprise afin de dterminer les transactions
valides et celles non encore valides (appeles respectivement gagnantes et perdantes
dans [Gray81]). Puis le journal est trait en sens inverse afin de dfaire les mises
jour des transactions non valides (les perdantes). Une telle procdure est illustre
figure XVI.41.
Journal
POINT DE REPRISE SYSTEME
Dbut transaction i
M1 (i)
Dbut transaction i+1
M1 (i+1)
Dbut transaction i+2
M1 (i+2)
M2 (i)
Base au moment du
redmarrage

Validation transaction i
M2 (i+1)
Dbut transaction i+3
M1 (i+3)
M2 (i+3)
M2 (i+2)
Validation transaction i+2
M3 (i+1)

Base au moment de
la panne

PANNE

Figure XVI.41 : Exemple de reprise chaud

Gestion de transactions 633

Les transactions i et (i+2) sont gagnantes alors que (i+1) et (i+3) sont perdantes.
Mj(i) dsigne la je mise jour de la transaction i. Les mises jour dfaites sont marques par une flche.
Cette procdure est excute lors des redmarrages du systme quand le dernier enregistrement du journal nest pas un point de reprise et que loprateur ne signale pas
une perte de mmoire secondaire.

8.3. PROTOCOLES DE REPRISE CHAUD

Lors dune reprise chaud, il est gnralement ncessaire de dfaire (Undo) des transactions non commises et refaire (Redo) des transactions commises. Cependant, diffrents protocoles sont applicables selon les cas indiqus figure XVI.42. Les conditions
indiques en colonne portent sur les mises jour des transactions commises, celles en
ligne portent sur les mises jour des transactions non commises au moment de la
panne. Les actions ncessaires sur les transactions excutes depuis le dernier point de
reprise systme sont indiques au carrefour de la ligne et de la colonne, quand les
deux conditions sont vrifies.
Non commises
Commises
Certaines mise jour
en base
Toute mise jour
en base

Pas de mise jour

en base

Certaines mises jour

en base

No Undo, Redo
(1)

Undo, Redo
(2)

No Undo, No Redo
(3)

Undo, No Redo
(4)

Figure XVI.42 : Protocoles de reprise chaud possibles

Les renvois numriques du tableau ci-dessus correspondent aux protocoles suivants :

1. Le protocole Refaire sans Dfaire (No Undo, Redo) est applicable dans le cas o
lon est sr que toute transaction non commise na aucune mise jour installe en
base permanente. Lapplication dun tel protocole ncessite donc le report des mises
jour dune transaction simultanment ou aprs lcriture de lenregistrement
COMMIT pour cette transaction dans le journal. La simultanit ncessite un matriel spcial capable dassurer latomicit de plusieurs mises jour simultanes de
disques diffrents. Diffrer les mises jour en base aprs la validation relche la
rgle de la validation aprs critures vue ci-dessus.
2. Le protocole Dfaire et Refaire (Undo, Redo) est le plus classique. Il est appliqu
dans le cas o certaines mises jour de transactions non commises peuvent tre

634 BASES DE DONNES : OBJET ET RELATIONNEL

enregistres dans la base et certaines mises jour de transactions commises peuvent

tre perdues dans la base. Il est gnral et est le plus frquemment utilis. Il ne
ncessite pas de diffrer les mises jour en base permanente.
3. Le protocole Dfaire sans Refaire (Undo, No Redo) est applicable dans le cas o
lon est sr que toute transaction commise a toutes ses mises jour reportes en
base permanente. Ce peut tre vrai si le systme respecte la rgle de validation
aprs report des critures vue ci-dessus.
4. Le protocole Ni Refaire Ni Dfaire (No Undo, No Redo) est rarement applicable.
Il ncessite que toute transaction commise ait toutes ses mises jour en base permanentes et que toute transaction non commise nait aucune de ses mises jour en
base permanentes. Il faut pour cela un matriel spcifique capable dexcuter toutes
les critures la fois et de garantir latomicit de ces critures multiples.

8.4. REPRISE FROID ET CATASTROPHE

La reprise aprs une panne de mmoire secondaire est plus difficile. Ce type de
reprise est souvent appel reprise froid. Une telle reprise est excute lorsquune
partie des donnes est perdue ou lorsque la base est devenue incohrente. Dans ce cas,
une sauvegarde cohrente de la base ainsi que le journal des activits qui ont suivi
sont utiliss afin de reconstruire la base actuelle. Il suffit pour cela dappliquer les
images aprs partir de la sauvegarde et du point de reprise associ. Lorsque le journal a t parcouru en avant jusqu la fin, la reprise froid enchane en gnral sur
une reprise chaud.
Une panne catastrophique survient quand tout ou partie du journal sur mmoire
secondaire est perdu. Certains systmes, tel systme R, permettent de grer deux
copies du journal sur des mmoires secondaires indpendantes afin de rendre trs peu
probable un tel type de panne. Dans le cas o cependant une telle panne survient, il
nexiste gure dautre solution que dcrire des transactions spciales charges de tester la cohrence de la base en dialoguant avec les administrateurs et de compenser les
effets des mises jour malheureuses.

9. LA MTHODE ARIES
ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) [Mohan92] est
une des mthodes de reprise de transactions des plus efficaces. Elle est la base des
algorithmes de reprises implments dans de nombreux systmes, dont ceux des
SGBD dIBM. Ralise dans le cadre du projet de SGBD extensible dIBM Starburst,
cette mthode sest impose comme une des meilleures mthodes intgres.

Gestion de transactions 635

9.1. OBJECTIFS
Les objectifs essentiels initiaux de la mthode taient les suivants [Mohan92] :
Simplicit. Vu la complexit du sujet, il est essentiel de viser la simplicit de
sorte tre applicable en vraie grandeur et garantir des algorithmes robustes.
Cest dailleurs vrai pour tous les algorithmes, au moins en systme.
Journalisation de valeur et dopration. Classiquement, ARIES permet de dfaire
et refaire une mise jour avec les images avant et aprs. Au-del, la mthode
intgre la possibilit de journaliser des oprations logiques, comme incrment et
dcrment dun compte. Cela permet le verrouillage smantique avec des modes
doprations sophistiqus, pour supporter des excutions oprations commutatives
non srialisables au niveau des lectures et critures. Ceci est important pour permettre une meilleure concurrence, comme vu ci-dessus. Une des difficults dans ce
type de journalisation par opration est de bien associer un enregistrement du journal avec ltat de la page qui lui correspond : ceci est accompli astucieusement avec
un numro de squence denregistrement journal (Log Sequence Number, LSN)
mmoris dans la page. Une autre difficult est due aux pannes pendant la reprise :
il faut pouvoir savoir si lon a refait ou non une opration. Ceci est accompli en
journalisant aussi les mises jour effectues pendant la reprise par des enregistrements de compensation (Compensation Log Records, CRLs).
Gestion de mmoire stable et du cache flexible. La mmoire stable est gre efficacement. Diffrentes stratgies de report du cache sont utilisables. Reprise et verrouillage sont logiques par nature ; cela signifie que la reprise reconstruit une base
cohrente qui nest pas forcment physiquement identique la base perdue (pages
diffrentes), mais aussi que les verrouillages sont effectus des niveaux de granularits variables, en utilisant le verrouillage dintention vu ci-dessus.
Reprise partielle de transactions. Un des objectifs de la mthode est de pouvoir
dfaire une transaction jusquau dernier point de sauvegarde. Cest important pour
pouvoir grer efficacement les violations de contraintes dintgrit et lutilisation de
donnes primes dans le cache.
Reprise granulaire oriente page. La mthode permet de reprendre seulement une
partie de la base, la reprise dun objet (une table par exemple) ne devant pas impliquer la reprise dautres objets. La reprise est oriente page en ce sens que la granularit de reprise la plus fine est la page : si une seule page est endommage, il doit
tre possible de la reconstruire seule.
Reprise efficace et rapide. Il sagit bien sr davoir de bonnes performances, la
fois pendant lexcution normale de transactions et pendant la reprise. Lide est de
rduire le nombre de pages rcrire sur disques et le temps unit central ncessaire
la reprise.
Outre ces quelques objectifs, ARIES en a atteint de nombreux autres tels que lespace
disque minimal ncessaire en dehors du journal, le support dobjets multi-pages, la

636 BASES DE DONNES : OBJET ET RELATIONNEL

prise de points de reprise systme efficaces, labsence de verrouillage pendant la

reprise, le journal limit en cas de pannes multiples lors de la reprise, lexploitation du
paralllisme possible, etc. [Mohan92].

9.2. LES STRUCTURES DE DONNES

ARIES gre un journal unique. Le format dun enregistrement est reprsent
figure XVI.43.
LSN

Log Sequence Number : Adresse relative du premier octet de lenregistrement

dans le log, utilis comme identifiant de lenregistrement (non mmoris).

TYPE

Record type : Indique sil sagit dun enregistrement de compensation,

dun enregistrement de mise jour normal, dun enregistrement de validation
deux tapes (prt, commise) ou dun enregistrement systme (checkpoint).

PrevLSN

Previous LSN : LSN de lenregistrement prcdent pour la transaction

sil y en a un.

TransID

Transaction ID : Identifiant de la transaction qui a crit lenregistrement.

PageID

Page ID : Identifiant de la page laquelle les mises jour de lenregistrement

sappliquent, si elle existe.
Prsent seulement pour les enregistrements de mise jour ou de compensation.

UndoNxtLSN Undo next LSN : LSN de lenregistrement suivant traiter pendant la reprise
arrire.
Prsent seulement pour les enregistrements de compensation.
Data

Data : Donnes dcrivant la mise jour qui a t effectue, soit limage avant
et limage aprs, soit lopration et son inverse si elle ne sen dduit pas.
Prsent seulement pour les enregistrements de mise jour ou de compensation
qui nont que les informations pour refaire.

Figure XVI.43 : Format des enregistrements du journal

Pour chaque page de donnes, ARIES ncessite un seul champ par page nomm
page_LSN qui mmorise le numro LSN du dernier enregistrement du journal qui
concerne cette page.
En plus, ARIES gre une table des transactions utilise pendant la reprise pour
mmoriser ltat de validation des transactions actives (Prte ou Non dans le protocole
deux phases), et enfin une table des pages sales, cest--dire modifie en cache et
ne correspondant plus la version sur mmoire stable.

Gestion de transactions 637

9.3. APERU DE LA MTHODE

ARIES garantit latomicit et la durabilit des transactions en cas de panne de processus, de transaction, du systme ou de mmoire secondaire. Pour cela, ARIES utilise
un journal et applique les rgles de journalisation avant criture (Write-Ahead
Loging, WAL) et de validation aprs criture (Write Before Commit, WBC) vues cidessus. ARIES journalise les mises jour effectues par les transactions sur chaque
page. Il journalise aussi les tats prts et valids des transactions gres par un protocole de validation deux tapes, et les points de reprise systme (system checkpoints).
En plus, ARIES journalise les mises jour effectues pour dfaire les transactions,
la fois pendant le fonctionnement normal du systme (par exemple, suite une violation dintgrit) et pendant la reprise. Ces enregistrements spciaux de restauration
sont appels des enregistrements de compensation (Compensation Log Records
CLR). Comme tous les enregistrements, chacun pointe sur lenregistrement prcdent
du journal pour la mme transaction (PrevLSN). Chaque enregistrement de compensation pointe aussi par UndoNxtLSN sur le prdcesseur de lenregistrement juste
dfait. Par exemple, si une transaction a crit les enregistrements normaux 1, 2, 3,
puis 3 et 2 pour compenser respectivement 3 et 2, alors 3 pointe sur 2 et 2 sur 1.
Cela permet de retrouver ce qui a dj t dfait. Si une panne survient pendant une
reprise arrire dune transaction, par exemple aprs excution de 2, grce au journal
on retrouvera 2 puis 1 et lon saura quil suffit de dfaire 1. Ainsi, les enregistrements
de compensation CLR gardent trace des progrs des reprises de transaction et permettent dviter de dfaire ce qui a dj t dfait. Ils permettent aussi de refaire des oprations logiques grce la trace garde.
ARIES marque chaque page avec le dernier LSN lui correspondant dans le journal.
Ainsi, il est possible de retrouver trs rapidement le dernier enregistrement du journal
concernant cette page. Cela permet de connatre prcisment ltat de la page, particulirement de savoir que toutes les mises jour ayant un LSN plus petit ont t correctement enregistres. Cela est un point cl pour les performances de la reprise : on
vite ainsi de r-appliquer des mises jour non perdues.
ARIES utilise des points de reprise systme priodique marquant des points de bon
fonctionnement dans le journal. Un enregistrement point de reprise identifie les transactions actives, leurs tats, le LSN de leur plus rcent enregistrement dans le journal,
et aussi les pages modifies et non reportes sur disques dans le cache (pages sales).
La procdure de reprise dtermine le dernier point de reprise et, dans une premire
passe danalyse, balaye le journal. Grce aux LSN des pages sales figurant dans
lenregistrement point de reprise, le point de reprise exact du journal pour la passe
suivante de rfaction est dtermin. Lanalyse dtermine aussi les transactions
dfaire. Pour chaque transaction en cours, le LSN de lenregistrement le plus rcent
du journal est dtermin. Il est mmoris dans la table des transactions introduites cidessus.

638 BASES DE DONNES : OBJET ET RELATIONNEL

Une deuxime passe de reconstruction est ensuite effectue, durant laquelle ARIES
rpte lhistoire mmorise dans le journal et non enregistre sur mmoire stable.
Ceci est fait pour toutes les transactions, y compris celles qui navaient pas t valides au moment de la panne. Lobjectif est de rtablir ltat de la base au moment de
la panne. Un enregistrement du journal est appliqu en avant (refait) sur une page si
son LSN est suprieur celui de la page, ce qui rduit le nombre de rfactions ncessaires. Durant cette phase, les verrous pour les transactions prtes valider au
moment de la panne sont restaurs, afin de pouvoir les relancer.
Une troisime passe de rparation consiste dfaire les transactions perdantes,
cest--dire celles non valides ou non prtes valider au moment de la panne. Ceci
seffectue par parcours du journal en arrire depuis le plus grand LSN restant traiter
pour les transactions perdantes. Si lenregistrement du journal est un enregistrement
normal, les donnes dannulation (image avant ou opration inverse) sont appliques.
Lenregistrement suivant traiter pour la transaction est alors dtermin en regardant
le champ PrevLSN. Sil sagit dun enregistrement de compensation, il est simplement utilis pour dterminer lenregistrement suivant traiter mmoris dans
UndoNxtLSN, puisque les enregistrements de compensation ne sont jamais compenss.
En rsum, la mthode comporte donc trois passes : analyse, reconstruction en avant
et rparation en arrire. Grce aux chanages intelligents des enregistrements du journal et la mmorisation du numro de squence du dernier enregistrement pertinent
au niveau de chaque page, la mthode vite de refaire et dfaire des mises jour inutilement. Elle intgre aussi la possibilit dannulation logique ou physique doprations,
ce qui permet des verrouillages en modes varis exploitant la commutativit. La
mthode a t implmente dans de nombreux systmes industriels.

10. LES MODLES DE TRANSACTIONS

TENDUS
Nous avons ci-dessus tudi les techniques implmentes dans les SGBD pour assurer
latomicit des transactions. Ces techniques sont aujourdhui bien connues et oprationnelles pour les transactions en gestion. Cependant, les techniques de gestion de
transactions atomiques sont trop limites dans le cas de transactions longues que lon
rencontre en conception (CAO, CFAO), en production de documents (PAO) et plus
gnralement dans les domaines techniques ncessitant des objets complexes. Aussi
diffrents modles de transactions ont-ils t proposs, cherchant permettre une plus
grande flexibilit que le tout ou rien. Ces modles tendent plus ou moins les proprits ACID vues ci-dessus.

Gestion de transactions 639

10.1. LES TRANSACTIONS IMBRIQUES

Le modle des transactions imbriques est d [Moss85]. Il tend le modle plat,
un seul niveau, une structure de transaction niveaux multiples. Chaque transaction
peut tre dcoupe en sous-transactions, et ce rcursivement.
Notion XVI.31 : Transaction imbrique (Nested transaction)
Transaction rcursivement dcompose en sous-transactions, chaque sous-transaction et la transaction globale tant bien forme, cest--dire commenant par BEGIN et se terminant par COMMIT.

On obtient ainsi un arbre de transactions (voir figure XVI.44). Une transaction fille
est lance par sa mre par excution dune commande BEGIN ; elle rend un compterendu sa mre qui se termine aprs toutes ses filles. De manire classique, chaque
(sous-)transaction se termine par COMMIT ou ABORT et est une unit atomique totalement excute ou pas du tout. Chaque (sous-)transaction peut tre refaite (REDO)
ou dfaite (UNDO) par un journal hirarchis.
Begin(T)

Begin(t'1)

Begin(t1)

Commit(t'1)

Commit(t1)
Begin(t2)

Begin(t21)

Commit(t21)

Abort(t2)

Commit(T)

Figure XVI.44 : Exemple de transactions imbriques

Les rgles de validation et dannulation rsultent du dcoupage logique dun travail en

sous-tche :
Lannulation dune transaction mre implique lannulation de toutes ses filles, et ce
rcursivement.

640 BASES DE DONNES : OBJET ET RELATIONNEL

La validation dune transaction fille est conditionne par celle de ses anctres, et ce
rcursivement.
En consquence, bien que chaque transaction se termine par COMMIT ou ABORT, la
validation nest confirme que lorsque tous les anctres ont valid. Le modle ferm
[Moss85] garantit latomicit de la transaction globale. Donc un chec dune soustransaction implique une annulation de la mre. Ceci est trs limitatif, mais conserve
les proprits ACID entre transactions globales. Au contraire, le modle ouvert
relche latomicit de la transaction globale.
Du point de vue de la concurrence, chaque (sous-)transaction applique le verrouillage
deux phases. Les verrous sont hrits dans les deux sens : lorsquune transaction fille
rclame un verrou tenu par un de ses anctres, elle nest pas bloque ; lorsquune transaction fille valide, les verrous quelle a acquis sont transmis sa mre. Deux (sous)transactions peuvent donc se bloquer voir sinterbloquer si le verrou nest pas tenu
par un anctre commun. Ceci complique les dtections de verrous mortels.
Le modle ouvert relche donc la ncessit datomicit des transactions globales.
Alors, une (sous-)transaction peut tre annule alors que sa mre est valide. Le travail
est donc seulement partiellement ralis. Ceci ncessite lintroduction de transactions
de compensation [Korth90]. Par exemple, la compensation dune transaction achetant
de la marchandise consiste rendre cette marchandise. Une (sous-)transaction de compensation dfait donc une (sous-)transaction prcdemment excute. Une variante est
une transaction de complment. Ces transactions de complment viendront plus tard
refaire les portions de travail non valides. Par exemple, le complment dune transaction de mise jour dun ouvrage qui a chou sur le chapitre II est une transaction qui
met jour le chapitre II. Finalement, ds que lon relche latomicit, il est ncessaire
dintroduire de telles transactions dpendant de la smantique de lapplication.
Ces principes ont conduit dfinir un modle de transactions imbriques ouvert trs
flexible [Weikum92]. Outre latomicit, ce modle relche en plus le principe disolation en laissant les rsultats des sous-transactions commises visibles aux transactions
concurrentes. La reprise ncessite alors de grer des sphres dinfluence de transactions, gnralisation de la notion de trane dj vue. La smantique des oprations est
aussi intgre pour grer les commutativits doprations types. De tels modles
commencent tre implments dans les SGBD classiques. Leurs limites et intrts
restent encore mal connus.

10.2. LES SAGAS

Les sagas [Garcia-Molina87] ont t introduites pour supporter des transactions
longues sans trop de blocages. Une saga est une squence de sous-transaction ACID
{T1,, Tn} devant sexcuter dans cet ordre, associe une squence de transactions

Gestion de transactions 641

de compensation {CT1,, CTn}, Cti tant la compensation de Ti. La saga elle-mme

est une transaction longue dcoupe en sous-transactions. Tout abandon dune soustransaction provoque labandon de la saga dans sa totalit. La figure XVI.45 reprsente deux excutions possibles dune saga.
T1

T2

T3

T1

T2

CT2

...

Tn

CT1

Figure XVI.45 : Exemples dexcution de sagas

Lintrt des sagas est de pouvoir relcher le principe disolation. En effet, chaque
transaction composante relche ses verrous ds quelle est termine. Une autre saga
peut alors voir les rsultats. Lannulation de la saga doit donc provoquer lannulation
de lautre saga. Pour cela, il suffit denchaner les transactions de compensation.

10.3. LES ACTIVITS

La gnralisation des sagas conduit au modle dactivits, proche des modles de
workflow. Lide est dintroduire un langage de contrle de transactions permettant de
dfinir des travaux sous la forme dune collection dtapes avec enchanements conditionnels, les tapes tant des transactions et les travaux des activits. Les proprits
souhaitables dune activit sont de pouvoir garder un contexte dexcution persistant,
progresser par le biais de transactions ou reculer par le biais de compensation, essayer
des alternatives et plus gnralement introduire un flot de contrle dpendant des succs et checs des transactions composantes. Il faut aussi pouvoir tre capable de diffrencier les checs systme des checs de programmes, les premiers tant corrigs par
le systme, les seconds par lactivit.
Un exemple typique dactivit est la rservation de vacances. Cette activit est par
exemple compose de trois transactions, la premire T1 ayant une alternative T1 :
1. T1 : rservation avion alternative T1 : location voiture
2. T2 : rservation htel
3. T3 : location voiture
De plus, chaque transaction est associe une transaction de compensation CT1, CT2
et CT3 permettant dannuler son effet.
Cette ide a conduit concevoir des modles et des langages de contrle dactivits
[Dayal91, Wachter92] et implmenter des moniteurs dactivits. Un tel langage per-

642 BASES DE DONNES : OBJET ET RELATIONNEL

met de contrler les transactions par des ordres du type If abort, If commit, Run alternative, Run compensation, etc. Le moniteur contrle les transactions et excute les
programmes de ce langage. On obtient ainsi des systmes de gestion de la coopration
trs flexibles, proches des workflows [Rusinkiewicz95].

10.4. AUTRES MODLES

Un modle bas sur des transactions multi-niveaux a t introduit par [Weikum91,
Beeri88]. Ce modle est une variante du modle des transactions imbriques dans
lequel les sous-transactions correspondent des oprations des niveaux diffrents
dune architecture en couches. Le modle permet de considrer des oprations au
niveau N qui se dcompose en squences doprations au niveau N 1. Par exemple,
le crdit dun compte en banque se dcompose au niveau infrieur (SQL) en une
slection (SELECT) et une mise jour (UPDATE). Ceux-ci se dcomposent leur
tour en lectures et critures de pages au niveau systme. Il est alors possible de
dcomposer une excution simultane de transactions en excution (ou histoire) au
niveau N, N 1, etc. La mthode traditionnelle de gestion de concurrence introduite
ci-dessus ne considre que le niveau le plus bas, des lectures et critures de pages. La
srialisabilit dune excution simultane multi-niveaux est alors dfinie comme la
srialisabilit chaque niveau avec des ordres de srialisation compatibles entre eux.
En considrant la smantique des oprations chaque niveau, il devient possible
dexploiter la commutativit pour tolrer des excutions simultanes qui ne seraient
pas valides si lon ne considrait que le niveau le plus bas. Des contrleurs de transactions peuvent tre dfinis aux diffrents niveaux. Il en rsulte moins de reprise de
transactions.
Le modle split-join [Pu88] est une autre variante des transactions imbriques.
limage des split et join de processus sur Unix, il est possible avec ce modle de
diviser une transaction dynamiquement en deux sous-transactions ou de runir deux
sous-transactions en une. Des rgles strictes sont imposes sur les sous-transactions
pour garantir la srialisabilit globale.
Lintroduction dun arbre de versions dobjet introduit une autre dimension aux
modles de transaction (voir figure XVI.46). La gestion de versions autorise les mises
jour simultanes dun objet. Pour manipuler les versions, deux oprations sont introduites : Check-out pour sortir un objet de la base dans un espace priv et Check-in
pour le rintroduire dans la base. Les objets versionnables sont verrouills pendant
tout le temps de la sortie de la base dans des modes spcifiques drivation partage
ou drivation exclusive. La drivation exclusive ne permet que la sortie dune version un instant donn alors que la drivation partage permet plusieurs sorties simultanes. La figure XVI.47 donne les compatibilits de ces modes.

Gestion de transactions 643

BD PARTAG
Objet
versionnable

CheckOut

V1

Version
personnelle

CheckIn
V2

V3

CheckOut
Version
personnelle

CheckIn
V4

Figure XVI.46 : Exemple dobjet versionnable et dvolution

Lecture

Ecriture

Drivation
Partage

Drivation
Exclusive

Lecture

criture

Drivation
Partage

Drivation
Exclusive

Figure XVI.47 : Compatibilit des oprations de lecture, criture et drivation

Lors de la rinsertion dune version dans la base (Check-in), le graphe de versions est
mis jour et la nouvelle version ajoute comme une fille de celle dont elle drive. Les
versions sont gnralement maintenues en diffrentiel, cest--dire que pour un nud
donn de larbre, seuls les attributs ou pages modifis par rapport au nud pre sont
maintenus. Le problme qui se pose est de faire converger les versions. Si deux versions drivant dun anctre commun nont pas de donnes communes modifies, une
fusion automatique peut tre ralise par intgration de toutes les mises jour effectues lanctre. Sinon, il y a ncessit de dfinir des procdures de rconciliation de
versions, voire dune intervention manuelle effectuant des choix.
Au-del de ces modles fort nombreux, des formalismes de comprhension et description ont t proposs. ACTA [Chrysanthis90] est un cadre pour spcifier et raisonner
sur la structure des transactions et leur comportement. Il permet dexprimer la sman-

644 BASES DE DONNES : OBJET ET RELATIONNEL

tique des interactions entre transactions en termes deffets sur la validation ou lannulation des autres transactions, et sur ltat des objets et des synchronisations ncessaires. Il permet ainsi de dcrire et de raisonner sur un modle dactivit ou de transaction.

11. SCURIT DES DONNES

Dans cette section, nous abordons brivement les problmes de scurit, de plus en
plus importants avec, par exemple, lutilisation des bases de donnes pour le commerce lectronique. Soulignons que les techniques de scurit [Russell91] ne doivent
cesser de progresser pour ne pas sexposer tre dpasses par les escrocs.

11.1. IDENTIFICATION DES SUJETS

Un systme de bases de donnes doit assurer la scurit des donnes quil gre, cest-dire que les oprations non autorises ou mal intentionnes doivent tre rejetes.
Assurer la scurit ncessite tout dabord une identification des utilisateurs, encore
appels sujets. Les sujets effectuent des oprations sur les objets protgs qui les
subissent. Dans les systmes de base de donnes, les sujets sont les utilisateurs devant
les terminaux et les objets les donnes protges avec diffrents niveaux de granularit possibles. Les sujets doivent tout dabord tre identifis.
Notion XVI.32 : Identification (Identification)
Procd consistant associer un sujet un nom ou un numro qui le dsigne de manire unique.

Un premier moyen de violer la scurit des donnes est pour un sujet de se faire passer pour un autre. Afin dviter cela, un procd dauthentification des sujets est
introduit.
Notion XVI.33 : Authentification (Authentification)
Procd permettant de vrifier quun sujet est bien qui il prtend tre.

Le procd dauthentification le plus courant est lutilisation de mots de passe. Un

mot de passe est une chane de caractres en principe connue du sujet et de lobjet
seuls, que le sujet doit fournir pour tre authentifi. Les mots de passe ne doivent pas
tre facilement retrouvables, par exemple partir dun dictionnaire par essais exhaus-

Gestion de transactions 645

tifs. Il est donc souhaitable de choisir des mots de passe longs (plus de 7 caractres),
comportant un mixage de caractres numriques, alphanumriques et de contrle.
Dautres procds plus sophistiqus et plus srs sont lutilisation de questionnaires,
lexcution dalgorithmes connus seulement par lobjet et le sujet, lutilisation de
badges, de cartes puces, dempreintes digitales ou dempreintes de la rtine. Ces
derniers procds ncessitent un priphrique spcialis.
La dfinition des sujets ne pose a priori pas de problme : tout utilisateur est un sujet.
Cependant, il est utile de considrer des groupes dutilisateurs.
Notion XVI.34 : Groupe dutilisateurs (User group)
Ensemble dutilisateurs ayant chacun nom et mot de passe, dsign globalement par un nom, pouvant intervenir comme sujet dans le mcanisme dautorisation.

La notion de groupe peut tre tendue de manire hirarchique, avec des sousgroupes. Dans ce cas, un groupe hrite de toutes les autorisations de ses antcdents
hirarchiques. Il est aussi possible de superposer plusieurs hirarchies [Fernandez80].
Egalement, un sujet peut tre un ensemble de transactions catalogues ; laccs ces
transactions doit alors tre aussi protg.
Un utilisateur peut joindre ou quitter un groupe. La dynamique des groupes lors des
dparts de personnes dans une entreprise peut tre un problme : il faut par exemple
enlever un utilisateur et le remplacer par un autre. Attribuer ou enlever de multiples
droits des groupes devient rapidement difficile lors des changements de fonctions.
Pour viter ces problmes, les SGBD ont introduit la notion de rle.
Notion XVI.35 : Rle (Role)
Ensemble de droits sur les objets caractris par un nom, pouvant intervenir comme sujet dans le
mcanisme dautorisation.

Ainsi, des droits sur les objets sont attribus aux rles. Ceux-ci peuvent tre ensuite
affects aux utilisateurs ou aux groupes dutilisateurs. Les SGBD modernes sont
capables de grer la fois des utilisateurs, des groupes et des rles qui sont donc les
sujets des mcanismes de contrle dautorisations.

11.2. LA DFINITION DES OBJETS

Le choix des objets protger est un des problmes importants lors de la conception
dun module de protection pour un SGBD. Les systmes anciens tels CODASYL et
IMS restreignent les objets protgeables aux types dobjets : CODASYL permet de
protger par des cls nimporte quel niveau de type dobjet dcrit dans le schma
(donne lmentaire, article, fichier), alors quIMS permet de protger des sous-

646 BASES DE DONNES : OBJET ET RELATIONNEL

ensembles de champs dun segment. Au contraire, les systmes relationnels permettent de protger des ensembles doccurrences de tuples dfinis par des prdicats, donc
dpendants du contenu. Les systmes objet permettent souvent de protger la fois
des types et des instances.
Dans les systmes relationnels, les vues jouent un rle essentiel dans la dfinition des
objets protger [Chamberlin75]. Tout dabord, lorsquune vue est un objet autoris
un usager, celui-ci ne peut accder quaux tuples de cette vue. Ensuite, il est possible
avec la notion de vue de dfinir des objets protgs granularit variable. Une vue
peut tre une table de la base : un droit daccs est alors attribu un usager sur une
relation entire. Une vue peut aussi tre un ou plusieurs tuples extraits dynamiquement dune ou de plusieurs tables : un droit daccs est alors attribu sur une relation
virtuelle rsultant de lvaluation dune question. La technique de modification de
questions [Stonebraker75] tudie au chapitre IX traitant des vues permet alors de
protger efficacement les tuples ou attributs de tuples composant la vue. Une autre
approche est dutiliser le mme langage pour dfinir les objets sur lesquels on autorise
des oprations que celui pour exprimer les questions. Cette approche est celle de QBE
o les questions et les autorisations sont exprimes de la mme manire. Cela revient
au mme que lutilisation de vues comme objets de protection, puisquune vue est
dfinie comme une question.
Dans les systmes objet, il est souvent souhaitable de protger les types et mme individuellement les oprations des types, mais aussi les instances. Les objets sont organiss en hirarchie dhritage : les instances dune classe peuvent tre perues comme le
dernier niveau de la hirarchie. Il doit tre possible dajouter des prdicats pour partitionner plus finement lextension dune classe en objets autoriss ou non.
Gnralement, un utilisateur dune sous-classe hrite des droits de la classe de base.
Dans le cas o des autorisations positives (droits daccs) et ngatives (interdictions
daccs) seraient attribues, dterminer les autorisations dune sous-classe devient difficile, notamment en cas dhritage multiple [Rabitti91]. Aujourdhui, les SGBD objet
restent pour la plupart encore assez faibles du point de vue de la scurit.

11.3. ATTRIBUTION ET CONTRLE

DES AUTORISATIONS : LA MTHODE DAC
La mthode DAC (Discretionary Access Control) est la plus utilise dans les SGBD.
Elle consiste attribuer aux sujets des droits doprations sur les objets et les vrifier lors des accs. Un sujet authentifi peut excuter certaines oprations sur certains
objets selon les droits dexcution accords par les administrateurs du systme ou plus
gnralement par dautres sujets. Plus prcisment, nous dfinirons le concept dautorisation dj utilis informellement.

Gestion de transactions 647

Notion XVI.36 : Autorisaton (Authorization)

Droit dexcution dune opration par un sujet sur un objet.

Les autorisations considres sont en gnral positives : ce sont des accords de droits.
Cependant, la dfense amricaine a aussi introduit dans ses standards des possibilits
dautorisations ngatives, qui sont des interdictions daccs. Cela pose des problmes
de conflits, les interdictions dominant en gnral les autorisations. Dans la suite, nous
ne considrons que les autorisations positives.
Lattribution dune autorisation peut dpendre :
du sujet, par exemple de ses privilges daccs ou du terminal quil utilise,
de lobjet, par exemple de son nom, son tat actuel, son contenu ou sa valeur,
de lopration effectue, par exemple lecture ou mise jour,
dautres facteurs, par exemple de lheure du jour ou de la date.
Il existe plusieurs manires de mmoriser les autorisations. Une premire est lutilisation de matrices dautorisations. Une matrice dautorisations est une matrice dont
les lignes correspondent aux sujets et les colonnes aux objets, dfinissant pour chaque
couple sujet-objet les oprations autorises.
Considrons par exemple deux relations dcrivant les objets NOM et RESULTAT
dtudiants et des sujets tudiants, secrtaires et professeurs. Les oprations que peuvent accomplir les sujets sur les objets nom et rsultat sont lecture et criture. Les
autorisations peuvent tre codes par deux bits, droit dcriture puis droit de lecture.
La figure XVI.48 reprsente la matrice correspondant cet exemple, 0 signifiant
accs interdit et 1 accs autoris.
NOM

RSULTAT

TUDIANT

01

01

SECRTAIRE

11

01

PROFESSEUR

11

11

Figure XVI.48 : Exemple de matrice dautorisations

Dans les SGBD, les dfinitions des sujets, objets et autorisations sont mmorises
dans la mta-base ou catalogue du systme. En pratique, la matrice dautorisation peut
tre stocke :
par ligne chaque sujet est alors associe la liste des objets auxquels il peut accder ainsi que les droits daccs quil possde ;

648 BASES DE DONNES : OBJET ET RELATIONNEL

par colonne chaque objet associe la liste des sujets pouvant y accder avec les
droits daccs associs ;
par lment chaque couple sujet-objet sont associs les droits daccs du sujet
sur lobjet.
Cest cette dernire technique qui est retenue dans les SGBD relationnels. Les autorisations sont mmorises dans une table DROITS(<Sujet>, <Objet>, <Droit>,
<Donneur>), le donneur permettant de retrouver la provenance des droits.
Lattribution de droits aux sujets sur les objets est un autre problme important. Plus
prcisment, il est ncessaire de dfinir qui attribue les droits. Deux approches sont
possibles. Soit, comme dans SQL2, le crateur dun objet (une relation ou une vue par
exemple) devient son propritaire et reoit tous les droits. Afin de passer et retirer les
droits quil possde, il doit alors disposer de commandes du type [Griffiths76] :
GRANT < types oprations > ON < objet >
TO < sujet >
[WITH GRANT OPTION]

avec :
<type opration> ::=
<action>
::=
|
|
<sujet> ::=
PUBLIC

ALL PRIVILEGES | <action>+

SELECT | INSERT
UPDATE [(<nom de colonne>+)]
REFERENCE [(<nom de colonne>+)]
| <identifiant dautorisation>

REVOKE < types oprations > FROM < objet > TO < sujet >.
Soulignons que PUBLIC dsigne lensemble des utilisateurs, alors quun identifiant
dautorisation peut dsigner un utilisateur, un groupe ou un rle. Loption WITH
GRANT OPTION permet de passer aussi le droit de donner le droit.
Soit un groupe de sujets particuliers (les administrateurs des bases de donnes) possdent tous les droits et les allouent aux autres par des primitives du mme type. La premire approche est dcentralise alors que la seconde est centralise. Des approches
intermdiaires sont possibles si lon distingue plusieurs groupes de sujets avec des
droits a priori [Chamberlin78].

11.4. ATTRIBUTION ET CONTRLE

DES AUTORISATIONS : LA MTHODE MAC
Un moyen plus simple de contrler les autorisations consiste associer un niveau
dautorisation aux sujets et aux objets.
Notion XVI.37 : Niveau dautorisation (Authorization level)
Fonction mappant lensemble des sujets et utilisateurs sur les entiers [0-N] permettant un sujet
daccder un objet si et seulement si : Niveau(Sujet) Niveau(Objet).

Gestion de transactions 649

Un niveau dautorisation est un nombre associ chaque objet ou chaque sujet. Il

caractrise des niveaux de sensibilit des informations (Top secret, secret, confidentiel, non class) et des niveaux de permissions des sujets vis vis des objets. Un accs
est autoris si et seulement si le niveau du sujet accdant est suprieur ou gal au
niveau de lobjet accd. Le sujet domine alors le type dinformation auquel il accde.
Considrons par exemple les sujets et objets introduits ci-dessus avec les niveaux
dautorisation : Etudiant (1), Secrtaire (2), Enseignant (3), Nom (1), Rsultat (3). La
matrice dautorisation quivalente est reprsente figure XVI.49.
NOM

RSULTAT

TUDIANT

11

01

SECRTAIRE

11

00

PROFESSEUR

11

11

Figure XVI.49 : Matrice dautorisation quivalente aux niveaux indiqus

Linconvnient de la solution niveau dautorisation est que lon perd la notion dopration. Cependant, cette solution est simple implanter et de plus elle permet de combiner les niveaux. En effet, si un sujet de niveau S1 accde travers une procdure ou
un quipement de niveau S2, on associera au sujet le niveau S = min (S1, S2). Par
exemple, sil existe un terminal en libre accs de niveau 1 et un terminal situ dans un
bureau priv de niveau 3, un enseignant ne conservera ses privilges que sil travaille
partir du terminal situ dans le bureau. De plus, la mthode peut tre tendue, avec
des classes de niveaux partiellement ordonnes, vers un modle plus complet de
contrle de flots dinformations. Elle peut aussi tre combine avec la mthode MAC.

11.5. QUELQUES MOTS SUR LE CRYPTAGE

Les donnes sensibles dans les bases peuvent tre cryptes. Le cryptage est fond sur
des algorithmes mathmatiques qui permettent de transformer les messages en rendant
trs difficile la dcouverte des transformations inverses. Plus prcisment, on utilise en
gnral des fonctions non facilement rversibles bases sur des divisions par des produits de grands nombres premiers. La recherche de la fonction inverse ncessite des
dcompositions en facteurs premiers trs longues raliser. Les algorithmes de codage
et dcodage demandent donc lattribution de cls de cryptage et de dcryptage.
Les algorithmes symtriques utilisent une seule cl secrte pour le cryptage et le
dcryptage. La cl est par exemple un nombre de 128 bits. Un dcodage dun message
crypt sans connatre la cl ncessite en moyenne quelques annes avec des machines

650 BASES DE DONNES : OBJET ET RELATIONNEL

parallles les plus puissantes. Le mcanisme est donc sr, mais le problme est la gestion des cls qui doivent tre changes. Lapplication dun tel algorithme aux bases
de donnes ncessite son implmentation dans le SGBD et au niveau de lutilisateur.
Il faut en effet pouvoir dcrypter au niveau du SGBD pour effectuer les recherches.
Rechercher sur des donnes cryptes est trs difficile puisque les chanes de donnes
codes dpassent en gnral un attribut. Le SGBD devra donc garder un catalogue des
cls de cryptage/dcryptage. Les utilisateurs doivent pouvoir accder au catalogue
pour retrouver leur cl secrte. Celui-ci devient un point faible du systme.
Les algorithmes cls publiques et prives proposent deux cls diffrentes, inverses
lune de lautre. Lune permet de coder, lautre de dcoder. Les cls doivent tre plus
longues quavec les algorithmes cls secrtes, car elles sont plus facilement cassables,
cest--dire qu partir dune cl publique de 40 bits, on peut dduire la cl prive en
lessayant sur un message comprhensible en quelques heures de calcul dune machine
puissante. Il faut donc des cls de 512 bits et plus pour obtenir une scurit totale, ce qui
peut poser des problmes de lgislation. Avec de telles cls, le SGBD peut garder ses cls
prives et publier ses cls publiques. Lutilisateur code les donnes avec une cl publique
et les insre dans la base. Le SGBD dcode avec la cl prive correspondante. Les rsultats peuvent tre envoys cods avec une cl publique de lutilisateur qui dcode alors
avec sa cl prive. Ce schma est trs sr si les cls sont assez longues. Il est illustr
figure XVI.50. Les algorithmes asymtriques tels que Diffie-Hellmann et RSA permettent ainsi des solutions trs sres, o SGBD et utilisateurs gardent leurs cls prives.

Codage
cl publique de S

Donnes
cryptes

Dcodage
cl prive de S

Recherche

Dcodage
cl prive de U

Utilisateur

Codage
cl publique de U

SGBD

Figure XVI.50 : Fonctionnement avec cls asymtriques

(U dsigne lutilisateur et S le SGBD)

Gestion de transactions 651

12. CONCLUSION ET PERSPECTIVES

Dans ce chapitre, nous avons abord les problmes de gestion de transactions. Nous
avons tudi la thorie de la concurrence puis les algorithmes de contrle. Ensuite,
nous avons abord la rsistance aux pannes avec ses aspects validation et reprise. La
mthode ARIES couple au verrouillage deux phases et la validation en deux tapes
constitue une bonne rfrence que nous avons prsente.
Nous avons aussi abord les modles de transactions tendues, tels que les transactions imbriques. Sur le contrle de concurrence et sur les transactions tendues, de
nombreux articles ont t publis. Il est difficile dy voir clair, mais nous avons synthtis lessentiel. Finalement, au-del du verrouillage deux phases, de la validation
en deux tapes et des procdures de reprise type ARIES, peu de choses sont implmentes dans les systmes industriels. Une des raisons est sans doute la complexit
des algorithmes trs sensibles pour lexploitation relle des bases de donnes.
Plusieurs problmes nont cependant pas t abords, en particulier celui de la concurrence dans les index et celui de la scurit dans les bases de donnes statistiques.
Les algorithmes de concurrence au niveau des index ncessitent des approches spcifiques du fait que lindex est un point de passage oblig pour toute les transactions
accdant sur cl. On ne peut donc bloquer lindex pendant la dure de vie dune transaction. La prise en compte des commutativits doprations telles que linsertion et
linsertion avec reprise par des oprations logique comme la suppression est une
direction de solution. Une autre voie repose sur une granularit de verrouillage trs
fine correspondant une entre dindex. Avec une telle granularit, dans un arbre B, il
est possible de relcher les verrous sur les entres suprieures ds quune entre infrieure est verrouille et que lon est sr de ne pas devoir modifier lentre suprieure.
Verrouiller efficacement des index ncessite la fois une granularit fine et la prise en
compte des commutativits doprations. Ceci complique la mthode de reprise.
Notez quARIES supporte ces points. Pour une introduction plus complte sur le
contrle de concurrence au niveau des index, vous pouvez consulter [Besancenot97].
Lobjectif des bases de donnes statistiques est de fournir des rsums sur une population sans permettre lutilisateur de dduire des informations sur des individus particuliers. Ce type de protection est important, notamment dans le domaine mdical et
plus gnralement pour le dcisionnel. Il apparat trs difficile dviter les possibilits
de dduction dinformations spcifiques un individu en corrlant plusieurs rsums.
Ainsi le chasseur de secrets reste-t-il une menace pour les bases de donnes statistiques [Denning80]. La seule manire de le perturber est sans doute de lui mentir un
peu. Une vue densemble du domaine est prsente dans un ouvrage assez ancien
[Demillo78]. Le sujet nest plus gure dactualit, mais il peut le redevenir.

652 BASES DE DONNES : OBJET ET RELATIONNEL

13. BIBLIOGRAPHIE
[Baer81] Baer J.-L., Gardarin G., Girault C., Roucairol G., The Two-Step
Commitment Protocol : Modeling, Specification and Proof Methodology ,
5th Intl. Conf. on Software Engineering, IEE Ed., San Diego, 1981.
Cet article modlise le protocole de validation en deux tapes par des rseaux
de Petri. Il prouve partiellement la correction du protocole, cest--dire que
tous les sites prennent la mme dcision pour une transaction.
[Barghouti91] Barghouti N. S., Kaiser G. E., Concurrency Control in Advance
Database Applications ACM Computing Survey, vol. 23, n 3, p. 270-317,
Sept. 1991
Cet article fait le point sur les techniques de contrle de concurrence avances.
Il rappelle les techniques traditionnelles vues ci-dessus et rsume le verrouillage altruiste, la validation par clichs, les transactions multi-niveaux, le
verrouillage smantique, les sagas, etc.
[Bancilhon85] Bancilhon F., Korth H., Won Kim, A Model of CAD Transactions ,
11th Int. Conf. on Very Large data Bases, Stockholm, Sude, Aot 1985.
Cet article propose un modle de transactions longues pour les bases de donnes en CAO. Il fut lun des prcurseurs des modles de transactions imbriqus
dvelopps par la suite.
[Beeri88] Beeri C., Scheck H-J., Weikum G., Multi-Level Transaction Management,
Theoretical Art or Practical Need ? , Proc. Intl. Conf. on Extending Database
Technology (EDBT), p. 134-155, Venise, Mars 1988.
Cet article introduit la srialisabilit niveaux multiples prsente ci-dessus.
[Bernstein80] Bernstein P.A., Goodman N., Timestamp-based Algorithm for
Concurrency Control in Distributed Database Systems , 5th Intl. Conf. On Very
Large data Bases, Montreal, Oct. 1980.
Cet article introduit diffrents algorithmes destampillage de transactions dans
le contexte de systmes rpartis.
[Bernstein87] Bernstein P.A., Hadzilacos V., Goodman N., Concurrency Control and
Recovery in Database Systems, Addison-Weley, 1987.
Cet excellent livre de 370 pages fait le tour des problmes de gestion de transactions dans les SGBD centraliss et rpartis. Il prsente notamment la thorie de base, le verrouillage, la certification, le multi-version, les protocoles de
validation deux et trois phases, la gestion de donnes rpliques.
[Bernstein90] Bernstein P.A., Hsu M., Mann B., Implementing Recoverable
Requests Using Queues , ACM SIGMOD Int. Conf., ACM Ed., SIGMOD
Record V. 19, n 2, June 1990.

Gestion de transactions 653

Cet article propose un protocole rsistant aux pannes pour grer les flots de
requtes de transactions entre clients et serveurs. Il discute une implmentation
en utilisant des files dattente persistantes rcuprables aprs panne.
[Besancenot97] Besancenot J., Cart M., Ferri J., Guerraoui R., Pucheral Ph.,
Traverson B., Les Systmes Transactionnels : Concepts, Normes et Produits,
Ed. Herms, Paris, 1997.
Ce remarquable livre sur les systmes transactionnels couvre tous les aspects
du sujet : concepts de base, algorithmes de reprise, transactions rparties,
duplication, modles de transactions tendus, normes et standards, transactions dans les SGBD relationnels et objet.
[Bjork72] Bjork L.A., Davies C.T., The Semantics of the Preservation and Recovery
of Integrity in a Data System , Technical Report TR-02.540, IBM, Dec. 1972.
Un des tout premiers articles introduisant un concept proche de celui de transaction.
[Cart90] Cart M., Ferri J., Integrating Concurrency Control into an ObjectOriented Database System , Proc. Intl. Conf. on Extending Database
Technology, EDBT, LCNS n 416, p. 367-377, Venise, Mars 1990.
Cet article prsente lintgration dalgorithmes de contrle de concurrence
avec prise en compte de la commutativit des oprations dans un SGBD objet.
[Chamberlin75] Chamberlin D.D., Gray J.N., Traiger I.L., Views, Authorizations
and Locking in a Relational Data Base System , Proc. of ACM National
Computer Conf., p. 425-430, 1975
Cet article discute de lutilisation des vues comme mcanisme dautorisation et
de verrouillage par prdicat dans un SGBD.
[Chamberlin78] Chamberlin D.D., Gray J.N., Griffiths P.P., Mresse M., Traiger I.L.,
Wade B.W., Data Base System Authorization , in Foundations of Secure
Computation [Demillo78], p. 39-56.
Cet article discute des mcanismes dautorisation dans un SGBD relationnel.
[Chrysanthis90] Chrystandis P.K., Ramamritham K., ACTA : A Framework for
Specifying and reasoning about Transaction Structure and Behavior , ACM
SIGMOD Intl. Conf. on Management of Data, SIGMOD Record vol. 19, n 2,
p. 194-203, Atlantic City, NJ, Juin 1990.
Cet article prsente ACTA, un formalisme permettant de spcifier structure et
comportement des transactions, en exprimant notamment la smantique des
interactions.
[Dayal91] Dayal U., Hsu M., Ladin R., A Transactional Model for Long-Running
Activities , Proc. of the 17th Intl. Conf. on Very Large Data Bases, Morgan
Kaufmann Ed., p. 113-122, Bacelonne, Sept. 1991.

654 BASES DE DONNES : OBJET ET RELATIONNEL

Cet article dcrit un modle dactivits composes rcursivement de sous-activits et de transactions. Le modle dfinit la smantique des activits et dcrit
une implmentation en utilisant des files rsistantes aux pannes pour chaner
les activits.
[Denning80] Denning D.E., Schlrer J., A Fast Procedure for Finding a Tracker in a
Statistical Database , ACM Transactions on Database Systems, vol. 5, n 1,
p. 88-102, Mars 1980.
Cet article prsente une procdure rapide pour dcouvrir les caractristiques
dun individu partir de requtes sur des ensembles dindividus.
[Demillo78] DeMillo R.A., Dobkin D.P., Jones A.K., Lipton R.J., Foundations of
Secure Computation, Academic Press, 1978.
Ce livre prsente un ensemble darticles sur la scurit dans les BD statistiques
et les systmes opratoires.
[Eswaran76] Eswaran K.P., Gray J.N., Lorie R.A., Traiger L.L., The Notion of
Consistency and Predicates Locks in a Database System , Comm. of the ACM,
vol. 19, n 11, p. 624-633, Nov. 1976.
Un des articles de base sur la notion de transaction et le principe du verrouillage deux phases. La notion de srialisabilit et le verrouillage par prdicat sont aussi introduits par les auteurs qui ralisent alors la gestion de transactions dans le fameux systme R.
[Fernandez80] Fernandez E.B., Summers R.C., Wood C., Database Security and
Integrity, The Systems Programming Series, 1980.
Ce livre de 320 pages fait le tour des techniques dintegrit et de scurit au
sens large dans les bases de donnes.
[Garcia-Molina87] Garcia-Molina H., Salem K., Sagas Proc. ACM SIMOD Intl.
Conf. on Management of Data, p. 249-259, San Fransisco, 1987.
Cet article prsente le modle des sagas introduit ci-dessus.
[Gardarin76] Gardarin G., Spaccapietra S., Integrity of Databases : A General
Locking Algorithm with Deadlock Detection , IFIP Intl. Conf. on Modelling
in DBMS, Freudenstadt, January 1976.
Cet article prsente un algorithme de verrouillage multi-mode et un algorithme
de dtection du verrou mortel dans ce contexte.
[Gardarin77] Gardarin G., Lebeux P., Scheduling Algorithms for Avoiding
Inconsistency in Large Data Bases , 3rd Intl. Conf. on Very Large Data Bases,
IEEE Ed., Tokyo, 1977.
Cet article introduit pour la premire fois la commutativit des oprations comme
solution pour tolrer plus dexcution srialisable. Il prsente un algorithme de
verrouillage modes multiples prenant en compte les commutativits possibles.

Gestion de transactions 655

[Gardarin78] Gardarin G., Rsolution des Conflits dAccs simultans un

Ensemble dInformations Applications aux Bases de Donnes Rparties ,
Thse dtat, Paris VI, 1978.
Cette thse introduit diffrents algorithmes de verrouillage et de dtection du
verrou mortel, dont certains avec prise en compte de la commutativit des oprations, dautres bass sur lordonnancement total ou partiel par estampillage.
Ces deux rsultats taient nouveaux cette poque. La mthode base sur la
commutativit des oprations avait t publie auparavant au VLDB 1977
[Gardarin77]. Les algorithmes destampillage ont t un peu plus tard plus
clairement prsents avec M. Melkanoff dans le rapport INRIA n 113 et en
parallle par P. Bernstein [Bernstein80].
[Gray78] Gray J.N., Notes on Database Operating Systems , in Operating Systems
An Advanced Course, R. Bayer Ed., Springer-Verlag, 1978.
Cet article est un autre tutorial sur la gestion de transactions, bas sur la ralisation du gestionnaire de transaction du systme R.
[Gray81] Gray J., The Transaction Concept : Virtues and Limitations , Proc. of the
7th Intl. Conf. on Very Large Data Bases, IEEE Ed., p. 144-154, 1981.
Un autre tutorial sur la notion de transaction, discutant verrouillage, validation et procdures de reprise.
[Gray91] Gray J. Ed., The Benchmark Handbook , Morgan & Kaufman Pub., San
Mateo, 1991.
Le livre de base sur les mesures de performances des SGBD. Compos de diffrents articles, il prsente les principaux benchmarks de SGBD, en particulier le
fameux benchmark TPC qui permet dchantillonner les performances des
SGBD en transactions par seconde. Les conditions exactes du benchmark dfinies par le Transaction Processing Council sont prcises. Les benchmarks
de luniversit du Madisson, AS3AP et Catell pour les bases de donnes objets,
sont aussi prsents.
[Gray93] Gray J.N., Reuter A., Transaction Processing : Concepts and Techniques,
Morgan Kaufman Ed., 1993.
Une bible de 1070 pages qui traite en dtail tous les aspects des transactions.
[Griffiths76] Griffiths P.P., Wade B.W., An Authorization Mechanism for a
Relational Database System , ACM Transactions on Database Systems, vol. 1,
n 3, p. 242-255, Sept. 1996.
Cet article dcrit le mcanismes des droits daccs avec oprations GRANT et
REVOKE pour la premire fois. Limplmentation du systme R ralise par les
auteurs fut la premire.
[Holt72] Holt R.C., Some Deadlock Properties of Computer Systems , ACM
Computing Surveys, vol. 4, n 3, p. 179-196, Sept. 1972.

656 BASES DE DONNES : OBJET ET RELATIONNEL

Cet article discute des problmes de deadlock et introduit notamment le graphe

dallocation des ressources avec des algorithmes de dtection associs.
[Kaiser95] Kaiser G.E., Cooperative Transactions for Multiuser Environments , in
Modern Database Systems, Won Kim Ed., ACM Press, p. 409-433, 1995.
Cet article est un tutorial sur les transactions coopratives de longue dure. Il
passe en revue le modle des versions, split-join, de transactions imbriques et
de groupes.
[Korth90] Korth H.F., Levy E., Silberschatz A., A Formal Aproach to Recovery by
Compensating Transactions , Proc. of 16th Intl. Conf. on Very Large Data
Bases, Morgan Kaufman Ed., p. 95-106, Brisbane, Australia, August 1990.
[Kung81] Kung H.T., Robinson J.T., On Optimistic Method for Concurrency
Control , ACM Transaction on Database Systems (TODS), vol. 6, n 2, p. 213226, Juin 1981.
Cet article prsente deux familles dalgorithmes optimistes de contrle de
concurrence bass sur la certification.
[Lampson76] Lampson B., Sturgis H., Crash Recovery in Distributed Data Storage
System , Xerox Technical Report, Palo Alto, Xerox Research Center, 1976.
Cet article de base prsente la premire implmentation du protocole de validation en deux tapes. Lampson et Sturgis sont connus comme tant les inventeurs
de ce fameux protocole.
[Lorie77] Lorie R.A., Physical Integrity in a Large Segmented Database , ACM
Transactions on Database Systems, vol. 2, n 1, p.91-104, Mars 1977.
Cet article dcrit le systme de stockage du systme R et sa gestion de transaction et reprise.
[Mohan86] Mohan C., Lindsay B., Obermark R., Transaction Management in the
R* Distributed Database Management System, ACM Trans. On Database Syst.,
vol. 11, n 4, Dec. 1986.
R* est le prototype de SGBD rparti dvelopp par IBM au dbut des annes
80. Cet article prsente la gestion de transactions distribues, notamment les
protocoles de validation deux phases.
[Mohan92] Mohan C., Haderle D., Lindsay B., Pirahesh H., Schwarz P., ARIES : A
Transaction Recovery Method Supporting Fine-Granularity Locking and Partial
Rollbacks Using Write-Ahead Logging , ACM Transactions on Database
Systems, vol. 17, n 1, p. 94-162, Mars 1992.
Cet article prsente la mthode ARIES dcrite ci-dessus.
[Moss82] Moss J.E.B., Nested transactions and Reliable Distributed Computing ,
2nd Symposium on Reliability in Distributed Software and Database Systems,
p. 33-39, IEEE Ed., Pittsburgh, 1982.

Gestion de transactions 657

Cet article introduit les transactions imbriques, inventes par Moss dans son
PhD. Les transactions imbriques, au dpart fermes, ont t ouvertes (nonatomicit globale) et son implmentes dans des systmes de plus en plus nombreux.
[Moss85] Moss J.E.B., Nested Transactions : An Approach to Reliable Distributed
Computing, The MIT Press, Cambridge, Mass., 1985.
Ce livre, version amliore du PhD de Moss, introduit et tudie en dtail la
thorie et la pratique des transactions imbriques.
[Murphy68] Murphy J.E., Ressource Allocation with Interlock Detection in a MultiTask system , Proc of AFIPS-FJCC Conf., vol. 33, n 2, p. 1169-1176, 1968.
Cet article introduisit les graphes dattente et lun des premiers algorithmes de
dtection de deadlock.
[zsu91] zsu M.T., Valduriez P., Principles of Distributed Database Systems,
Prentice Hall, Englewood Cliffs, New Jersey, 562 p., 1991.
Cet ouvrage est le livre de rfrence en anglais sur les bases de donnes rparties. Il couvre en particulier les aspects architecture, conception, contrle
smantique, optimisation de requtes, gestion de transactions, fiabilit et
concurrence, bases de donnes fdres. Chaque aspect est trait de manire
trs complte. Les algorithmes sont esquisss et une formalisation minimale est
souvent introduite.
[Ozsu94] Ozsu T., Transaction Models and Transaction Management in ObjectOriented Database Management Systems , in Advances in Object-Oriented
Database Systems, p. 147-184, A. Dogac et. Al. Ed., NATO ASI Series,
Springer Verlag, Computer and System Sciences, 1994.
Ce remarquable article est un autre tutorial sur la gestion de transactions. Il
couvre particulirement bien les modles de transactions tendus et linfluence
de la commutativit des oprations.
[Pu88] Pu C., Kaiser G.E., Hutchinson N., Split-Transactions for Open-Ended
Activities 14th Intl. Conf. on Very Large data Bases, p. 26-37, Morgan
Kaufman Ed., Los Angels, 1998.
Cet article prsente le modle dynamique split et join voqu ci-dessus pour les
transactions imbriques.
[Rabitti91] Rabitti F., Bertino E., Kim W., Woelk D., A Model of Authorization for
Next Generation Database Systems , ACM Trans. On Database Systems,
vol. 16, n 1, p. 88-131, Mars 1991.
Cet article dveloppe un modle formel de scurit de type DAC pour un SGBD
objet. Il sappuie sur lexprience conduite avec le SGBD ORION.

658 BASES DE DONNES : OBJET ET RELATIONNEL

[Reed79] Reed D.P., Implementing Atomic Actions , Proc. of the 7 th ACM

SIGOPS Symposium on Operating Systems Principles, ACM Ed., Dec. 1979.
Lauteur a propos un algorithme dordonnancement multi-version quil utilise
pour implmenter des actions atomiques que lon appelle aujourdhui des transactions.
[Rosenkrantz78] Rosenkrantz D., Stearns R., Lewis P., System Level Concurrency
Control for Distributed Database Systems , ACM Transactions on Database
Systems, vol. 3, n 2, p. 178-198, Juin 1978.
Cet article prsente les techniques de contrle de concurrence WAIT-DIE et
WOUND-WAIT dcrites ci-dessus.
[Rusinkiewicz95] Rusinkiewicz M., Sheth A., Specification and Execution of
Transactional Workflows , in Modern Database Systems, Won Kim Ed., ACM
Press, p. 592-620, 1995.
Cet article discute les applications du concept de transaction aux activits de
type workflow qui ncessitent la coordination de tches multiples.
[Russell91] Russell D., Gangemi Sr. G.T., Computer Security Basics, OReilly &
Associates, Inc., 1991.
Un livre de base sur les techniques de scurit, couvrant notamment les
contrles daccs, les virus, le livre orange de larme amricaine (Orange
Book) et la scurit dans les rseaux.
[Skeen81] Skeen D., Nonblocking Commit Protocols , ACM SIGMOD Intl. Conf.
on Management of Data, Ann Arbor, p. 133-142, ACM Ed., Mai 1981.
Des protocoles non bloquants, en particulier le protocole en trois tapes dcrit
ci-dessus, sont introduits dans cet article.
[Stonebraker75] Stonebraker M., Implmentation of Integrity Constraints and Views
by Query Modification , Proc. ACM SIGMOD Intl. Conf. on Management of
Data, San Jos, CA 1975.
Cet article propose de modifier les questions au niveau du source par la dfinition de vues pour rpondre aux requtes. La technique est formalise avec le
langage QUEL dINGRES, o elle a t implmente.
[Verhofstad78] Verhofstad J.S.M, Recovery Techniques for database Systems, ACM
Computing Surveys, vol. 10, n 2, p. 167-195, Juin 1978.
Un tat de lart sur les techniques de reprise dans les bases de donnes en
rseaux et relationnelles.
[Wachter92] Wachter H., Reuter A., The Contract Model , in Database
Transaction Models for Advanced Applications, Morgan Kaufman Pub., 1992.
Cet article introduit les contrats comme un ensemble de transactions diriges
par un script. Il fut lun des prcusseurs des workflows.

Gestion de transactions 659

[Weikum91] G. Weikum, Principles and Realization Strategies of Multi-Level

Transaction Management , ACM Transactions on Database Systems, vol. 16,
n 1, 1991.
Cet article dcrit un protocole de gestion de transactions imbriques et distribues, avec des sphres dinfluence dfinies pour chaque transaction : sphre
de validation des sous-transactions devant tre valides, sphre dannulation
des sous-transaction devant tre annules, ceci en cas de validation ou dannulation de la transaction matre.
[Weihl88] Weihl W.E., Commutativity-based Concurrency Control for Abstract
Data Types , IEEE Transactions on Computers, vol. 37, n 12, p. 1488-1505,
1988.
Cet article propose des mthodes et algorithmes de contrle de concurrence
prenant en compte la commutativit des oprations pour grer des types abstraits de donns.

Chapitre XVII

CONCEPTION
DES BASES DE DONNES
1. INTRODUCTION
Une des tches essentielles des dveloppeurs de bases de donnes est la conception du
schma des bases. Lobjectif est de structurer le domaine dapplication de sorte le
reprsenter sous forme de types et de tables. La reprsentation doit tre juste pour viter les erreurs smantiques, notamment dans les rponses aux requtes. Elle doit aussi
tre complte pour permettre le dveloppement des programmes dapplication souhaits. Elle doit enfin tre volutive afin de supporter la prise en compte rapide de nouvelles demandes.
Le concepteur, ou plutt ladministrateur de base, effectue galement le choix du placement des tables sur disques et le choix des index, choix essentiels pour les performances.
En exagrant un peu, on peut dire quil ny a pas de mauvais SGBD, mais de mauvais
concepteurs responsables des erreurs smantiques ou des mauvaises performances. Les
choix de structures physiques sont dpendants des programmes qui manipulent la base,
particulirement des types et frquences des requtes dinterrogation et de mise jour.
Traditionnellement, la dmarche de conception seffectue par abstractions successives, en descendant depuis les problmes de lutilisateur vers le SGBD. Nous proposons de distinguer cinq tapes :

662 BASES DE DONNES : OBJET ET RELATIONNEL

1. Perception du monde rel et capture des besoins. Cette tape consiste tudier
les problmes des utilisateurs et comprendre leurs besoins. Elle comporte des
entretiens, des analyses des flux dinformation et des processus mtier. Des
dmarches de type BPR (Business Process Reengineering) [Hammer93] de reconception des processus mtiers existants en les dirigeant vers le client peuvent tre
un support pour cette tape. La gnration de modles de problmes est aussi une
technique courante ce niveau [DeAntonellis83]. Comme il est difficile de comprendre le problme dans son ensemble, les concepteurs ralisent des tudes de cas
partiels. Le rsultat se compose donc dun ensemble de vues ou schmas externes
quil faut intgrer dans ltape suivante. Ces vues sont exprimes dans un modle
de type entit-association ou objet, selon la mthode choisie.
2. laboration du schma conceptuel. Cette tape est base sur lintgration des
schmas externes obtenus ltape prcdente. Chaque composant est un schma
entit-association ou objet. Il rsulte dun modle de problme reprsentant une
partie de lapplication. La difficult est dintgrer toutes les parties dans un schma
conceptuel global complet, non redondant et cohrent. Des allers et retours avec
ltape prcdente sont souvent ncessaires.
3. Conception du schma logique. Cette tape ralise la transformation du schma
conceptuel en structures de donnes supportes par le systme choisi. Avec un
SGBD relationnel, il sagit de passer des tables. Avec un SGBD objet-relationnel,
il est possible de gnrer des types et des tables, les types tant rutilisables. Avec
un SGBD objet, il sagit de gnrer des classes et des associations. Cette tape peut
tre compltement automatise, comme nous le verrons.
4. Affinement du schma logique. Une question qui se pose est de savoir si le
schma logique obtenu est un bon schma. titre de premire approximation,
un bon schma est un schma sans oublis ni redondances dinformations. Pour
caractriser plus prcisment les bons schmas, le modle relationnel sappuie
sur la thorie de la normalisation, qui peut tre avantageusement applique ce
niveau. En relationnel, lobjectif est de grouper ou dcomposer les tables de
manire reprsenter fidlement le monde rel modlis.
5. laboration du schma physique. Cette tape est ncessaire pour obtenir de
bonnes performances. Elle ncessite la prise en compte des transactions afin de
dterminer les patterns daccs frquents. partir de l, il faut choisir les bonnes
structures physiques : groupage ou partitionnement de tables, index, etc. Cest l
que se jouent pour une bonne part les performances des applications.
Dans ce chapitre, nous tudions essentiellement les tapes 2, 3 et 4 qui font largement
partie du domaine des bases de donnes. La partie 1 appartient plutt au gnie logiciel, voire lconomie ou la psychologie. Nous ne laborderons gure. Nous
dtaillons surtout la partie 3 o toute une thorie sest dveloppe la fin des
annes 70 et au dbut des annes 80 pour les bases relationnelles.
Dans la section qui suit, nous abordons le problme de la conception du schma
conceptuel. Cest loccasion de prsenter le langage de modlisation UML, plus prci-

Conception des bases de donnes 663

sment les constructions ncessaires la modlisation de BD. Nous discutons aussi

des techniques dintgration de schmas. La section 3 dveloppe les rgles pour passer dun schma conceptuel UML un schma relationnel. Elle propose aussi
quelques pistes pour passer lobjet-relationnel. La section 4 prsente les approches
pour laffinement du schma logique. La thorie de la normalisation, qui peut tre
intgre au cur de laffinement, est lobjet des trois sections qui suivent. La section 5 discute les principales techniques doptimisation du schma physique. Nous
concluons en rsumant et discutant les voies dvolution.

2. LABORATION DU SCHMA
CONCEPTUEL
Dans cette section, nous traitons des techniques permettant de dfinir un schma
conceptuel. Nous procdons par modlisation entit-association ou objet en construisant des diagrammes bass sur UML, le langage de modlisation unifi standardis
par lOMG.

2.1. PERCEPTION DU MONDE REL AVEC E/R

Le monde des applications informatiques peut tre modlis laide dentits qui
reprsentent les objets ayant une existence visible, et dassociations entre ces objets
[Benci76, Chen76]. Le modle entit-association (Entity Relationship, E/R) a eu un
trs grand succs pour reprsenter des schmas externes dun domaine de discours
particulier, autrement dit des parties dune application. Comme nous lavons vu au
chapitre II, ce modle repose sur des entits encore appeles individus, des associations ou relations entre entits, et des attributs ou proprits. Il est la base de
Merise [Tardieu83] et de nombreuses autres mthodes. Une entit modlise un objet
intressant peru dans le rel analys, ayant une existence propre. Un attribut est une
information lmentaire qui caractrise une entit ou une association et dont la valeur
dpend de lentit ou de lassociation considre. Une association est un lien smantique entre deux entits ou plus. Dfinir une vue du rel analys par le modle entitassociation ncessite disoler les types dentits, dassociations et dattributs.
Diffrents diagrammes ont t introduits pour reprsenter les schmas entit-association. Au chapitre II, nous avons introduit les notations originelles de Chen. Dans la
suite, nous utilisons la reprsentation propose dans le langage universel de modlisation UML [Rational98]. En effet, ce langage devient le standard pour la conception
dans les entreprises. Pouss par lOMG, il a le mrite dtre complet, clair et sans

664 BASES DE DONNES : OBJET ET RELATIONNEL

doute rsistant lusure du temps, comme tous les standards. La construction de base
drive du langage UML pour reprsenter des entits est symbolise figure XVII.1.
titre dexemple, nous avons reprsent des voitures avec les attributs numro de
vhicule (NV), marque, type, puissance et couleur.
Nom

Voitures

Attribut: Type
.
Attribut: Type

NV: Int
Marque: String
Type: String
Puissance: Int
Couleur: String

Figure XVII.1 : Reprsentation dentits

La construction de base permettant de reprsenter des associations est symbolise

figure XVII.2. Nous reprsentons l une association binaire gnrique avec attributs.
Lassociation entre les entits Entit1 et Entit2 est reprsente par un trait simple. Le
nom de lassociation apparat au-dessus du trait. Les attributs sont reprsents par une
entit sans nom accroche par un trait en pointill lassociation. Si les donnes participent elles-mmes des associations, il est possible de leur donner un nom : on a alors
une vritable entit associative possdant une valeur pour chaque instance de lassociation binaire. La reprsentation dassociations ternaires est possible avec UML : on utilise alors un losange o convergent les traits associatifs et de donnes. Cependant, nous
dconseillons lemploi de telles associations difficiles lire : les associations n-aires
peuvent toujours se reprsenter par une classe associative en ajoutant une contrainte
qui exprime que les associations sont instancies ensemble. Par exemple, une vente
associe simultanment un client, un produit et un vendeur. Dans la suite, nous considrons souvent des associations binaires, plus faciles manipuler et comprendre.
Entit1

Entit2
Association
Rle1

Rle2

Donnes

Figure XVII.2 : Reprsentation dassociations

Conception des bases de donnes 665

Dans une association, chaque entit participante joue un rle. Celui-ci peut tre explicitement nomm, comme indiqu figure XVII.2. Mais ceci nest pas obligatoire. Les
associations sont caractrises par des cardinalits : la cardinalit [m,n] attache
une entit indique les nombres minimal et maximal dinstance dassociations pour une
instance de cette entit.
Notion XVII.1 : Cardinalits dassociation (Relationship cardinalities)
Cardinalits minimale et maximale associes chacun des rles de lassociation, indiquant le
nombre minimal et maximal dinstances dassociation auxquelles participe une instance de lentit
du rle.

Une cardinalit se lit donc dans le sens entit vers association. Il faut se demander
pour une instance dentit (ou de classe) combien dinstances dassociation lui sont
attaches ? Avec des associations binaires, cela revient indiquer le nombre dinstances de lautre entit pour une instance de celle laquelle est attache la cardinalit.
UML propose les notations indiques figure XVII.3 pour les cardinalits. Notez que 1
signifie la fois un minimum de 1 et un maximum de 1. La notation {ord} signifie
que lordre dapparition des entits dans lassociation est important.
1

*
0..1

1..*

1
plusieurs (0 N)
optionnel (0 ou 1)
obligatoire (1 ou plus)

0..*
{ord}
3..5

ordonn (0 N)
limit (de 3 5)

Figure XVII.3 : Notation des cardinalits dassociations

titre dexemple, soient une base modlisant des entits personne et voiture ,
et le type dassociation possde qui traduit le fait quune personne est propritaire
dune ou plusieurs voitures. Une personne est caractrise par un numro de Scurit
Sociale (NSS), un nom, un prnom et une date de naissance alors quune voiture est
caractrise par les attributs dj vus NV, MARQUE, TYPE, PUISSANCE et COULEUR. Chaque personne est identifie par une occurrence du numro de Scurit
Sociale (NSS), alors que chaque voiture est identifie par un numro de vhicule

666 BASES DE DONNES : OBJET ET RELATIONNEL

(NV). chaque occurrence dassociation correspond par exemple une date dachat
(DATE) et un prix dachat (PRIX). La figure XVII.4 reprsente le schma externe
correspondant dcrit avec les notations UML rduites aux entits, associations et attributs. Les cardinalits indiquent quune personne peut possder de O N voitures alors
quune voiture est possde par une et une seule personne.
Personne

Voiture
nv
marque
type
puissance
couleur

Possde
*

nss
nom
prenom
datenais

date
prix

Figure XVII.4 : Exemple dassociation entre voiture et personne

Nous prsentons figure XVII.5 lexemple classique des buveurs, des vins et de lassociation boire caractrise par une date et une quantit. Les cardinalits sont donc portes par les rles : le rle Estbu porte la cardinalit 1..*, ce qui signifie qu un buveur
est associ entre 1 et N abus ou vins si lon prfre. * est une notation raccourcie pour
0..*. Le rle Estbu porte cette cardinalit, ce qui signifie quun vin est bu par 0 N
buveurs. Tout cela, aux notations prs, est bien connu mais souvent confus, les cardinalits tant interprtes de diffrentes manires selon les auteurs. Nous avons choisi
ces notations pour assurer la compatibilit avec lapproche objet et UML que nous
allons maintenant dvelopper un peu plus.
Buveurs

Vins
*

Boire

Abus

1..*
Estbu

Abus
Date
Quantit

Figure XVII.5 : Reprsentation de lassociation entre buveur et vin

Conception des bases de donnes 667

2.2. PERCEPTION DU MONDE REL AVEC UML

UML (Universal Modelling Language) est donc le langage qui se veut universel pour
la modlisation objet. Nous lavons dj souvent approximativement utilis pour
reprsenter des objets. UML a t dvelopp en rponse lappel proposition lanc
par lOMG (Object Management Group). Il existe de nombreux ouvrages sur UML et
nous nous contenterons des constructions utiles pour modliser les bases de donnes.
Le lecteur dsirant en savoir plus pourra se reporter [Bouzeghoub97], [Muller98] ou
encore [Kettani98]. UML prsente beaucoup dautres diagrammes que ceux utiliss,
en particulier pour reprsenter les cas dutilisation, les squences, les transitions
dtats, les activits, les composants, etc. Nous utilisons essentiellement les diagrammes de classe, dassociation, dhritage et dagrgation.
Une classe est une extension du concept dentit avec des oprations, comme le
montre la figure XVII.6. Nous donnons en exemple la classe Voiture avec les oprations Dmarrer(), Acclrer(), Rouler() et Freiner(). UML distingue aussi les attributs
privs prcds de et publics nots +. Dautres niveaux de visibilit sont possibles.
Pour linstant, et par dfaut, nous supposons tous les attributs publics. Cela nest pas
trs conforme lobjet, mais les spcialistes des bases de donnes sont des briseurs
dencapsulation bien connus, car ils sintressent avant tout aux donnes !
Nom

attributs
oprations

Voiture

NV: Int
Type: String
Marque: Constructeur
Vitesse: Int
Km : Int
Dmarrer()
Acclrer()
Rouler(km:Int)
Freiner()

Figure XVII.6 : Reprsentation dune classe en UML

La dcouverte des classes, comme celle des entits, ncessite disoler les types
dobjets du monde rel qui ont un cycle de vie propre. Dans une description en langage naturel, les classes comme les entits correspondent souvent des noms. partir
des objets, il faut abstraire pour dcouvrir les proprits, attributs et mthodes. Une
rflexion sur le cycle de vie de lobjet et sur ses collaborations avec les autres objets
permet de prciser les mthodes, et par l les attributs manipuls par ces mthodes.
UML fournit des outils pour reprsenter cycle de vie et collaboration : ce sont les diagrammes dtat et de collaboration, dont ltude dpasse le cadre de cet ouvrage.
La dcouverte des classes conduit dcouvrir les liens de gnralisation et de spcialisation entre classes. Dans une description en langage naturel, les objets sont alors

668 BASES DE DONNES : OBJET ET RELATIONNEL

relis par le verbe tre (relation is a). UML permet la reprsentation de lhritage
comme indiqu figure XVII.7. Sil est possible de grouper les deux flches en une
seule, cela na pas de signification particulire. Si les deux sous-classes sont disjointes, une contrainte {Exclusive} peut tre explicitement note. De mme, il est possible de prciser {Inclusive} si tout objet se retrouve dans toutes les sous-classes. Un
nom discriminant peut tre ajout sur larc de spcialisation, pour distinguer diffrentes spcialisations dune classe.
Classe
de base

Personnes

Employs

Sous-classe
C1

Sous-classe
C2

Etudiants

Hommes

Personnes

{exclusif}

Femmes

Figure XVII.7 : Reprsentation et exemples de spcialisation en UML

Lagrgation est utilise pour reprsenter les situations o une classe est compose
dun ou plusieurs composants. UML permet de distinguer lagrgation indpendante
de lagrgation composite. La premire est une association particulire qui relie un
objet un ou plusieurs objets composants ; les deux classes sont deux classes autonomes. La seconde permet de reprsenter des objets composites rsultant de lagrgation de valeurs. Elle se distingue de la premire par un losange plein. Les diagrammes
reprsentant ces deux types dassociations sont symboliss figure XVII.8.
Classe
attributs
oprations

Composant

Attribut

attribut

nom

opration

opration

Figure XVII.8 : Reprsentation dagrgations en UML

Conception des bases de donnes 669

Les figures XVII.9 et XVII.10 illustrent les constructions introduites par deux tudes de
cas conduisant llaboration de schmas externes ou vues, ou encore paquetages (un
paquetage UML est un ensemble de composants objets qui peut comporter beaucoup
dautres lments). Chaque paquetage est reprsent par un rectangle tiquet contenant
ses composants. UML permet dajouter des notes tous les niveaux. Pour les paquetages, nous dfinissons dans la note associe la situation correspondante en franais.
La vie
Habite

Personne
*

nss
nom
prenoms
datenais

Adresse
1

tage
no
rue
code
ville

vieillir()
dormir()

dpend

*
Infrieur

Employ

Chaque personne habite

une adresse.
Une adresse se compose
d'un tage,
un n, une rue, un code
et une ville.
Une personne possde
un nss, un nom,
des prnoms et une datenais.
Les personnes vieillissent
et dorment.
Un employ est une personne.
Il a une fonction, un
salaire et des primes.
Un employ travaille.
Il dpend d'un suprieur
et a des infrieurs.

fonction
1 salaire
Suprieur primes
travailler()

Figure XVII.9 : Exemple de schma externe en UML

La voiture
Possde

Voiture

Date
Prix

rouler()
1

Moteur

Type

type
puissance

marque
code

dmarrer()
stopper()

nss
nom
prenoms
adresse
dmnager()

1
1

nveh
couleur
km

Personne

Acheter()

Une personne possde 0

N voitures,
chacune tant achete une
date et un certain prix.
Une personne a un nom,
un prnom, une adresse et
peut dmnager.
La voiture un nveh,
une couleur, un nombre de km
parcourus.
Rouler augmente le nombre
de km parcourus.
La voiture a un type intgr,
compos d'un code et d'une
marque.
La voiture se compose
d'un moteur
qui a un type et une puissance.
Le moteur peut dmarrer
et stopper.

Figure XVII.10 : Un autre exemple de schma externe en UML

670 BASES DE DONNES : OBJET ET RELATIONNEL

2.3. INTGRATION DE SCHMAS EXTERNES

Les schmas externes ou vues ou encore paquetages permettent donc de reprsenter
des sous-ensembles du schma conceptuel de la base de donnes. Construire le
schma externe ncessite dintgrer ces diffrentes parties, ce qui nest pas une tche
simple. Les difficults proviennent des recouvrements et des liens smantiques entre
parties. De nombreux travaux ont t effectus pour intgrer des schmas objet, non
seulement dans le domaine de la conception [Batini86, Navathe84], mais aussi dans
celui des bases de donnes objet fdres [WonKim95].
Les conflits peuvent concerner les noms des classes et associations (synonymes et
homonymes), les structures (attributs manquants, associations regroupes), les dfinitions dattributs (conflits, inclusion), les contraintes (cardinalits), etc. La
figure XVII.11 propose une liste plus ou moins exhaustive des conflits possibles
[WonKim95].
Classe Classe
Noms diffrents pour des classes quivalentes
Noms identiques pour des classes diffrentes
Inclusion de lune dans lautre
Intersection non vide
Contraintes entre instances
Attribut Attribut
Noms diffrents pour des attributs quivalents
Noms identiques pour des attributs diffrents
Types diffrents
Compositions diffrentes
Classe Attribut
Significations identiques
Compositions similaires
Association Association
Noms diffrents pour des associations quivalentes
Noms identiques pour des associations diffrentes
Cardinalits diffrentes
Donnes diffrentes
Compositions de plusieurs autres
Agrgation Agrgation
Agrgation composite versus non composite
Cardinalits diffrentes
Association Attribut
Association versus rfrence
Cardinalits incompatibles

Figure XVII.11 : Quelques types de conflits entre schmas

Conception des bases de donnes 671

Le premier problme est disoler les conflits. Cela ncessite le passage par un dictionnaire unique des noms, voire par une ontologie. Une ontologie est une dfinition complte des concepts, avec leurs relations smantiques. Lutilisation dune ontologie spcifique au domaine permet de ramener les concepts un rfrentiel unique et de
mesurer la distance et le recouvrement entre eux [Mtais97]. On peut ainsi isoler les
conflits potentiels.
Pour chaque cas, des solutions doivent tre envisages, telles que :
Changement de dnomination de classes, dassociations ou dattributs
Ajout dattributs ou remplacement par des oprations
Dfinition de classes plus gnrales ou plus spcifiques
Transformation dagrgation en objets composites et vice versa
Redfinition de types plus gnraux
Transformation de reprsentation
Conversion et changement dunits.
Certains conflits ne sont solubles que manuellement. Un outil graphique daide
lintgration peut tre avantageusement utilis.
Possde

Voiture

1
1

Moteur

Type

type
puissance

marque
code

dmarrer()
stopper()

Dpend

Suprieur

dmnager()

Habitation
tage
no
rue
code
ville

vieillir()
dormir()

Vendre()

Infrieur

nss
nom
prenoms
datenais

Date
Prix

rouler()
1

nveh
couleur
km

Habite

Personne

Employ
fonction
salaire
primes

Buveur
type
tat
boire()

travailler()

Boire
1..*

date
quantit

Vin
nv
cru
millsime
degr
qualit

EmployBuveur

Figure XVII.12 : Exemple de schma intgr UML

En rsum, aprs des transformations de schmas automatiques ou manuelles, les

schmas externes peuvent tre intgrs afin dobtenir un schma global cohrent avec

672 BASES DE DONNES : OBJET ET RELATIONNEL

un minimum de redondance. titre dillustration, la figure XVII.12 (ci-avant) propose un schma intgr rsultant de lintgration des vues La vie et La voiture
avec nos ternels buveurs ( La fte ). Vous pouvez reprer les transformations
effectues, qui sont assez rduites.

3. CONCEPTION DU SCHMA LOGIQUE

Cette section explique comment obtenir un schma relationnel ou objet-relationnel partir dun schma objet reprsent en UML. Nous proposons deux mthodes, la premire
pour passer de lobjet (et donc dentit-association qui en est un cas particulier) au relationnel appele UML/R, la seconde pour passer de lobjet lobjet-relationnel, appele
UML/OR ou UML/RO selon que la dominance est donne lobjet ou au relationnel.

3.1. PASSAGE AU RELATIONNEL : LA MTHODE UML/R

3.1.1. Cas des entits et associations
Examinons tout dabord comment traduire des entits et associations simples. Le
modle relationnel se prte bien la reprsentation des entits et des associations. Les
rgles sont les suivantes :
R1. Une entit est reprsente par une relation (table) de mme nom ayant pour
attributs la liste des attributs de lentit.
R2. Une association est reprsente par une relation de mme nom ayant pour attributs
la liste des cls des entits participantes et les attributs propres de lassociation.
Pour appliquer la rgle 2, chaque table rsultant de la rgle 1 doit possder une cl
primaire, cest--dire un groupe dattributs (1, 2 ou 3 au plus sont conseills) qui
dtermine tout instant un tuple unique dans la table. Sil nen est pas ainsi, il faut
ajouter une cl qui est un numro de tuple (une squence attribue par le systme en
SQL2). Les tables rsultant des associations ont pour cls la liste des cls des entits
participantes avec ventuellement, en cas dassociation multivalue, une ou plusieurs
donnes propres de lassociation.
Par exemple, les entits PERSONNE et VOITURE de la figure XVII.4 seront respectivement reprsentes par les relations :
PERSONNE (NSS, NOM, PRENOM, DATENAIS)
VOITURE (NV, MARQUE, TYPE, PUISSANCE, COULEUR).

Les cls sont respectivement NSS et NV. En consquence, lassociation POSSDE

sera reprsente par la relation :

Conception des bases de donnes 673

POSSEDE (NSS, NV, DATE, PRIX).

Les transformations proposes donnent autant de relations que dentits et dassociations. Il est possible de regrouper certaines relations et associations dans les cas particuliers o un tuple dune table rfrence un et un seul tuple de lassociation. Une telle
association est dite bijective avec lentit : en effet, tout tuple de la table correspond
un tuple de lassociation et rciproquement. La rgle est la suivante :
R3. Une association bijective, cest--dire de cardinalits minimale et maximale 1,
peut tre regroupe en une seule table avec la relation attache par jointure sur
la cl de lentit.
Cette rgle est illustre figure XVII.13. Dans le cas o lassociation est 1..1 des deux
cts, la rgle peut tre applique droite ou gauche, et si les deux entits ne sont
relies aucune autre association, elles peuvent mme tre regroupes en une seule table.
Pour implmenter un modle objet, il nest pas ncessaire d avoir une BD objet. Audel des entits et associations, tous les concepts dun modle objet peuvent tre
implments avec un SGBD relationnel. Alors que les tables mmorisent ltat des
objets, les mthodes apparaissent comme des attributs calculs. Elles seront gnralement implmentes sous forme de procdures stockes. Nous allons maintenant examiner le passage dun modle UML au relationnel, sachant que ce que nous avons dit
pour les associations restent vrai dans le contexte objet. La plupart des rgles dcrites
ci-dessous ont t implmentes dans le systme expert SECSI daide la conception
de bases de donnes [Bouzeghoub85].
Ent1
K1
A1

An

Ass

Abus
D1

Dp

Ent2
K2
B1

Bm

Ent1(K1, A1, , An)

Ent2Ass (K2,B1,Bm, K1,D1,Dp)

Figure XVII.13 : Translation dassociation 1..1

3.1.2. Cas des gnralisations avec hritage

Les systmes relationnels ne connaissent pas les concepts de gnralisation et dhritage. Il faut donc raliser statiquement ce dernier lors de la transformation du schma.
Pour les donnes, cela ne pose pas trop de problmes et plusieurs solutions sont pos-

674 BASES DE DONNES : OBJET ET RELATIONNEL

sibles, consistant toutes aplatir les hirarchies de spcialisation. Pour les mthodes,
le polymorphisme doit tre ralis dans le corps de la mthode par des tests (CASE).
Nous examinons ici la transformation des donnes, comme il se doit pour une base de
donnes.
La solution la plus naturelle pour traduire une hirarchie de gnralisations de classes
C1, C2Cn vers une classe C est dappliquer la rgle suivante, en plus de la rgle R1
qui conduit traduire chaque classe (ou entit) comme une table avec une cl primaire, la rgle suivante :
R4.a Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par rptition de la cl de la table reprsentant C au niveau de chacune des
tables reprsentant C1, C2Cn.
Cette solution conduit une table par classe (voir figure XVII.14(a)). Lorsquon souhaite retrouver un attribut hrit dans une classe drive, il faut effectuer une jointure
avec la table reprsentant la classe de base. Lhritage doit donc tre accompli par les
programmes dapplication. La dfinition dune vue jointure des tables drives et de
la table de base (par exemple C|X|C1) permet dautomatiser lhritage.
Dautres solutions sont possibles pour traduire des spcialisations, comme le montre
la figure XVII.14(b) et (c). La solution (b) consiste faire une table par classe feuille
de la hirarchie en appliquant la rgle suivante :
R4.b Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par rptition des attributs reprsentant C au niveau de chacune des tables
reprsentant C1, C2Cn et par transformation de C en une vue drive de C1,
C2Cn par union des projections sur les attributs de C.
Le problme avec cette solution survient lorsque les classes C1, C2, Cn ne sont pas
exclusives et contiennent des objets communs. Les attributs de C sont alors rpts
dans chacune des tables C1, C2Cn, ce qui pose des problmes de cohrence. Cette
rgle sera donc seulement applique dans le cas dhritage exclusif. Par exemple, il
est intressant de reprsenter la hirarchie dhritage FEMMES, HOMMES PERSONNES de la figure XVII.7 par les tables FEMMES et HOMMES, la table PERSONNES pouvant tre drive par une vue. Au contraire, la mme technique utilise
pour la hirarchie dhritage EMPLOYES, ETUDIANTS PERSONNES conduirait dupliquer les employs tudiants. On prfrera alors appliquer la rgle R4.a
conduisant trois tables EMPLOYES, ETUDIANTS et PERSONNES, chacune ayant
pour cl le numro de scurit sociale de la personne.
Une autre solution encore possible consiste implmenter une seule table comme
illustr figure XVII.14(c) :
R4.c Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par une table unique comportant la traduction de la classe C complte avec les
attributs de C1, C2Cn, les tables correspondant C1, C2Cn tant des vues
drives de C par projection sur les attributs pertinents.

Conception des bases de donnes 675

Classe
C

Sous-classe
C1

C K
C1 K
C2 K

(a)

Sous-classe
C2

C1 C
C2 C

(b)

C C1 C2

(c)

Figure XVII.14 : Traduction de hirarchie dhritage en relationnel

Le problme avec cette solution survient lorsquun objet de la classe C na pas de spcialisation dans une sous classe Ci : dans ce cas, tous les attributs de la classe Ci apparaissent comme des valeurs nulles ! Par exemple, pour la hirarchie FEMMES,
HOMMES PERSONNES, les attributs spcifiques aux femmes seront nuls pour
chaque homme dans la table PERSONNES gnrale (par exemple, le nom de jeune
fille). Pour la hirarchie EMPLOYES, ETUDIANTS PERSONNES, tout employ
non tudiant aura les attributs dtudiants nuls et tout tudiant non employ aura les
attributs spcifiques aux tudiants nuls. Cette solution nest donc bonne que dans le
cas dhritage complet, o chaque objet de la classe de base est membre de la sousclasse.
En rsum, les diffrents cas sont illustrs figure XVII.14. Bien sr, ils peuvent tre
mixs et il faut rflchir pour chaque sous-classe. Certaines peuvent par exemple tre
regroupes avec la classe de base, dautres implmentes de manire autonome.

3.1.3. Cas des agrgations et collections

Comme nous lavons vu ci-dessus, UML propose deux cas dagrgations : les agrgations indpendantes et les agrgations composites.
Lagrgation indpendante nest rien de plus quun cas particulier dassociation :
elle sera donc traduite en appliquant les rgles des associations. Un problme peut tre
que les agrgations nont pas de nom en gnral : il faut en gnrer un, par exemple

676 BASES DE DONNES : OBJET ET RELATIONNEL

par concatnation des noms des entits participantes. On ajoutera un nom de rle si
plusieurs agrgations indpendantes relient deux classes.
Lagrgation composite correspond un groupe dattributs (et mthodes) imbriqus
dans lobjet composite. Dans le cas de bijection (cardinalit 1..1), tous les attributs de la
classe cible (le composant) sont simplement ajouts la table reprsentant la classe
source (le compos). La classe cible est reprsente par une vue. La rgle est la suivante :
R5. Une classe dpendant dune autre par une agrgation composite monovalue
est reprsente par des attributs ajouts la table reprsentant lobjet composite
et si ncessaire transforme en une vue, sinon omise.
Cette rgle est applique figure XVII.15. Au-del, le relationnel pur ne permet pas de
traduire les agrgations composites multivalues par une seule table. On procde alors
comme avec une agrgation indpendante et plus gnralement une association. Des
contraintes dintgrit additionnelles peuvent tre ajoutes, comme nous le verrons cidessous.
Marque et code sont intgrs
car l'agrgation composite est monovalue.

Voiture
nveh
couleur
km

VOITURE(NVEH, COULEUR, KM, MARQUE, CODE)

PORTE(NVEH, NPOR, HAUTEUR, LARGEUR)

rouler()
1

1
4

Porte

Type

hauteur
largeur

marque
code

PORTE est spare car l'agrgation composite

est multivalue.
NVEH, NPOR est regroup avec PORTE
car l'association est bijective.

Figure XVII.15 : Traduction dagrgations composites

Les attributs multivalus peuvent tre intgrs directement dans une classe par le
biais de collections SET<X>, LIST<X>, BAG<X>, etc. Une bonne modlisation
UML traduit de tels attributs en agrgations composites. Cependant, il est permis
dutiliser des templates ; alors le problme de la traduction en relationnel se pose.
Deux cas sont considrer pour traduire en relationnel. Si le nombre maximal N de
valeurs est connu et faible (< 5 par exemple), il est possible de dclarer N colonnes, de
nom A1, A2,, etc., o A est le nom de lattribut. Cette solution manque cependant de
flexibilit et conduit des valeurs nulles ds quil y a moins de N valeurs. Une solution
plus gnrale consiste isoler la cl K de la table rsultant de la classe ayant un attribut
collection, et crer une table rpertoriant les valeurs de la collection associe la cl.
La table a donc pour schma AS (K, A) et donne les valeurs de A pour chaque valeur
de K. Par exemple, si une collection a trois valeurs v1, v2, v3 pour la cl 100, (100-v1),

Conception des bases de donnes 677

(100-v2) et (100-v3) seront trois tuples de la table AS. Les collections seront reconstitues par des jointures lors des interrogations. Cette solution est connue sous le nom
de passage en premire forme normale et nous y reviendrons ci-dessous.

3.1.4. Gnration de contraintes dintgrit

Au-del des tables, le passage dun modle objet exprim en UML au relationnel permet de gnrer des contraintes dintgrit rfrentielles. Les associations sont particulirement utiles pour cela. Voici deux rgles applicables :
R6. Toute association E1RE2 reprsente par une table R non intgre E1
ou E2 donne naissance deux contraintes rfrentielles : R.K(E1) rfrence E1
et R.K(E2) rfrence E2, K(Ei) dsignant la cl de Ei.
R7. Toute association E1RE2 de cardinalit minimale 1 sur E2 reprsente
par une table non intgre E1 donne naissance une contrainte rfrentielle
additionnelle : E1.K(E1) rfrence R.K(E1).
Ces rgles sont illustres figure XVII.16 sur lassociation Boire entre Buveurs et
Vins. La contrainte de Buveurs vers Abus rsulte du fait que la cardinalit minimale de 1 signifie que pour un objet quelconque, il existe au moins une instance
dassociation (rgle 7). Les contraintes rfrentielles de la table associative Abus vers
Buveurs et Vins proviennent du fait que lassociation implique lexistence des
objets associs (rgle 6). En thorie, les associations sont donc trs contraignantes
pour le modle relationnel sous-jacent. On omet parfois les contraintes rsultant de la
rgle 6, ce qui signifie quon tolre des associations entre objets non existants.
Buveurs
nb
nom
type

Boire

1..*
Estbu

Abus
Abus
Date
Quantit

Vins
nv
cru
millsime
degr

cause de la cardinalit min de 1.

BUVEURS (NB REF ABUS.NB, NOM, TYPE)

VINS (NV, CRU, MILLESIME, DEGRE)
ABUS(NB REF BUVEURS, NV REF VINS, DATE, QUANTITE)

cause de l'association (obligatoire).

Figure XVII.16 : Gnration de contraintes rfrentielles

678 BASES DE DONNES : OBJET ET RELATIONNEL

3.2. PASSAGE LOBJET-RELATIONNEL :

UML/RO OU UML/OR?
Les SGBD deviennent objet-relationnel avec SQL3, comme nous lavons montr au
chapitre XIII. Passer dun modle UML un modle objet-relationnel est la fois
plus simple et plus compliqu. Cest plus simple en thorie car lobjet-relationnel supporte directement les associations, lhritage et les collections. Cest plus complexe
car il y a maintenant des types et des tables, et tous les types possibles en objet ne sont
pas possibles en objet-relationnel. De plus, la reprsentation relationnelle reste possible. Alors que faire ? Deux approches au moins sont possibles : lune tendant simplement lapproche relationnelle avec des types utilisateurs, lautre beaucoup plus
proche de lobjet.
Lapproche relationnelle tendue (note UML/RO, le R venant en premier) consiste
faire une premire passe sur le schma objet afin disoler les types intressants.
Ceux-ci peuvent tre des groupes dattributs qui apparaissent de manire rptitive
dans diffrentes classes ou des groupes dattributs supports de mthodes. On sattachera chercher des types significatifs pour lentreprise ou le mtier. Les types resteront rduits quelques attributs, et couvriront rarement une classe entire. Lobjectif
est de rester dans une dmarche relationnelle, simplement en ajoutant quelques types
fondamentaux aux types de base SQL entier, rel, caractres et date. Une fois isols,
ces types seront dfinis comme tels, des attributs typs remplaceront les groupes isols, et la dmarche UML/R prcdente sera applique pour gnrer les tables. Cette
mthode prsente lavantage de continuit et laisse possible lapplication des techniques de normalisation que nous allons tudier ci-dessous, en considrant les instances des types utiliss comme atomiques.
La dmarche objet (note UML/OR, le O venant en premier) au contraire va tout
transformer en type et voir les tables comme des extensions de type. Une technique
peut consister procder systmatiquement comme suit :
1. Pour chaque classe, gnrer le type SQL3 correspondant par la commande
CREATE TYPE. Utiliser lhritage de type pour traduire les spcialisations et
lagrgation de type pour les agrgations composites.
2. Si une classe nest pas cible dune agrgation composite ou dune gnralisation,
alors limplmenter comme une table dobjets du type associ. Cela conduit :
implmenter toutes les classes feuille des hirarchies dhritage en incluant les
attributs hrits, comme dans le cas (b) de la figure XVII.14. Dautres choix sont
possibles, comme cela a dj t signal ci-dessus.
respecter les agrgations composites en ce sens que les instances de la classe
cible figureront dans la table associe lautre classe.
3. Implmenter toutes les associations par des attributs rfrences mono ou multivalus (en respectant les cardinalits maximum de lassociation) dune table vers une
autre, ventuellement dans les deux sens. Lutilisation de rfrences dans les deux

Conception des bases de donnes 679

sens permet les parcours de chemins dans les deux sens. Cest utile si les requtes le
ncessitent.
En fait, aujourdhui bien peu de SGBD objet-relationnel supporteront une telle
dmarche pour une grosse base (quelques centaines de classes). Elle conduit en effet
grer beaucoup de types et beaucoup de rfrences. De plus, le schma rsultat ne
peut tre normalis simplement et peut prsenter des difficults dvolutions, les types
tant souvent lis par hritage ou par agrgation. Nous conseillerons donc plutt
lapproche UML/RO plus compatible avec la thorie hrite du relationnel que nous
tudions ci-dessous.

4. AFFINEMENT DU SCHMA LOGIQUE

Cette section justifie la ncessit dune tape daffinement des schmas relationnels et
introduit les approches possibles pour rduire les problmes soulevs par une mauvaise perception du rel.

4.1. ANOMALIES DE MISE JOUR

Une mauvaise conception des entits et associations reprsentant le monde rel modlis conduit des relations problmatiques. Imaginons par exemple que lon isole une
entit unique PROPRIETAIRE contenant tous les attributs des trois relations PERSONNE, VOITURE et POSSEDE. Ainsi, nous pourrions reprsenter toutes les informations modlises par une seule table. La figure XVII.17 reprsente une extension
possible de cette table.
NV

Marque

Type

672RH75

Renault

RME8

Puiss. Coul.
8

Rouge 142032

NSS

Nom

Prnom

Date

Prix

Martin

Jacques

10021998

70 000

800AB64

Peugeot

P206A

Bleue

686HK75

Citron

BX20V

Verte

142032

Martin

Jacques

11061999

90 000

158037

Dupond

Pierre

200499

120 000

720CD63

Citron

2CV8

400XY75

Renault

RCL5

Verte

158037

Dupond

Pierre

200278

5 000

Verte

275045

Fantas

Julie

110996

20 000

280037

Schiffer

Claudia

963TX63

Renault

P306B

Bleue

Figure XVII.17 : Extension de la relation Propritaire

680 BASES DE DONNES : OBJET ET RELATIONNEL

La relation reprsente figure XVII.17 souffre de plusieurs types danomalies

[Codd72, Fagin81] :
1. Tout dabord, des donnes sont redondantes : par exemple, MARTIN Jacques et
DUPOND Pierre apparaissent deux fois ; plus gnralement, une personne apparat
autant de fois quelle possde de voitures.
2. Ces redondances conduisent des risques dincohrences lors des mises jour. Par
exemple, si lon saperoit que le prnom de DUPOND nest pas Pierre mais Jean,
il faudra veiller mettre jour les deux tuples contenant DUPOND, sous peine de
voir apparatre un DUPOND Pierre et un DUPOND Jean.
3. Il est ncessaire dautoriser la prsence de valeurs nulles dans une telle relation afin
de pouvoir conserver dans la base des voitures sans propritaire ou des personnes
ne possdant pas de voitures.
En rsum, une relation qui ne reprsente pas de vraies entits ou associations semble
donc souffrir de la prsence de donnes redondantes et dincohrences potentielles, et
ncessite le codage de valeurs nulles. En ralit, un fait lmentaire est enregistr plusieurs fois dans une relation rsultant de la jointure de plusieurs entits et association. De
plus, les faits lmentaires sont artificiellement associs si bien quils ne peuvent tre
insrs indpendamment. Il y a tout intrt liminer ces anomalies dinsertion, de
mise jour et de suppression afin de faciliter la manipulation des relations.

4.2. PERTE DINFORMATIONS

Une analyse simpliste des exemples prcdents pourrait laisser croire que les relations
problmatiques sont celles ayant trop dattributs. Une mthode simple pour viter les
problmes pourraient tre de nutiliser que des relations binaires deux colonnes.
Malheureusement, des faits lmentaires associent plus de deux valeurs dattributs. Cela
se traduit par le fait quun dcoupage par projections dune table peut conduire ne plus
tre capable de retrouver les informations du monde rel reprsentes par jointure : on
dit quil y a perte dinformations. Un exemple est reprsent figure XVII.18.
VIN1

NV

CRU

100
200
300
400
500

Volnay
Chablis
Chablis
Volnay
Sancerre

VIN2

CRU

MILL

DEGRE

Volnay
Chablis
Chablis
Sancerre

1992
1997
1999
2002

11.5
12.3
12.1
12.0

Figure XVII.18 : Exemple de perte dinformations

Conception des bases de donnes 681

Lentit VIN a t reprsente par deux tables VIN1 et VIN2. En interrogeant par des
jointures et projections, et plus gnralement en SQL, il est impossible de retrouver
prcisment le degr dun vin ou la qualit dun cru millsim. Il y a perte de smantique car la jointure naturelle des deux tables VIN1 et VIN2 sur lattribut commun
CRU ne permet pas de retrouver les vins de dpart, avec un degr unique (par exemple
pour les Chablis).

4.3. LAPPROCHE PAR DCOMPOSITION

Lapproche par dcomposition la conception des schmas relationnels tend partir
dune relation compose de tous les attributs, appele la relation universelle, et la
dcomposer en sous-relations ne souffrant pas des anomalies prcdemment signales.
Notion XVII.2 : Relation universelle (Universal relation)
Table unique dont le schma est compos par union de tous les attributs des tables constituant la
base.

La dfinition de cette relation universelle suppose pralablement une nomination des

attributs telle que deux attributs reprsentant le mme concept aient le mme nom et
deux attributs reprsentant des concepts distincts aient des noms diffrents.
Le processus de dcomposition est un processus de raffinement successif qui doit
aboutir (du moins on lespre) isoler des entits et des associations lmentaires, ou
si lon prfre canoniques, du monde rel. Il doit tre ralis partir dune bonne
comprhension des proprits smantiques des donnes. Cette approche est illustre
par la figure XVII.19. La comprhension de la thorie de la dcomposition des relations ncessite la bonne connaissance des deux oprations lmentaires de manipulation de relations que sont la projection et la jointure. En effet, nous allons dcomposer
par projection et recomposer par jointure.
NV MARQUE

TYPE

NV MARQUE

PUISS. COUL. NSS NOM

TYPE

PUISS. COUL.

PRNOM DATE PRIX

NV NSS NOM

NSS NOM

PRNOM

PRNOM DATE PRIX

NV NSS DATE PRIX

Figure XVII.19 : Le processus de dcomposition

682 BASES DE DONNES : OBJET ET RELATIONNEL

Il est maintenant possible dintroduire plus prcisment la notion de dcomposition

[Ullman88].
Notion XVII.3 : Dcomposition (Decomposition)
Remplacement dune relation R (A1, A2 An) par une collection de relations R1, R2, Rn obtenues par des projections de R sur des sous-ensembles dattributs dont lunion contient tous les attributs de R.

Par suite, lors dune dcomposition, le schma de relation R (A1, A2 An) est remplac
par une collection de schmas dont lunion des attributs est (A1, A2 An). La jointure
naturelle R1 |X| R2 |X| Rn constitue donc une relation de mme schma que R, mais
dont les tuples ne sont pas forcment les mmes que ceux de R. titre dillustration, la
figure XVII.20 propose deux dcompositions possibles pour la relation VOITURE.
NV

MARQUE

TYPE

PUISS.

872RH75

Peugeot

P206A

Bleue

975AB80

Peugeot

P206A

Rouge

Dcomposition 1

R1

Dcomposition 2

NV

TYPE

COUL.

872RH75
975AB80

P206A
P206A

Bleue
Rouge

V1

V2

R2

COUL.

TYPE

MARQ.

PUISS.

P206A

Peugeot

V3

NV

TYPE

872RH75
975AB80

P206A
P206A

TYPE

PUISS.

COUL.

P206A
P206A

7
7

Bleue
Rouge

TYPE

MARQ.

P206A

Peugeot

Figure XVII.20 : Deux dcompositions possibles de la relation Voiture

Si lon admet qu un type de vhicule sont associes une seule marque et une seule
puissance (ce qui est vrai pour les tuples figurant sur des cartes grises), la dcomposi-

Conception des bases de donnes 683

tion 1 est plus plaisante que lautre : elle permet de retrouver toutes les informations
par jointure, alors que la dcomposition 2 ne permet pas de retrouver la couleur dun
vhicule ; la jointure V1
V2
V3 est diffrente de la relation initiale VOITURE. Do la notion de dcomposition sans perte (dinformation).
Notion XVII.4 : Dcomposition sans perte (Lossless join decomposition)
Dcomposition dune relation R en R1, R2 Rn telle que pour toute extension de R, on ait :
R = R1

R2

Rn.

Le problme de la conception des bases de donnes relationnelles peut donc tre

peru comme celui de dcomposer la relation universelle compose de tous les attributs en sous-relations ne souffrant pas des anomalies vues ci-dessus, de sorte obtenir
une dcomposition sans perte. La dcomposition a t introduite par Codd [Codd71]
et a donn lieu a de nombreux travaux la fin des annes 70 pour casser en morceaux les relations . Nous allons ci-dessous tudier les principales mthodes proposes pour effectuer une telle dcomposition, qui devrait permettre de dterminer des
entits et associations canoniques du monde rel, donc en fait de gnrer un schma
conceptuel. Ces mthodes ont t dveloppes dans [Rissanen73] puis gnralises
dans [Fagin77] et [Zaniolo81].
En pratique, on ne part gnralement pas de la relation universelle, mais plutt du
schma logique obtenu par la modlisation entit-association ou objet, puis par application des rgles de passage au relationnel tudies ci-dessus. Ce processus conduit de
fait une premire dcomposition intuitive. Si elle est trop fine, il se peut que des
informations soient perdues.

4.4. LAPPROCHE PAR SYNTHSE

Lapproche par synthse [Bernstein76] procde par recomposition des relations
partir dun ensemble dattributs indpendants. Fonde sur les proprits smantiques
des attributs et des liens entre eux, les relations sont composes progressivement de
faon ne pas souffrir des anomalies prcdemment mentionnes (voir
figure XVII.21 page suivante). Les approches par synthse sappuient souvent sur un
graphe reprsentant les liens inter-attributs. Nous verrons un algorithme de synthse
plus loin.

684 BASES DE DONNES : OBJET ET RELATIONNEL

DATE

NSS

NSS

NV PRIX

NV

COUL.

MARQUE

DATE
NV PRIX

PUISS.

TYPE

DATE

MARQUE

NV
PRIX

TYPE

PRNOM

NOM

NSS
PUISS.

NSS
PRNOM
NOM

COUL.
PRNOM

NOM

Figure XVII.21 : Illustration de lapproche par synthse

5. DPENDANCES FONCTIONNELLES
Dans cette section, nous tudions les liens smantiques entre attributs, particulirement les liens fonctionnels.

5.1. QUEST-CE QUUNE DPENDANCE

FONCTIONNELLE ?
La notion de dpendance fonctionnelle fut introduite ds le dbut du relationnel par
CODD afin de caractriser des relations pouvant tre dcomposes sans perte dinformations.
Notion XVII.5 : Dpendance fonctionnelle (Functional dependency)
Soit R (A1, A2 An) un schma de relation, et X et Y des sous-ensembles de {A1, A2, An}. On
dit que X Y (X dtermine Y, ou Y dpend fonctionnellement de X) si pour toute extension r de R,
pour tout tuple t1 et t2 de r, on a : X (t1) = X (t2) Y (t1) = Y (t2)

Conception des bases de donnes 685

Plus simplement, un attribut (ou groupe dattributs) Y dpend fonctionnellement dun

attribut (ou groupe dattributs) X, si, tant donn une valeur de X, il lui correspond
une valeur unique de Y (quel que soit linstant considr).
titre dexemple, dans la relation VOITURE, les dpendances fonctionnelles suivantes existent :
NV COULEUR
TYPE MARQUE
TYPE PUISSANCE
(TYPE, MARQUE) PUISSANCE

Par contre, les dpendances fonctionnelles suivantes sont inexistantes :

PUISSANCE TYPE
TYPE COULEUR

Il est essentiel de bien remarquer quune dpendance fonctionnelle (en abrg, DF)
est une assertion sur toutes les valeurs possibles et non pas sur les valeurs actuelles :
elle caractrise une intention et non pas une extension dune relation. Autrement dit, il
est impossible de dduire les DF dune ralisation particulire dune relation. La seule
manire de dterminer une DF est de regarder soigneusement ce que signifient les
attributs car ce sont des assertions sur le monde rel qui lient les valeurs possibles des
attributs entre elles. Les DF devraient ainsi tre dclares par ladministrateur dentreprise au niveau du schma conceptuel et un bon SGBD devrait les faire respecter.

5.2. PROPRITS DES DPENDANCES

FONCTIONNELLES
Les DF obissent plusieurs rgles dinfrences triviales. Les trois rgles suivantes
composent les axiomes des dpendances fonctionnelles et sont connues dans la littrature sous le nom daxiomes dArmstrong [Armstrong74] :
Rflexivit : Y
X X Y ; tout ensemble dattributs dtermine lui-mme ou
une partie de lui-mme.
Augmentation : X Y XZ YZ ; si X dtermine Y, les deux ensembles
dattributs peuvent tre enrichis par un mme troisime.
Transitivit : X Y et Y Z X Z ; cette rgle est moins triviale et provient
du fait que le compos de deux fonctions dont limage de lune est le domaine de
lautre est une fonction. Par exemple, des dpendances NV TYPE et
TYPE PUISSANCE, on dduit NV PUISSANCE.
Plusieurs autres rgles se dduisent de ces axiomes de base :
Union : X Y et X Z X YZ.
Pseudo-transitivit : X Y et WY Z WX Z.

686 BASES DE DONNES : OBJET ET RELATIONNEL

Dcomposition : X Y et Z
Y X Z.
partir de ces rgles, il est possible dintroduire la notion de dpendance fonctionnelle lmentaire [Zaniolo81].
Notion XVII.6 : Dpendance fonctionnelle lmentaire
(Elementary functional dependancy)
Dpendance fonctionnelle de la forme X A, o A est un attribut unique nappartenant pas X (A
X) et o il nexiste pas X X tel que X A.

La seule rgle dinfrence qui sapplique aux dpendances fonctionnelles lmentaires est la transitivit.

5.3. GRAPHE DES DPENDANCES FONCTIONNELLES

Soit un ensemble F de dpendances fonctionnelles lmentaires. Si tous les attributs
gauches sont uniques, il est possible de visualiser cet ensemble de DF par un graphe
appel graphe des dpendances fonctionnelles. titre dexemple, nous considrons
les dpendances fonctionnelles entre les attributs de la relation VOITURE
figure XVII.22.
NV

COULEUR

TYPE

MARQUE

PUISSANCE

Figure XVII.22 : Exemple de graphe des DF

Il nest pas toujours possible de reprsenter les DF dune relation par un graphe
simple : si une partie gauche dune DF comporte plus dun attribut, il faut introduire
des arcs reprsentant une association de plusieurs sommets vers un sommet. Nous
pouvons alors utiliser la notation des rseaux de Ptri pour reprsenter les dpendances (voir figure XVII.23).
En effet, la relation :
REDUCTION (CRU, TYPE, CLIENT, REMISE)

Conception des bases de donnes 687

dans laquelle :
(a) un cru possde un type associ et un seul,
(b) les rductions sont effectues selon le type et le client,
comporte une dpendance partie gauche multiple :
TYPE, CLIENT REMISE.

CRU

TYPE

CLIENT

REMISE

CHENAS
MEDOC
JULIENAS

A
A
B

C1
C2
C1

3%
5%
4%

CRU

TYPE
CLIENT

CRU TYPE
TYPE, CLIENT REMISE

REMISE

Figure XVII.23 : Exemple de rseau de DF

De mme, la relation CODE POSTAL (CODE, VILLE, RUE) comporte les DF :

(VILLE, RUE) CODE
CODE VILLE.

La dpendance (VILLE,RUE) CODE ncessite un rseau.

5.4. FERMETURE TRANSITIVE

ET COUVERTURE MINIMALE
partir dun ensemble de DF lmentaires, on peut composer par transitivit dautres
DF lmentaires. On aboutit ainsi la notion de fermeture transitive dun ensemble F
de DF lmentaires : cest lensemble des DF lmentaires considres enrichi de
toutes les DF lmentaires dduites par transitivit.
Par exemple, partir de lensemble de DF :
F =

{ NV TYPE ; TYPE MARQUE ; TYPE PUISSANCE ;

NV COULEUR}

on dduit la fermeture transitive :

F+ = F {NV MARQUE ; NV PUISSANCE}

688 BASES DE DONNES : OBJET ET RELATIONNEL

Le graphe correspondant F+ est reprsent figure XVII.24.

NV

TYPE

COULEUR

MARQUE

PUISSANCE

Figure XVII.24 : Exemple de fermeture transitive

partir de la notion de fermeture transitive, il est possible de dfinir lquivalence de

deux ensembles de DF lmentaires : deux ensembles sont quivalents sils ont la
mme fermeture transitive. Par suite, il est intressant de dterminer un sousensemble minimal de DF permettant de gnrer toutes les autres. Cest la couverture
minimale dun ensemble de DF.
Notion XVII.7 : Couverture minimale (Minimal cover)
Ensemble F de DF lmentaires associ un ensemble dattributs vrifiant les proprits suivantes :
1. Aucune dpendance dans F nest redondante, ce qui signifie que pour toute DF f de F, F f nest
pas quivalent F.
2. Toute DF lmentaire des attributs est dans la fermeture transitive de F (note F+).

Il a t montr [Delobel73] que tout ensemble de DF a une couverture minimale qui

nest en gnral pas unique. Par exemple :
F =

{NV TYPE ; TYPE MARQUE ; TYPE PUISSANCE ;

NV COULEUR

est une couverture minimale pour lensemble des DF de VOITURE. La couverture

minimale va constituer un lment essentiel pour composer des relations sans perte
dinformations directement partir des attributs.

5.5. RETOUR SUR LA NOTION DE CL DE RELATION

La notion de cl de relation est un concept de base du modle relationnel. Bien que la
notion intuitive de cl soit bien connue, il est possible den donner une dfinition plus
formelle partir de celle de dpendance fonctionnelle, comme suit.

Conception des bases de donnes 689

Notion XVII.8 : Cl de relation (Relation key)

Sous-ensemble X des attributs dune relation R (A1, A2, A2) tel que :
1. X A1 A2 An.
2. Il nexiste pas de sous-ensemble Y X tel que Y A1 A2 An.

En clair, une cl est un ensemble minimal dattributs qui dtermine tous les autres. Un
ensemble dattributs qui inclut une cl est appel supercl. Par exemple, NV est une
cl de la relation VOITURE, alors que (NV, TYPE) nest pas une cl mais une supercl. Il peut y avoir plusieurs cls pour une mme relation : on en choisit en gnral
une comme cl primaire. On parle parfois de cl candidate pour dsigner une cl
quelconque.

6. LES TROIS PREMIRES FORMES

NORMALES
Les trois premires formes normales ont pour objectif de permettre la dcomposition
de relations sans perdre dinformations, partir de la notion de dpendance fonctionnelle [Codd72]. Lobjectif de cette dcomposition est daboutir un schma conceptuel reprsentant les entits et les associations canoniques du monde rel.

6.1. PREMIRE FORME NORMALE

La premire forme normale permet simplement dobtenir des tables rectangulaires
sans attributs multivalus irrguliers.
Notion XVII.9 : Premire forme normale (First normal form)
Une relation est en premire forme normale si tout attribut contient une valeur atomique.

Cette forme normale est justifie par la simplicit et lesthtique. Elle consiste simplement viter les domaines composs de plusieurs valeurs. Plusieurs dcompositions
sont possibles, comme vu ci-dessus. Par exemple, la relation PERSONNE(NOM, PRENOMS) pourra tre dcompose en PERSONNE1(NOM, PRENOM1) et
PERSONNE2(NOM, PRENOM2) si lon sait que les personnes nont pas plus de deux
prnoms. Plus gnralement, nous avons montr ci-dessus quune relation de cl K
avec un attribut multivalu A* pouvait tre dcompose en deux relations par limina-

690 BASES DE DONNES : OBJET ET RELATIONNEL

tion de lattribut multivalu et gnration dune table de schma (K, A) donnant les
valeurs lmentaires de A associes aux valeurs de la cl. La rgle de dcomposition
en premire forme normale nest rien dautre que lapplication systmatique de cette
transformation. Si la relation na pas dautre attribut que la cl et lattribut multivalu,
elle est simplement dsimbrique comme pour lexemple de la figure XVII.25.
PERSONNE

NOM

PROFESSION

DUPONT

Ingnieur, Professeur

MARTIN

Gomtre

Une telle relation doit tre dcompose en rptant les noms pour chaque
profession (Opration UNNEST)

Figure XVII.25 : Exemple de relation non en premire forme normale

Soulignons que la premire forme normale est une question de dfinition de domaine :
chaque valeur dun domaine est en effet un atome du point de vue du modle relationnel. Par suite, rien nempche de considrer une date ou une figure gomtrique
comme atomique si les domaines de valeur sont les dates et les figures gomtriques.
Cest une question de point de vue et de niveau de dcomposition.

6.2. DEUXIME FORME NORMALE

La deuxime forme normale permet dassurer llimination de certaines redondances
en garantissant quaucun attribut nest dtermin seulement par une partie de la cl.
Notion XVII.10 : Deuxime forme normale (Second normal form)
Une relation R est en deuxime forme normale si et seulement si :
1. Elle est en premire forme.
2. Tout attribut nappartenant pas une cl ne dpend pas dune partie dune cl.

Le schma typique dune relation qui nest pas en 2e forme normale est reprsent
figure XVII.26. K1 et K2 dsignent deux parties de la cl K. Le problme est que K2
lui seul dtermine Y : K2 Y. Donc Y dpend dune partie de la cl. Comme nous
le verrons plus loin, une telle relation doit tre dcompose en R1(K1,K2,X) et
R2(K2,Y).
Par exemple, considrons la relation :
FOURNISSEUR (NOM, ADRESSE, ARTICLE, PRIX)

Conception des bases de donnes 691

La cl est le couple (NOM, ARTICLE). Il existe les DF :

(NOM, ARTICLE) PRIX et NOM ADRESSE.

Par suite, une partie de la cl (NOM) dtermine un attribut nappartenant pas la cl.
Cette relation nest donc pas en deuxime forme normale. Elle pourra tre dcompose en deux relations :
FOURNISSEUR (NOM, ADRESSE)
PRODUIT (NOM, ARTICLE, PRIX)

qui, quant elles, sont en deuxime forme normale.

K1

K2

Une telle relation doit tre dcompose en R1(K1,K2,X) et R2(K2,Y)

Figure XVII.26 : Schma de relation non en 2e forme normale

6.3. TROISIME FORME NORMALE

La troisime forme normale permet dassurer llimination des redondances dues
aux dpendances transitives.
Notion XVII.11 : Troisime forme normale (Third normal form)
Une relation R est en troisime forme normale si et seulement si :
1. Elle est en deuxime forme.
2. Tout attribut nappartenant pas une cl ne dpend pas dun autre attribut non cl.

Soulignons quune partie de cl nest pas une cl. En consquence, une relation en 3e
forme est automatiquement en 2e : la condition 1 est automatiquement vrifie, mais
figure par souci de claret. Soulignons aussi que si la relation possde plusieurs cls
candidates, la dfinition doit tre vrifie pour chacune delles successivement.
Le schma typique dune relation qui nest pas en 3e forme normale est reprsent
figure XVII.27. K est la cl de R. Le problme est que X lui seul dtermine Z : X
Z. Donc Z dpend dun attribut non cl. Comme nous le verrons plus loin, une telle
relation doit tre dcompose en R1(K1,K2,X) et R2(K2,Y).

692 BASES DE DONNES : OBJET ET RELATIONNEL

Une telle relation doit tre dcompose en R1(K, X, Y) et R2(X, Z)

Figure XVII.27 : Schma de relation non en 3e forme normale

titre dillustration, la relation :

VOITURE (NV, MARQUE, TYPE, PUISSANCE, COULEUR)

nest pas en troisime forme normale. En effet, lattribut non cl TYPE dtermine
MARQUE et aussi PUISSANCE. Cette relation peut tre dcompose en deux relations :
VOITURE (NV, TYPE, COULEUR)
MODELE (TYPE, MARQUE, PUISSANCE).

Si la relation possde une seule cl primaire, il est possible de donner une dfinition
quivalente comme suit. Une relation R est en troisime forme normale si et seulement si :
1)elle est en deuxime forme normale ;
2)tout attribut nappartenant pas la cl ne dpend pas transitivement de la cl.
Par exemple, dans la relation VOITURE, lattribut MARQUE dpend transitivement
de la cl ainsi que lattribut PUISSANCE :
NV TYPE PUISSANCE,
NV TYPE MARQUE.

6.4. PROPRITS DUNE DCOMPOSITION

EN TROISIME FORME NORMALE
Les dpendances fonctionnelles sont des rgles indpendantes du temps que doivent
vrifier les valeurs des attributs. Il est ncessaire quune dcomposition prserve ces
rgles.

Conception des bases de donnes 693

Notion XVII.12 : Dcomposition prservant les dpendances fonctionnelles

(Dependencies preserving decomposition)
Dcomposition {R1, R2 Rn} dune relation R telle que la fermeture transitive des DF de R est la
mme que celle de lunion des DF de {R1, R2 Rn}.

titre dexemple, la dcomposition de la relation VOITURE(NV, MARQUE,

TYPE, PUISSANCE, COULEUR) en R1(NV, TYPE, COULEUR) et
R2(TYPE, MARQUE, PUISSANCE) prserve les DF, alors que la dcomposition
en V1(NV, TYPE), V2(TYPE, PUISSANCE, COULEUR) et V3(TYPE,
MARQUE) ne les prserve pas, comme le montre la figure XVII.28.
La troisime forme normale est importante. En effet, toute relation a au moins une
dcomposition en troisime forme normale telle que :
(a) la dcomposition prserve les DF ;
(b) la dcomposition est sans perte.
Cette dcomposition peut ne pas tre unique. Nous allons dans la suite tudier un
algorithme permettant de gnrer une telle dcomposition.
DF perdue par la dcomposition
V1, V2, V3

NV

TYPE

COULEUR

MARQUE

PUISSANCE

Figure XVII.28 : DF perdue par la dcomposition {V1, V2, V3}

6.5. ALGORITHME DE DCOMPOSITION

EN TROISIME FORME NORMALE
Pour toute relation, y compris la relation universelle, il existe donc au moins une
dcomposition en troisime forme normale prservant les DF et sans perte. Le but

694 BASES DE DONNES : OBJET ET RELATIONNEL

dun algorithme de dcomposition en 3e forme normale est de convertir un schma de

relation qui nest pas en 3e FN en un ensemble de schmas en 3e FN. Le principe
consiste simplement appliquer rcursivement les rgles de dcomposition nonces
ci-dessus, afin de dcomposer jusqu obtenir des relations en 3e FN.
Revenons quelque peu sur ces rgles afin de montrer leur validit. Soit donc une relation de schma R(K1, K2, X, Y) qui nest pas en 2e FN. La figure XVII.29 donne le
graphe de DF associ. Les cercles correspondant aux relations dcomposes
R1(K1,K2, X) et R2(K2,Y) montrent simplement que lunion des DF de R1 et R2 est
bien lensemble des DF : cette dcomposition prserve les DF. Dun autre ct, par
jointure sur K2, on retrouve bien la relation initiale. Donc, la dcomposition est sans
perte. Les deux relations sont bien en 2e FN. Cette rgle de dcomposition a donc
toutes les bonnes proprits.

R1

R2

K1

K2

Figure XVII.29 : Dcomposition dune relation non en 2e forme normale

On vrifie de manire similaire les bonnes proprits de la dcomposition en 3e FN,

comme illustre figure XVII.30.

R1

R2

X
Y

Figure XVII.30 : Dcomposition dune relation non en 3e forme normale

Conception des bases de donnes 695

6.6. ALGORITHME DE SYNTHSE

EN TROISIME FORME NORMALE
Une dcomposition en 3e FN peut tre gnre par un algorithme de synthse ayant
pour entres lensemble des attributs ainsi que les DF. Le principe dun tel algorithme
[Bernstein76] consiste construire tout dabord une couverture minimale F des DF
lmentaires. Ensuite, la couverture F doit tre partitionne en groupes Fi tels que les
DF dans chaque Fi ait le mme ensemble dattributs gauche. Chaque groupe produit
une relation en 3e FN.
Pour produire un groupe, on recherche le plus grand ensemble X dattributs qui dtermine dautres attributs A1, A2 An (avec n 1), et lon extrait la relation (X1, A1, A2
An). Une telle relation de cl X est bien en 3e forme normale car X dtermine tous
les autres attributs et il ne peut exister de dpendances transitives X Ai Aj du fait
que lon est parti dune couverture minimale (sinon, X Aj ne serait pas dans cette
couverture). Les DF X A1, X A2, X An sont alors limines de la couverture
minimale, ainsi que les attributs isols crs (non source ou cible de DF). Lalgorithme
est ensuite appliqu itrativement jusqu ce quil ne reste plus de groupe. Sil reste des
attributs isols, on les sort dans une table qui est bien en 3e FN puisquelle na pas de
DF entre ses attributs. Cet algorithme est schmatis figure XVII.31.
Procdure Synthse({Ai}, {DF}) { // Normalisation par synthse
Trouver une couverture minimale F de {DF} ;
Conserver les seules dpendances lmentaires ;
Tant que il reste des DF Faire { ProduireGroupe() } ;
Editer la relation compose des attributs restants ;
}
// Production dune relation de cl maximale partir de F
Procdure ProduireGroupe {
X = Rechercher(), // rechercher le plus grand ensemble
// dattributs X qui en dtermine dautres ;
A = {Ai | Ai X} ;
Editer la relation (X, A) ; //Gnration de relation en 3e FN
Pour chaque Ai de A Faire { // Rduction de F
Eliminer toute DF incluse dans (X,Ai) ;
Si Ai est isol Alors Eliminer Ai de F ;} ;
} ;

Figure XVII.31 : Algorithme de synthse de relations en 3e forme normale

6.7. FORME NORMALE DE BOYCE-CODD

La 2e forme normale limine les anomalies cres par des dpendances entre parties
de cl et attributs non cl. La 3e forme normale limine les anomalies cres par des

696 BASES DE DONNES : OBJET ET RELATIONNEL

dpendances entre les attributs non cls. Quid des dpendances de parties de cls entre
elles ou dattributs non cl vers une partie de cl ? Eh bien, la 3e FN est insuffisante.
Afin dliminer les redondances cres par des dpendances entre parties de cls et
celles dj limines par la 3e FN, Boyce et Codd ont introduit la forme normale qui
porte leur nom (en abrg BCNF) [Codd74].
Notion XVII.13 : Forme normale de Boyce-Codd (Boyce-Codd normal form)
Une relation est en BCNF si et seulement si les seules dpendances fonctionnelles lmentaires sont
celles dans lesquelles une cl entire dtermine un attribut.

Cette dfinition a le mrite dtre simple : pas de dpendance autre que KA, K tant
la cl et A un attribut non cl. Il a t montr que toute relation a une dcomposition
en BCNF qui est sans perte. Par contre, une dcomposition en BCNF ne prserve en
gnral pas les DF. La figure XVII.32 illustre le cas typique o un attribut non cl
dtermine une partie de cl, et indique le schma de dcomposition associ.

K1

K2

Une telle relation doit tre dcompose en R1(K1, K2, X) et R2(Y, K1)

Figure XVII.32 : Schma de relation en 3e forme normale mais non en BCNF

Considrons par exemple la relation :

LOCALISATION (CRU, PAYS, REGION, QUALITE)

avec les dpendances :

CRU, PAYS REGION
CRU, PAYS QUALITE
REGION PAYS.

Cette relation nest pas en BCNF bien quen 3e forme puisque le cru ne dtermine pas
la rgion (il y a du Chablis en Bourgogne mais aussi en Californie ; notez que la qualit dpend bien du pays !). Une instance, le rseau de DF et la dcomposition souhaitable sont reprsents figure XVII.33. La DF CRU, PAYS REGION est perdue. La
dcomposition est cependant sans perte.

Conception des bases de donnes 697

CRU

PAYS

REGION

QUALITE

Chenas
Julinas
Morgon
Chablis
Brouilly
Chablis

France
France
France
tats-Unis
tats-Unis
France

Beaujolais
Beaujolais
Beaujolais
Californie
Californie
Beaujolais

Excellent
Excellent
Bon
Moyen
Mdiocre
Excellent

PAYS
CRU
REGION

QUALITE
Dcomposition :
CRUS (CRU, PAYS, QUALITE)
REGIONS(REGION, PAYS)

Figure XVII.33 : Exemple de relation non en BCNF et dcomposition

7. QUATRIME ET CINQUIME FORMES

NORMALES
La BCNF nest pas suffisante pour liminer compltement les redondances. Pour aller
au-del, il faut introduire des dpendances plus lches. Nous allons en voir de plusieurs types.

7.1. DPENDANCES MULTIVALUES

Un exemple permet de comprendre la nature des redondances. Considrons la
relation :
ETUDIANT (NE, COURS, SPORT)

698 BASES DE DONNES : OBJET ET RELATIONNEL

NE est le numro dtudiant, COURS les cours suivis et SPORT les sports pratiqus.
Une extension de cette relation est reprsente figure XVII.34. NE, COURS et SPORT
constituent la cl compose. En effet, NE ne dtermine ni cours ni sport car il est
conseill de suivre plusieurs cours et de pratiquer plusieurs sports (cest le cas de
ltudiant 100 ci-dessous).
NE

COURS

SPORT

100

Bases de donnes

Tennis

100

Bases de donnes

Football

100

Rseaux

Tennis

100

Rseaux

Football

200

Rseaux

Vlo

Figure XVII.34 : Relation en troisime forme normale avec redondance

Ses redondances apparaissent clairement dans cette relation. Cependant, en raison de

labsence de dpendances fonctionnelles, elle est jusque-l non dcomposable.
Lexemple prcdent montre linsuffisance de la notion de dpendance fonctionnelle :
elle ne permet pas de saisir lindpendance qui existe entre des attributs comme
COURS suivi et SPORT pratiqu. Pour cela, on gnralise la notion de DF en introduisant celle de dpendance multivalue (DM) [Fagin77, Zaniolo81].
Notion XVII.14 : Dpendance multivalue (Multivalued dependency)
Soit R (A1, A2 An) un schma de relation, et X et Y des sous-ensembles de A1, A2, An. On dit
que X
Y (X multidtermine Y, ou il y a une dpendance multivalue de Y sur X) si, tant donn
des valeurs de X, il y a un ensemble de valeurs de Y associes et cet ensemble est indpendant des
autres attributs Z = R X Y de la relation R.

Une dpendance multivalue caractrise donc une indpendance entre deux

ensembles dattributs (Y et Z) corrls par un mme troisime X. Plus formellement,
on a :
(X
Y) {(x y z) et (x y z) R (x y z) et (x y z) R}
o x, y, z, y, z dsignent des occurrences des attributs X, Y, Z, Y, Z.
Il faut souligner que les DF sont des cas particuliers de DM. En effet :
(X Y) {(x y z) et (x y z) R y = y}.
Donc :
(X Y) {(x y z) et (x y z) R (x y z) et (x y z) R.
Par suite :
(X Y) (X

Y).

Conception des bases de donnes 699

Comme avec les dpendances fonctionnelles, il est possible deffectuer des infrences
partir des dpendances multivalues. Les axiomes dinfrence des DM sont les suivants, en considrant une relation compose dun ensemble dattributs R [Beeri79] :
1. Complmentation : (X
Y) (X
R X Y)
2. Augmentation : (X
Y) et (V W) (XW
YV)
3. Transitivit : (X
Y) et (Y
Z) (X
Z Y)
Des rgles additionnelles sen dduisent, telles que celle dunion :
4. Union : (X
Y) et (Y
Z) (X
YZ)
partir des axiomes prcdents, il est possible dintroduire la notion de dpendance
multivalue lmentaire, ceci afin dliminer les dpendances dduites trivialement
dun ensemble de dpendances de base [Zaniolo81].
Notion XVII.15 : Dpendance multivalue lmentaire
(Elementary multivalued dependency)
Dpendance multivalue X

Y dune relation R telle que :

1. Y nest pas vide et est disjoint de X.

2. R ne contient pas une autre DM du type X

Y telle que X X et Y Y.

Ainsi, une dpendance multivalue lmentaire a, la fois, un ct droit et un ct

gauche minimaux, comme une dpendance fonctionnelle lmentaire.
Afin dillustrer plus en dtail, nous donnerons deux autres exemples de DM. Soit la
relation :
VOL (NV, AVION, PILOTE)

o NV est un numro de vol. On suppose disposer dun ensemble davions et dun

ensemble de pilotes. Tout pilote est conduit piloter tout avion sur nimporte quel vol.
Ainsi, les avions et les pilotes sont indpendants. Do les deux DM lmentaires :
NV
NV

AVION
PILOTE

Soit encore la relation :

PERSONNE (NSS, PRENOM-ENFANT, N VEHICULE)

Il est clair que lon a les DM lmentaires :

NSS
NSS

PRENOM-ENFANT
NVEHICULE

7.2. QUATRIME FORME NORMALE

La quatrime forme normale est une gnralisation de la forme normale de BoyceCodd destine dcomposer les relations ayant des DM lmentaires.

700 BASES DE DONNES : OBJET ET RELATIONNEL

Notion XVII.16 : Quatrime forme normale (Fourth normal form)

Une relation est en quatrime forme normale si et seulement si les seules dpendances multivalues
lmentaires sont celles dans lesquelles une supercl dtermine un attribut.

Rappelons quune supercl est un ensemble dattributs contenant une cl. Donc, une
relation R nest pas en 4e FN si lon peut trouver une dpendance de la forme
X
Y o X ninclut pas une cl de R. Comme une dpendance fonctionnelle est
un cas particulier de dpendance multivalue, il apparat quune relation en quatrime
forme normale est en forme normale de Boyce-Codd et donc en troisime forme normale.
titre dexemple, la relation ETUDIANT (NE, COURS, SPORT) nest pas en quatrime forme normale : la cl est lensemble des attributs et il existe des DM lmentaires entre des attributs participants la cl :
NE
NE

COURS
SPORT.

Il a t montr que toute relation a une dcomposition (pas forcment unique) en quatrime forme normale qui est sans perte [Fagin77]. Par exemple, la relation ETUDIANT peut tre dcompose en deux relations (NE, COURS) et (NE, SPORT) qui
sont bien en quatrime forme normale.

7.3. DPENDANCES DE JOINTURE

La notion de dpendance multivalue a conduit dcomposer les relations en quatrime forme normale. Est-ce suffisant pour liminer les problmes de redondances et
anomalies ? [Nicolas78] et [Fagin79] ont montr que non.
Considrons par exemple la relation BUVCRU reprsente figure XVII.35 ; cette relation modlise des vins bus par des buveurs, dun cru donn et commands un producteur produisant ce cru.
BUVEUR

CRU

PRODUCTEUR

Ronald

Chablis

Georges

Ronald

Chablis

Nicolas

Ronald

Volnay

Nicolas

Claude

Chablis

Nicolas

Figure XVII.35 : Relation en quatrime forme normale avec redondance

Cette relation est bien en quatrime forme normale. En effet, il nexiste pas de dpendance multivalue daprs lextension reprsente ci-dessus :

Conception des bases de donnes 701

BUVEUR
CRU est faux car par exemple le tuple (Ronald Volnay Georges)
nexiste pas.
CRU
PRODUCTEUR est faux car par exemple le tuple (Claude Chablis
Georges) nexiste pas.
PRODUCTEUR
BUVEUR est faux car par exemple le tuple (Claude Volnay
Nicolas) nexiste pas.
Autrement dit, si lon considre les projections R1, R2, R3 de la relation BUVCRU
sur deux attributs (voir figure XVII.36), on constate que lon a :
BUVCRU R1
R2,
BUVCRU R1
R3,
BUVCRU R2
R3.
Cependant, la relation reprsente figure XVII.35 prsente bien des redondances : on
apprend deux fois que Ronald boit du Chablis et que Nicolas produit du Chablis. Elle
nest cependant pas dcomposable en deux relations.
R1

BUVEUR

CRU

Ronald
Ronald
Claude

Chablis
Volnay
Chablis

R2

R2

BUVEUR PRODUCTEUR
Ronald
Ronald
Claude

CRU

PRODUCTEUR

Chablis
Chablis
Volnay

Georges
Nicolas
Nicolas

Georges
Nicolas
Nicolas

Figure XVII.36 : Trois projections de la relation BUVCRU

Lexemple prcdent montre linsuffisance de la notion de dpendance multivalue

pour liminer les redondances. Le problme vient du fait que jusqu prsent, nous
avons essay de dcomposer une relation seulement en deux relations. Ainsi, la notion
de dpendance multivalue capture la possibilit de dcomposer une relation en deux ;
la relation (XYZ) dans laquelle X
Y est en effet dcompose en (XY) et (XZ)
puisque Y et Z sont indpendants par rapport X. Comme nous allons le voir, il existe
des relations non dcomposables en deux mais dcomposables en trois, quatre ou plus
gnralement N relations. Ce phnomne a t dcouvert par [Aho79] et [Nicolas78].
titre dexemple de relation dcomposable en trois relations et non dcomposable en
deux, supposons que la relation BUVCRU de la figure XVII.35 obisse la contrainte
dintgrit assez plausible :

702 BASES DE DONNES : OBJET ET RELATIONNEL

Tout buveur ayant bu un cru et ayant command un producteur produisant ce cru a

aussi command ce cru ce producteur .
Cette contrainte scrit plus formellement :
(b,c) R1 et (b,p) R2 et (c,p) R3 (b,c,p) R.
Dans ce cas, R sera la jointure de R1, R2 et R3 :
R = R1
R2
R3
Cette contrainte est bien vrifie par lextension de la relation BUVCRU reprsente
figure XVII.35 en considrant ses projections R1, R2 et R3 reprsentes
figure XVII.36.
Plus gnralement, [Rissanen78] a introduit la notion de dpendance de jointure
(DJ) afin de dcomposer des relations en plusieurs.
Notion XVII.17 : Dpendance de jointure (Join dependency)
Soit R (A1, A2 An) un schma de relation et R1, R2 Rm des sous-ensembles de {A1, A2 An}.
On dit quil existe une dpendance de jointure *{R1, R2 Rm} si R est la jointure de ses projections
R2(R)
Rm(R).
sur R1, R2 Rm, cest--dire si R = R1(R)

En dautres termes, la dpendance de jointure *{R1, R2 Rm} est valide si R1,

R2Rp est une dcomposition sans perte de R. En consquence, une relation de
schma R satisfait la dpendance de jointure *{R1, R2 Rm} quand la condition suivante est valide pour toute instance r de R :
Si t1 R1(r) t2 R2(r) tm Rm(r), alors t1*t2*..tm R en notant * la jointure naturelle des relations Ri concernes.
Par exemple, la relation de schma BUVCRU(BUVEUR, CRU, PRODUCTEUR)
obit la dpendance de jointure :
*{(BUVEUR,CRU),(BUVEUR,PRODUCTEUR),(CRU, PRODUCTEUR)}

Elle est donc dcomposable en trois relations R1(BUVEUR,CRU), R2(BUVEUR,

PRODUCTEUR) et R3(CRU,PRODUCTEUR) comme reprsente figure XVII.36. Si
(b,c), (b,p) et (c,p) sont respectivement des tuples de R1, R2 et R3, alors (b,c,p) est un
tuple de BUVCRU.
Les dpendances multivalues sont bien sr des cas particuliers de dpendances de jointures. En effet, une relation R (X,Y,Z) vrifiant la dpendance multivalue X
Y
(et donc X
Z) satisfait la dpendance de jointure *{(XY), (XZ)}.

7.4. CINQUIME FORME NORMALE

La forme normale de projection jointure, parfois appele cinquime forme normale,
est une gnralisation de la quatrime partir de la notion de dpendance de jointure.

Conception des bases de donnes 703

Sa dfinition ncessite dtudier les dpendances de jointures comme nous lavons

fait pour les DF ou les DM. Soit une relation R et *{R1, R2Rp} une dpendance de
jointure. Une telle dpendance de jointure est triviale si lune des relations Ri est la
relation R elle-mme.
Il nous est maintenant possible de dfinir la forme normale de projection-jointure,
encore appele 5e forme normale.
Notion XVII.18 : Forme normale de projection-jointure (Project-join normal form)
Une relation R est en forme normale de projection-jointure si et seulement si toute dpendance de
jointure est triviale ou tout Ri est une supercl de R (cest--dire que chaque Ri contient une cl de R).

Lide simple est que si la DJ est implique par les cls, la dcomposition nliminera
pas de redondance et est sans intrt. Si elle contient R, elle ne sert rien puisque R
demeure. Dans les autres cas, il est possible de dcomposer par projection selon les
schmas de la DJ ; lexpression de jointures drives de la JD permet de recomposer
la relation R. Par suite, la dcomposition dune relation non en 5e forme suit les DJ et
est sans perte. Par contre, elle ne prserve en gnral pas les DF, comme la BCNF.
Notons aussi que la 5e forme normale est une gnralisation directe de la BCNF et de
la 4e ; donc une relation en 5e forme est en 4e et bien sr en 3e.
Ainsi la relation BUVCRU nest pas en 5e forme normale puisque la seule cl candidate (BUVEUR, CRU, PRODUCTEUR) nimplique pas la DJ *{(BUVEUR CRU),
(CRU PRODUCTEUR), (BUVEUR PRODUCTEUR)}. Elle doit donc tre dcompose
en ces trois relations afin dviter les anomalies de mise jour.
[Fagin79] a dmontr le rsultat essentiel suivant. Toute relation en 5e forme normale
ne peut plus tre dcompose sans perte dinformations (except par les dcompositions bases sur les cls qui sont sans intrt) si lon ne considre que la dcomposition par projection et la recomposition par jointure. La 5e forme normale est donc un
point final la dcomposition par projection-jointure. Voil pourquoi Fagin a propos
dappeler cette forme forme normale de projection-jointure (JD/NF).
La 5e forme nest cependant pas la forme ultime de dcomposition si lon accepte
aussi des dcompositions horizontales, cest--dire en partitionnant la table en soustables comportant chacune un ensemble de tuples avec tous les attributs. Il est possible dintroduire des dpendances algbriques du style R E(R) o E est une
expression de lalgbre relationnelle avec union, projection et jointure
[Yannakakis80]. Les dpendances dinclusion constituent une forme plus restreinte
de dpendances qui unifient les FD et les JD [Abiteboul95]. Mais tout cela nest pas
dune grande utilit pour concevoir une BD.

704 BASES DE DONNES : OBJET ET RELATIONNEL

8. CONCEPTION DU SCHMA INTERNE

Nous abordons dans cette partie les problmes plus pratiques de passage au niveau
interne, cest--dire dimplmentation du schma logique sur un SGBD particulier.

8.1. LES PARAMTRES PRENDRE EN COMPTE

La conception du schma interne, encore appele conception physique, vise non plus
rsoudre les problmes smantiques, mais les problmes de performances. Lobjectif
est, pour une charge applicative donne, de trouver le meilleur schma physique pour
optimiser les temps daccs et de calcul, plus gnralement le dbit en transactions et
les temps de rponse.
Quels sont les paramtres ncessaires ? Tout dabord, le schma logique de la base
issu des tapes prcdentes est connu. Pour chaque relation, il faut aussi connatre les
tailles en nombre de tuples et le profil moyen dun tuple (attributs et tailles). En plus,
il faut avoir un modle de lapplication. Plus prcisment, pour chaque transaction, il
est souhaitable de connatre :
la frquence, voire ventuellement une distribution de frquence pendant la journe ;
les requtes excutes, avec les types (SELECT, UPDATE, etc.), les critres et un
nombre de fois si la requte est rpte ;
le mode dexcution, cest--dire requte interactive ou compile.
partir de ces paramtres, un modle de lapplication peut tre labor. Il peut
tre analytique ou simul. Mais il faut aussi modliser le SGBD sauf si lon choisit un
modle simul effectivement construit sur le SGBD. Les paramtres intressants
prendre en compte au niveau du SGBD sont les configurations des disques, la taille du
cache, la taille des pages, les temps de lecture et dcriture dune page, les types
dindex, etc. Cest en fait trs complexe.
Le modle analytique conduit une formule de cot paramtre (par exemple la prsence ou non dun index est un paramtre) quil sagit doptimiser. En gnral, le cot
va tre compos du temps dentres-sorties et du temps unit centrale pondr par un
coefficient unificateur. Les formules de loptimiseur de requtes sont intgrer dans
un tel modle. Le problme est gnralement que le nombre de paramtres est trop
grand pour permettre une recherche doptimum.
Le modle simul est plus crdible. Il conduit raliser une base rduite avec des
corps de transactions comprenant essentiellement les requtes. Un gnrateur de transactions doit alors tre ralis pour simuler la charge. Un tel modle permet de faire
des mesures effectives en faisant varier tel ou tel paramtre, par exemple en ajoutant

Conception des bases de donnes 705

ou en supprimant un index. Les modles base doutils gnraux bass sur les files
dattente sont aussi utilisables.
Au-del du modle qui est un problme en soi, nous examinons ci-dessous les paramtres sur lequel ladministrateur systme peut jouer. Ceux-ci sont souvent dpendant
du SGBD.

8.2. DNORMALISATION ET GROUPEMENT DE TABLES

Dun point de vue logique, pour viter anomalies et pertes doprations, nous avons
vu ci-dessus quil tait souhaitable de dcomposer les relations par projection, la
recomposition tant faite par jointure. Dun point de vue performance, ce nest pas
toujours optimal. En effet, la normalisation conduit, si lapplication le ncessite,
recalculer les jointures. Do lide dune tape de dnormalisation possible.
Notion XVII.19 : Dnormalisation (Denormalisation)
Technique consistant implmenter la jointure de deux relations (ou plus) la place des relations
individuelles initiales.

Bien sr, la dnormalisation conduit des redondances et ventuellement des

valeurs nulles qui doivent tre prises en compte par les programmes dapplication.
Soulignons aussi que les jointures intressantes suivent en gnral les contraintes rfrentielles, qui sont les plus frquemment utilises. Quand une dnormalisation est-elle
souhaitable ? Pratiquement, le gain est pour les recherches, la jointure des deux tables
tant remplace par une slection sur la table rsultant de la jointure. La perte affecte
les mises jour qui sappliquent sur la table jointure en plusieurs points, mais aussi
les slections sur les tables individuelles qui doivent maintenant sappliquer sur la
jointure. Seuls un calcul analytique ou une simulation permettent de calculer la diffrence et de conclure.
Une variante plus performante de la dnormalisation est le groupement, permis dans
certains SGBD.
Notion XVII.20 : Groupement (Clustering)
Technique permettant de regrouper dans une mme page ou des pages voisines les tuples de deux
tables (ou plus) selon un critre de jointure.

Cette technique est connue depuis longtemps sous le nom de placement proximit
dans le modle rseau. Elle permet par exemple de placer les lignes de commandes
dans la page de len-tte. Ainsi, la jointure ne ncessite quune entre-sortie par commande. Il ny a cette fois pas de duplication et donc pas de problme introduit en mise
jour. Cest donc une excellente technique qui peut cependant pnaliser les slections
sur lune et lautre des tables.

706 BASES DE DONNES : OBJET ET RELATIONNEL

8.3. PARTITIONNEMMENT VERTICAL ET HORIZONTAL

Le partitionnement vertical consiste diviser la table en deux par projection en
rptant les cls.
Notion XVII.21 : Partitionnement vertical (Vertical partitionning)
Technique consistant implmenter deux projections ou plus dune table sur des schmas R1, R2
en rptant la cl dans chaque Ri pour pouvoir recomposer la table initiale par jointure sur cl.

Cette technique, qui prolonge en quelque sorte la normalisation, permet dloigner

dune relation tous les attributs peu frquemment utiliss : ceux-ci sont reports dans
la deuxime table. La table frquemment slectionne R1 devient plus petite, ce qui
amliore les performances. La technique est donc trs intressante si un groupe
dattributs longs est rarement interrog. L encore, calculs analytiques et simulations
aideront prendre les bonnes dcisions.
Le partitionnement horizontal consiste au contraire diviser la table en sous-tables
de mme schma, chacune conservant une partie des tuples.
Notion XVII.22 : Partitionnement horizontal (Horizontal partitionning)
Technique consistant diviser une table en N sous-tables selon des critres de restriction 1,
2n.

Tout tuple respectant les contraintes dintgrit doit appartenir lune des partitions.
Un exemple typique est la cration de partitions sur le mois pour la table des commandes. Ainsi, douze partitions sont cres, une par mois. Cette technique est particulirement intressante si les requtes indiquent souvent le mois de la commande, donc
en gnral un des i. Elle permet surtout de diviser les grosses tables notamment pour
le chargement et la sauvegarde. De nombreux SGBD limplmentent de manire invisible au dveloppeur dapplication. Le partitionnement horizontal correspond de fait
une dcomposition par union.

8.4. CHOIX DES INDEX

Le choix des index nest pas un problme simple. En effet, les index permettent des
gains impressionnants en interrogation, mais des pertes significatives en mise jour.
De plus, il existe diffrents types dindex, les plus frquents tant les arbres B et les
index bitmap pour lOLAP.
Alors que faire ? Quelques rgles simples sont utiles :
1. Toute cl primaire doit tre indexe par un arbre B ds que la relation dpasse
quelques pages. Cela vite les problmes pour la vrification dintgrit, la

Conception des bases de donnes 707

recherche sur cl, etc. Les SGBD du march automatisent de plus en plus ce type
dindexation.
2. Un attribut sur lequel figure un prdicat conjonctif avec galit sera index :
par un arbre B si le nombre de valeurs possibles dpasse quelques centaines ;
par un index bitmap sinon.
Il ne faut cependant pas abuser de lindexation pour les tables frquemment mises
jour ou avec insertions nombreuses. Dans ce cas, un modle analytique ou une simulation permettront dy voir plus clair. On pourra consulter [Cardenas75,
Schkolnick85] pour de tels modles.

8.5. INTRODUCTION DE VUES CONCRTES

Mentionnons pour finir que lintroduction de vues concrtes pr-calculant les
rponses aux questions frquentes est une technique trs intressante pour loptimisation. Elle est dailleurs de plus en plus utilise dans les environnements OLAP,
comme nous lavons vu au chapitre IX traitant des vues. Bien sr, les rpercussions
des mises jour des relations de base sur la vue concrte peuvent tre difficiles. Une
vue concrte sera donc particulirement intressante lorsque les relations de base sont
peu frquemment mises jour.

9. CONCLUSION
En rsum, concevoir une base de donnes ncessite tout dabord dlaborer un
schma conceptuel. Le modle objet et le langage graphique de modlisation UML
nous semble un bon vhicule pour ce faire. partir de l, des rgles prcises permettent dobtenir un schma logique relationnel. Faut-il ensuite normaliser les schmas
de tables ? Cela peut tre utile en cas de mauvaise isolation des entits. Cependant, la
normalisation est un processus long qui ncessite danalyser les dpendances quon
napplique finalement qu lexception. Trop systmatiquement applique, elle
conduit clater les tables en molcules de quelques attributs. Il apparat alors des
myriades de tables quil faut regrouper. Loptimisation est finalement beaucoup plus
importante pour les performances, mais trs difficile matriser. Cest un mtier de
spcialiste de systme.
La conception reste encore plus un art quune science, surtout avec le modle objet.
En effet, on est peu prs incapable de dire ce quest un bon schma objet. De plus, le
passage dun schma objet un schma logique objet-relationnel reste une tape
mal matrise. Les approches par un modle smantique de plus haut niveau sont trs

708 BASES DE DONNES : OBJET ET RELATIONNEL

intressantes [Bouzeghoub91], mais restent thoriques. Il y a donc toujours de grands

besoins en recherche sur la conception, notamment avec lavnement des bases de
donnes objet-relationnelles. La mode est plutt aujourdhui aux mthodes de conception globale pour les applications objet. Reste quil faut bien gnrer le schma de la
base. Les patterns, bibliothques de cas typiques paramtrables, sont sans doute une
voie davenir [Gamma97].

10. BIBLIOGRAPHIE
[Abiteboul95] Abiteboul S., Hull R., Vianu V., Foundations of Databases, AddisonWesley, 1995.
Ce livre sur les fondements des bases de donnes couvre particulirement bien
la thorie des dpendances fonctionnelles, de jointure et dinclusion, et bien
dautres aspects.
[Aho79] Aho A.V., Beeri C., Ullman J-D., The Theory of Joins in Relational
Databases , ACM Transactions on Database Systems, Vol.4, n 3, p. 297-314,
Sept. 1979.
Cet article tudie la dcomposition dune relation par projection et donne des
algorithmes efficaces pour dterminer si la jointure de relations est sans perte
en prsence de dpendances fonctionnelles et multivalues.
[Armstrong74] Amstrong W.W., Dependency Structures of Database
Relationships , IFIP World Congress, North-Holland Ed., p. 580-583, 1974.
Cet article introduit les fameux axiomes de Armstrong.
[Batini86] Batini C., Lenzerini M., A Methodology for Data Schema Integration in
the Entity-Relationship Model , IEEE Transactions on Software Engineering,
vol. 10, n 6, p.650-664, Nov. 1984.
Les auteurs prsentent une mthodologie pour intgrer les schmas entit-association.
[Beeri79] Beeri C., Bernstein P.A., Computational Problems Related to the Design
of Norma Form Schemas , ACM Transactions on Database Systems, Vol.4,
n 1, Mars 1979.
Cet article dcrit un algorithme linaire pour tester si une dpendance fonctionnelle est dans la fermeture dun ensemble de DF et une implmentation
optimise de lalgorithme de synthse de Bernstein.
[Benci76] Benci E., Concepts for the Design of a Conceptual Schema , IFIP
Conference on Modelling in Database Management Systems, North-Holland
Ed., p. 181-200, 1976.

Conception des bases de donnes 709

Cet article collectif introduit une mthode de type entit-association pour

modliser des donnes au niveau conceptuel. Cest un des articles fondateurs
de MERISE.
[Bernstein76] Bernstein P.A., Synthesizing Third Normal Form Relations from
Functional Dependencies , ACM Transactions on Database Systems, Vol.1,
n 4, p. 277-298, 1976.
Lauteur prsente lalgorithme de synthse de relations en 3e FN et ses les fondements.
[Bouzeghoub85] Bouzeghoub M., Gardarin G., Mtais E., SECSI: An Expert
System for Database Design , 11 th Very Large Data Base International
Conference, Morgan Kaufman Pub., Stockolm, Sude, 1985.
Cet article dcrit le systme SECSI bas sur un modle smantique appel
MORSE. MORSE supporte lagrgation, la gnralisation, lassociation et linstanciation. SECSI est construit selon une architecture systme expert. Cest un
outil daide la conception de bases de donnes relationnelles qui transforme le
modle smantique en relations normalises. Pour passer au relationnel, SECSI
applique les rgles de transformation du modle objet vues ci-dessus.
[Bouzeghoub91] Bouzeghoub M., Mtais E., Semantic Modeling of Object Oriented
Databases , Proc. of the 17th Intl. Conf. on Very large Data Bases, Morgan
Kaufman Ed., p. 3-14, Sept. 1991.
Cet article propose une mthode de conception de BD objet base sur un
rseau smantique. La mthode a t implmente dans un outil CASE.
[Bouzeghoub97] Bouzeghoub M., Gardarin G., Valduriez P., Les Objets, ditions
Eyrolles, Paris, 1997.
Ce livre couvre tous les aspects de lobjet et dtaille les principales mthodologies de conception objet.
[Chen76] Chen P.P., The Entity-Relationship Model Toward a Unified View of
Data , ACM Transactions on Database Systems, Vol.1, n 1, p. 9-36,
Mars1976.
Le fameux article introduisant le modle E/R.
[Codd71] Codd E.F., Normalized Database structure : A Brief Tutorial , ACM SIGFIDET Workshop on Data Description, Access and Control, p. 1-17, Nov.
1971.
Un tat de lart sur les trois premires formes normales.
[Codd72] Codd E.F., Further Normalization of the Data Base Relational Model , in
Data Base Systems, R. Rusin ed., Prentice-Hall, 1972.
Cet article introduit la BCNF. Lintrt de cette forme normale fut plus tard
contest par Bernstein.

710 BASES DE DONNES : OBJET ET RELATIONNEL

[Codd74] Codd E.F., Recent Investigations in Relational Database Systems , IFIP

World Congress, North Holland Ed., p. 1017-1021, 1974.
Un autre tutorial sur le relationnel et les formes normales.
[DeAntonellis83] De Antonellis V., Demo B., Requirements Collection and
analysis in Methodology and Tools for Database Design, S. Ceri ED., NorthHolland, 1983.
Cet article fait le tour de mthodes en matire de capture des besoins des utilisateurs.
[Delobel73] Delobel C., Casey R.G., Decomposition of a Data Base and the Theory
of Boolean Switching Functions , IBM Journal of research and Devlopment,
vol. 17, n 5, p. 374-386, 1973.
Cet article tudie les dpendances fonctionnelles comme des fonctions boolennes. Il introduit en particulier la notion de couverture minimale.
[Fagin77] Fagin R., Multivalued Dependencies and a New Normal Form for
Relational Databases , ACM Transactions on Database Systems, Vol.2, n 3,
p. 262-278, Sept. 1977.
Cet article introduit les dpendances multivalues et la 4e forme normale.
[Fagin79] Fagin R., Normal Forms and Relational Database Operators , Proc.
ACM SIGMOD Intl. Conf. on Management of Data, Boston, p.153-160, Juin
1979.
Cet article introduit les dpendances de jointures et la forme normale par projection jointure.
[Fagin81] Fagin R., A Normal Form for Relational Databases Based on Domains
and Keys , ACM Transactions on Database Systems, vol. 6, n 3, p. 387-415,
Sept. 1981.
Cet article introduit une nouvelle forme normale base sur des dfinitions de
domaines, les dclarations de cls et des contraintes gnralises exprimes
par des rgles logiques. Cette forme gnralise les prcdentes.
[Gamma97] Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns,
Addisson-Wesley, Professional Computing Series, 1997.
Ce livre dfinit ce quest un pattern objet pour la conception et prsente plus
dune vingtaine de patterns utiles.
[Hammer93] Hammer M., Champy J., Le Reengineering, Dunod, 1993.
Ce livre dtaille les techniques de reengineering, en particulier le BPR qui permet de modliser une socit depuis le client jusquau processus de fabrication
avec des diagrammes de flux dinformation.
[Kettani98] Kettani N., Mignet D., Par P., Rosenthal-Sabroux C., De Merise UML,
d. Eyrolles, Paris, 998

Conception des bases de donnes 711

Ce livre prsente UML, le langage de modlisation universel, le compare avec

MERISE et propose une dmarche de transition.
[Mtais97] Mtais E., Kedad Z., Comyn-Wattiau I., Bouzeghoub M., Using
Linguistic Knowledge in View Integration : Towards a Third Generation of
Tools , Data and Knowledge Engineering, Nort-Holland, 1997.
Cette article propose une mthodologie dintgration de vues fonde sur des
connaissances linguistiques. Un outil dintgration pouvant utiliser une ontologie en est driv.
[Muller98] Muller P.A., Modlisation Objet avec UML, d. Eyrolles, Paris, 1998.
Ce livre prsente lobjet et le langage de modlisation associ UML. Il propose
quelques exemples de modles.
[Navathe84] Navathe S., El-Masri R., Sahidar T., Relationship Merging in Schema
Integration , Proc. 10 th Intl. Conf. on Very Large Data Bases, Morgan
Kaufman Ed., p. 78-90, Florence, Aot 1984.
Cet article propose des mthodes dintgration de schmas, notamment de
fusion dassociations dans un modle E/R.
[Nicolas78] Nicolas J-M., Mutual Dependencies and Some Reults on undecomposable relations , Proc. 5th Intl. Conf. on Very Large Data Bases, IEEE Ed.,
p. 360-367, Berlin, 1978.
Cet article propose des dpendances mutuelles intermdiaires entre les dpendances multivalues et de jointure. Il montre que des relations non dcomposables en 2 peuvent ltre en 3.
[Rational98] Rational Soft., UML 1.1, Documentation du langage UML,
http://www.rational.com/uml/.
La documentation en HTML et PDF de UML.
[Rissanen73] Rissanen J., Delobel C., Decomposition of Files A Basis for Data
Storage and Retrieval , IBM Research Report RJ 1220, San Jos, Ca., Mai
1973.
Quelques-uns des premiers algorithmes de dcomposition en 3e forme normale.
[Rissanen78] Rissanen J., Theory of Relations for Databases A Tutorial Survey ,
7th Symposium on Math. Foundations of Computer Science, Springer Verlag
ED., LCNS n 64, p. 537-551, 1978.
Un tutorial sur la dcomposition des relations, de la 1e la 4e forme normale.
[Tardieu83] Tardieu H., Rochefeld A., Colletti R., La Mthode Merise, d.
dOrganisations, 1983.
Le livre de base sur la mthode MERISE.

712 BASES DE DONNES : OBJET ET RELATIONNEL

[Ullman88] Ullman J.D., Principles of database and Knowledge-base Systems, vol. I,

Computer Science Press, Rockville, MD, 1988.
Le livre de Ullman couvre particulirement bien la thorie de la dcomposition
et les dpendances gnralises par des tableaux.
[WonKim95] Won Kim, Choi I., Gala S., Scheevel M., On Resolving Schematic
Heterogeneity in Multidatabase systems , in Modern Database Systems, Won
Kim ED., ACM Press, 1995.
Cet article est un tutorial des techniques de rsolution conflits entre schmas
intgrer. Il discute particulirement de lintgration de schmas objet et relationnels dans un contexte de BD rparties fdres.
[Yannakakis80] Yannakakis M., Papadimitriou C.H., Algebraic dependencies ,
Foundations of Computer Science Conference, IEEE Ed., p. 328-332, 1980.
Cet article introduit les dpendances algbriques qui gnralisent les dpendances de jointures.
[Zaniolo81] Zaniolo C., Melkanoff M.A., On the design of relational Database
Schemata , ACM Transactions on Database Systems,Vol.6, n 1, p. 1-47, 1981.
Cet article introduit la 4e forme normale et des algorithmes de normalisation
bass sur des hypergraphes.

Chapitre XVIII

CONCLUSION ET PERSPECTIVES

1. INTRODUCTION
Trois gnrations de systmes de bases de donnes ont dj vu le jour. La premire
gnration des annes 70 correspondait aux modles hirarchique et rseau. Elle tait
reprsente par des produits tels TOTAL, IDS II, IMS et Socrate. La seconde gnration des annes 80 tait base sur le modle relationnel et fut conduite par les produits
Oracle, DB2, Ingres, Informix et Sybase. La 3e gnration des annes 90 a vu lintgration de lobjet aux systmes de 2e gnration. Bien que des systmes purs objets
tels O2 ou Object Store aient montr le chemin, lindustrie a procd par extension, si
bien que dun point de vue industriel Oracle, DB2, Informix et SQL Server restent les
produits phares maintenant de 3e gnration.
Les principes des systmes de bases de donnes sont souvent venus de la recherche au
cours de ces trente dernires annes. Lenjeu aujourdhui est le dveloppement de la
gnration de SGBD de lan 2000. Celle-ci devrait voir lintgration efficace du dcisionnel aux systmes transactionnels, le support transparent de lInternet et bien sr la
possibilit de recherche par le contenu des objets multimdias sur le Web vu comme
une grande base de donnes. Tous ces travaux sont dj bien engags dans les laboratoires de recherche et chez les constructeurs de SGBD, notamment aux USA. Nous
rsumons ci-dessous quelques aspects des recherches en cours qui nous paraissent
essentiels pour le futur.

714 BASES DE DONNES : OBJET ET RELATIONNEL

2. LES BD ET LE DCISIONNEL
La dcennie 90 a vu le dveloppement des entrepts de donnes (Datawarehouse). Un
entrept de donnes est un ensemble de donnes historises variant dans le temps,
organis par sujets, agrg dans une base de donnes unique, gr dans un environnement de stockage particulier, aidant la prise de dcision dans lentreprise. Trois
fonctions essentielles sont prises en compte par ces nouveaux systmes dcisionnels :
la collecte de donnes partir de bases existantes et le chargement de lentrept, la
gestion et lorganisation des donnes dans lentrept, lanalyse de donnes pour la
prise de dcision en interaction avec les analystes.
La figure XVIII.1 illustre les composants dun entrept de donnes. Le moniteuradapteur est charg de la prise en compte des mises jour des sources de donnes
locales, de la prparation de tables diffrentielles (les deltas) pour envois lentrept
et du transfert des deltas priodiquement vers le mdiateur. Ce dernier assure la fusion
des sources et la mise en forme des donnes pour la base de lentrept. Autour du
datawarehouse, les outils OLAP (On Line Analysis Processing) permettent lanalyse
des donnes historises. Les outils de data mining permettent lextraction de rgles et
de modles partir des donnes.
Prsentation

Composant
dcisionnel

Composant
dcisionnel

Datawarehouse
Mining

Analyse

BD
Entrept
Mdiateur

Transformation

Moniteur/Adaptateur

Moniteur/Adaptateur
Source

Moniteur/Adaptateur

BD Source

Donnes
externes

BD Source

Donnes
oprationnelles

BD lgataires

Figure XVIII.1 : Architecture dun entrept de donnes

Nouvelles perspectives 715

2.1. LANALYSE INTERACTIVE

MULTIDIMENSIONNELLE (OLAP)
Le dveloppement de lanalyse interactive de donnes (OLAP) a t bas sur lutilisation de cubes multidimensionnels [Gray96]. Un cube permet la visualisation et lanalyse d une mesure selon trois axes. Par exemple, un chiffre daffaire sera reprsent
dans un espace 3-D, en fonction du temps, des produits vendus et de la gographie. Ce
cube de donnes (datacube) peut tre manipul par des oprations bases sur une
algbre des cubes de donnes compose doprateurs de tranches, extensions et agrgats (slice, dice, rollup, drilldown).
Les problmes de performance dans le cadre de larges bases de donnes historises sont
nombreux : Que concrtiser dans l entrept ? Comment grer des vues redondantes pour
faciliter le calcul des cubes ? Comment passer du relationnel au multidimensionnel ? Et
plus gnralement comment concevoir la base de lentrept ? Comment choisir les rsums stocks, les vues concrtises, maintenir les mta-donnes [Mumick97]?

2.2. LA FOUILLE DE DONNES (DATA MINING)

Au-del de lanalyse interactive multidimensionnelle, les techniques de fouille de
donnes (Data mining) se sont rpandues. Il sagit dun ensemble de techniques
dexploration de larges bases de donnes afin den tirer les liens smantiques significatifs et plus gnralement des rgles et des modles pour la comprhension et laide
la dcision. Les domaines dapplications sont nombreux, par exemple lanalyse de
risque, le marketing direct, la grande distribution, la gestion de stocks, la maintenance, le contrle de qualit, le mdical, lanalyse financire. Lapproche consiste
souvent induire des rgles avec des coefficients de vraisemblance partir de large
ensemble de donnes. Les techniques de base sont issues de l IA et de lanalyse de
donnes (analyse statistique, modles fonctionnels, rseaux de neurones, recherche de
rgles associatives, classification, segmentation, etc.). La problmatique BD est le
passage l chelle, cest--dire tre capable de traiter quelques giga octets de faits !
Par exemple des indexes spcialiss (bitmap) et des chantillonnages contrls ont t
proposs. Les techniques de dcouvertes de rgles associatives ont t particulirement dveloppes [voir par exemple Agrawal93, Gardarin98]

3. BD ET WEB
Le Web sest dvelopp comme un hypertexte sur le rseau Internet, pour permettre
facilement laccs des fichiers chans. Rapidement, le besoin de couplage avec les

716 BASES DE DONNES : OBJET ET RELATIONNEL

bases de donnes est apparu. Pourquoi coupler ? Trois raisons au moins motivent ce
besoin : lintroduction du client-serveur prsentation universelle (architectures 3tiers), la gnration de sites Web dynamiques composs partir de templates Html et
de donnes extraites de bases, et le commerce lectronique, qui ncessite la gestion de
catalogues et de transactions en bases de donnes.
Il existe dj de nombreuses solutions industrielles, plus ou moins issues de la
recherche, telles Oracle Web, Web SQL de Sybase, LiveWire de Netscape, Visual
Interdev de Microsoft, O2 Web, etc. Ces outils ralisent une intgration faible de deux
modles de donnes (le relationnel-objet et le modle semi-structur abstrait de Html).
Ils sont insuffisants car ils ne permettent gure la transcription automatique de rsultats de requtes en Html et vice-versa.
De nombreux projets de recherche (par exemple, Tsimmis Stanford [Abiteboul97],
Strudel ATT [Fernandez97], MiroWeb au PriSM en collaboration avec Osis et
lInria) tendent permettre le stockage direct dhypermdia dans la base. XML parat
le standard adapt pour les bases de donnes semi-structures. Les principaux projets
proposent des modles de reprsentation de documents XML et des langages dinterrogation associs. Les bases de donnes semi-structures [Abiteboul96, Buneman97]
modlisent les donnes par un graphe tiquet, chaque nud feuille pouvant correspondre un objet externe, structur ou non. Les tiquettes correspondent aux tags
XML. La figure XVIII.2 illustre un document semi-structur reprsent sous la forme
dun graphe et en XML.
Lutcia

RACINE
NOM
HOTEL.1

TEL

12345678

FAX

ADRESSE
HOTEL.2

98765432
Rivoli
RUE
VILLE

NOM

TEL

Paris

Crillon
13578642

<RACINE>
<HOTEL>
<NOM> Lutcia </NOM>
<TEL> 12345678 </TEL>
<FAX> 98765432 </FAX>
<ADRESSE>
<RUE> Rivoli </RUE>
<VILLE> Paris </VILLE>
</ADRESSE>
</HOTEL>
<HOTEL>
<NOM> Crillon </NOM>
<TEL> 13578642 </TEL>
</HOTEL>
</RACINE>

Figure XVIII.2 : Exemple de document semi-structur

Le semi-structur parat bien adapt au Web. Il permet en effet la prise en compte de

documents HTML/XML et facilite linterrogation et la recomposition dynamique de
partie de documents multimdias. Il autorise aussi la navigation intelligente dans une
base de documents. Un document distribu est reprsent par un rseau smantique
dobjets lis. Les liens correspondent des arcs de composition ou dassociation. La

Nouvelles perspectives 717

grammaire des documents (DTD) peut tre maintenue comme une nouvelle sorte de
contrainte dintgrit. La question dintgrer le semi-structur aux SGBD existants
reste pose. Elle ncessite en particulier la capacit dcouvrir des structures rptitives dans les documents, afin de les reprsenter sous forme dextensions de types.
Les langages SQL ou OQL doivent aussi tre tendus pour manipuler les graphes
dobjets semi-structurs, par exemple avec des parcours de chemins et des expressions
rgulires [Abiteboul97, Arocena98, Consens93, Fernandez97, Konopnicki95,
Mendelzon96].
La ralisation dadaptateurs capables de gnrer une vue semi-structure de sources
de donnes structures ou non est aussi un problme dactualit. Il faut non seulement
comprendre la smantique des sources afin de dcouvrir un peu de structure mais
aussi assurer le passage du structur au semi-structur. Des vues partielles de sources
sous forme de graphes tiquetes doivent tre gnres sur demande partir de
requtes.
Loptimisation de requtes mixant des donnes structures et semi-structures pose
aussi des problmes nouveaux. Il faudrait pouvoir disposer dun modle de cot pour
donnes semi-structures. La gestion de documents distribus (sur Intranet ou
Internet) ncessite aussi des techniques doptimisation originale pouvant allier les
approches push et pull.

4. BD MULTIMDIA
Le multimdia est la mode [Subrahmanian96]. Il est reconnu quune BD multimdia
doit possder cinq caractristiques :
1. grer des types de donnes multimdias incluant texte libre, gomtrie, image, son,
vido ;
2. offrir les fonctionnalits des bases de donnes, cest--dire lexistence dun langage
dinterrogation non procdural permettant les recherches par le contenu, la persistance, la concurrence et la fiabilit ;
3. assurer la gestion de larges volumes de donnes, pouvant atteindre les pta-bases
(10**15) ;
4. supporter des structures de stockage efficaces comme les Quadtree, les Rtree et
leurs variantes, pour permettre la recherche rapide par le contenu ;
5. tre capable de rcuprer des informations partir de sources htrognes.
Linterrogation dobjets multimdias passe par la recherche classique dans une BD
structure partir dattributs dcrivant les objets (exact-match retrieval), mais surtout
par la recherche base sur le contenu des objets. Une requte typique est la recherche

718 BASES DE DONNES : OBJET ET RELATIONNEL

des k objets les plus similaires un objet donn. L, il ny a pas de garantie sur la correction et la prcision des rsultats. On rcupre un ensemble de rsultats classs par
ordre de pertinence et interrogeable nouveau (raffinement). Dans cet esprit, une
extension de SQL3 avec des types de donnes abstraits spcifiques au multimdia est
en cours de conception par un sous-groupe de lISO : SQL multimdia (SQL/MM). Il
sagit dun projet international de standardisation dont lobjectif est de dvelopper une
librairie de types SQL pour les applications multimdias. SQL/MM est compos de
diverses parties amenes voluer : Full text, Graphic still, Animation, Image still,
Full motion video, Audio, Spatial 2D et 3D, Music. Tous ces types de donnes
devraient tre standardiss, en conjonction avec dautres efforts (MPEG 7 par
exemple).
Les thmes de recherche lis au multimdia sont nombreux et sortent souvent du strict
domaine des bases de donnes. Il sagit en particulier de lindexation automatique
[Salton88], de lextraction de caractristiques (features), de lvaluation de distances
combines entre objets, de la gestion de proximit smantique, du dveloppement de
structures de stockage efficaces. Loptimisation de requtes, les modles de cots, la
formulation et lvaluation de requtes mixtes, lintgration aux SGBD existants, la
distribution et la recherche sur Internet/Intranet devraient aussi contribuer la constitution de muses virtuels interrogeables par le contenu sur les grands rseaux.

5. CONCLUSION
Les bases de donnes ont connu une volution douce vers lobjet, le standard tant
aujourdhui le relationnel-objet et SQL3. Les domaines les plus actifs sont le dcisionnel, lintgration avec le Web et le multimdia. Nous dveloppons ces thmes
dans un ouvrage complmentaire. Les bases de donnes mobiles ne sont pas non plus
ngliger et la conception, notamment dentrept de donnes et de BD actives, restent des problmes ouverts. Il ne faut pas non plus ngliger les thmes de recherche
traditionnels o il y a encore beaucoup faire (mthodes daccs, concurrence,
rparti, intgrit et vues, paralllisme).
Un sondage effectu rcemment auprs de 20 chercheurs reconnus (comit de programme de CIKM) sur leurs domaines dintrt a donn les rsultats indiqus
figure XVIII.3. La note est un poids entre 0 et 20 (intrt ou non).
Si lon analyse les thmes des articles des derniers VLDB et SIGMOD, on obtient des
rsultats sensiblement diffrents comme indiqus figure XVIII.4. Tout ceci montre
la fois la multiplicit, la diversit et louverture de la recherche en bases de donnes.
Les enjeux conomiques sont trs grands, ce qui explique la croissance du nombre de
chercheurs (400 articles soumis au dernier VLDB, 220 CIKM).

Nouvelles perspectives 719

Semi-structured and Web Database

20

Heterogeneous and Distributed System

16

Query Languages and Query Processing

16

Application

15

DataWarehousing and Mining

14

Multimedia Databases

11

Database Design

10

Active & Rule Databases

Object Storage Methods

User and Application Interfaces

Imprecise and Uncertain Information

Parallel database systems

Transaction and Reliability

Tuning, Benchmarking and Performance

Privacy and Security Issues

Figure XVIII.3 : Sondage dintrt auprs de chercheurs

Multimedia Databases

19

DataWarehousing and Mining

18

Query Languages and Query Processing

Semi-structured and Web DB

Heterogeneous an Distributed Systems

Object Storage Methods

Transaction and Reliability

Active & Rule Databases

Tuning, Benchmarking and Performance

Application

Database Design

User and Application Interfaces

Parallel database systems

Imprecise and Uncertain Information

Privacy and Security Issues

Figure XVIII.4 : Analyse des thmes des articles des derniers SIGMOD et VLDB.

Pour terminer, nous voudrions souligner la vertu des prototypes et des applications en
bases de donnes. La ralisation de systmes plus ou moins exploratoires (Socrate,

720 BASES DE DONNES : OBJET ET RELATIONNEL

Syntex, Sabre, O2) a permis par le pass de constituer des quipes masse critique de
pointe. Elle permet aussi dacqurir des connaissances, de les et maintenir et de le
passer de nouveaux chercheurs au sein dun systme. Il ne faudrait pas que la rduction et la dispersion des crdits conduisent abandonner les grands projets au profit
de publications souvent secondaires.
La ralisation dapplications laide de prototypes avancs permet de cerner les vritables besoins et de dcouvrir des sujets neufs. De grandes expriences couples au
rseau (Intranet ou Internet) sont dj en cours par exemple au Muse du Louvre et
Bibliothque Nationale. Une meilleure participation de la recherche dans ces projets
est souhaitable.

6. BIBLIOGRAPHIE
[Abiteboul97] Abiteboul S., Querying semi-structured data , Proc. Of the
International Conference on Database Theory (ICDT), Jan. 1997.
Une mise en perspective thorique des bases de donnes semi-structures.
[Abiteboul97] Abiteboul S., Quass D., McHugh J., Widom J., Weiner J., The Lorel
Query Language for Semi-structured Data , Journal of Digital Libraries,
vol. 1, n 1, p. 68-88, April 1997.
Cet article prsente le langage LOREL, extension de OQL pour les donnes
semi-structures.
[Agrawal93] Agrawal R., Imielinski T., Swami A. N., Mining Association Rules
between Sets of Items in Large Databases , Proc. of the 1993 ACM SIGMOD
International Conference on Management of Data, Washington, D.C., 1993 ,
p. 207-216.
Le premier article sur les rgles associatives. Il propose la mthode Apriori
pour extraire les rgles associatives de grandes bases de donnes.
[Arocena98] Arocena G., Mendelzon A., WebOQL : Restructuring documents, databases and Webs , in Proc. IEE ICDE 98, Orlando, Florida, Feb. 1998.
Cet article propose un langage dinterrogation pour le Web construit partir
dOQL.
[Buneman97] Buneman P., Semi-structured data , Proc. ACM PODS97, Tucson,
Arizona, USA, p. 117-121, 1997.
Cet article prsente un tutoriel sur les donnes semi-structures. En particulier
le langage UnQL et les premires techniques doptimisation, en particulier
pour les expressions rgulires, sont dcrits.

Nouvelles perspectives 721

[Consens93] Consens M., Mendelzon A., Hy+ : A hygraph-based query and

Vizualisation System , SIGMOD Record, vol. 22, n 2, p. 511-516, 1993.
Un des premiers langages dinterrogation pour hypertexte.
[Gardarin98] Gardarin G., Pucheral P., Wu F., Bitmap Based Algorithms For Mining
Association Rules , rapport PriSM, Proc. BDA98, Tunis, octobre 1998.
Un algorithme de dcouverte de rgles associatives bas sur des index spcialiss, de type bitmap.
[Gray96] Gray J., Bosworth A., Layman A., Pirahesh H., Data Cube : A relational
aggregation operator generalizing group-by, cross-tab, and sub-total , Proc. of
the 12th IEEE Data Engineering Conf., p. 152-159, New-Orleans, Feb. 1996.
Un des premiers articles formalisant le datacube et lintroduisant comme une
construction en SQL.
[Konopnicki95] Konopnicki D., Shmueli O., W3QS : A Query System for the
World Wide Web , Proc. Of the 21st VLDB, Zurich, Switzerland, 1995.
Un autre langage dinterrogation pour le Web.
[Mendelzon96] Mendelzon, Mihaila G., Milo T., Querying the World-Wide Web ,
Proc. Of 1st Int. Conf. On Parallel and Distributed Information Systems, p. 8091, Dec. 1996.
Une formalisation de langages dinterrogation pour le Web.
[Mumick97] Mumick S.I., Quass D., Mumick B.S., Maintenance of Data Cubes and
Summary Tables in a Warehouse , in Proc. of ACM SIGMOD97, Sigmod
Record n 26, vol. 26, n 2, p. 100-111, 1997.
Cet article propose une mthode pour maintenir des vues avec agrgats dans
un entrept de donnes. Les mises jour sont envoyes priodiquement sous
forme de tables diffrentielles ou deltas. Tout dabord, un algorithme efficace
de propagation des mises jour sur une vue est propose. Puis, il est montr
comment un ensemble de vues support de cubes de donnes peut tre maintenu
efficacement.
[Salton88] Salton G., Buckley C., Term-weighting approaches in automatic text
retrieval , Information Processing & Management, vol. 24, p. 513-523, 1988.
Cet article prsente une mthode base sur des matrices de frquence de
termes pour interroger les bases de donnes textuelles.
[Subrahmanian96] Subrahmanian V.S., Jajodia S. editors, Multimedia Database
Systems, Springer-Verlag, 323 pages, Berlin, 1996.
Cet excellent livre sur le multimdia donne une vue densemble des techniques
proposes pour les BD images, textes, vido et audio. Il fait aussi un tour des
techniques de stockage et de publications de documents multimdia.

EXERCICES
Prpars en collaboration avec
Yann Vimont
Laboratoire PRiSM, UVSQ

Ces textes reprsentent un ensemble de sujets de partiels et dexamens crits par

Georges Gardarin et Yann Vimont soumis aux tudiants Paris VI puis Versailles
entre 1980 et 2000. Nous nous excusons auprs de ces nombreux tudiants (ils sont
aujourdhui pour la plupart ingnieurs dans un domaine porteur) pour la difficult et
parfois le manque de clart de certains de ces textes, mais les bases de donnes, ce
nest pas si facile...
Des versions de ces textes ont souvent t relues par des collgues que nous tenons ici
remercier, dont M. Bouzeghoub, M. Cheminaud, B. Finance, R. Gomez, M. Jouve,
J. Madelaine, E. Mtais, I. Paumelle, P. Pucheral, E. Simon, P. Testemale, J-M.
Thvenin, P. Valduriez et K. Zeitouni.
Ces sujets ont parfois t repris comme texte de Travaux Dirigs (TD) et dvelopps
par ailleurs. Des corrigs de quelques-uns de ces exercices tendus et modifis pourront tre trouvs dans la srie douvrages Les Bases de Donnes en Questions aux ditions Herms, par Mokrane Bouzeghoub, Mireille Jouve et Philippe Pucheral.
Cependant, les annales qui suivent ont t adaptes et modernises pour mieux correspondre aux chapitres qui prcdent.

724 BASES DE DONNES : OBJET ET RELATIONNEL

1. DISQUES MAGNTIQUES (chapitres I et III)

Le paralllisme entre un traitement par lunit centrale et une entre-sortie (E/S)
disque permet la prise en compte de nouvelles requtes pendant lexcution dune
requte plus ancienne. Ainsi, devant chaque unit dchange, le systme est amen
grer des files dattente de requtes. Les requtes en attente peuvent tre planifies
afin de minimiser les temps dE/S disques. Nous considrons une unit de disques
inamovibles tte mobile des plus courantes.
Soit une file dattente compose des cinq instructions de lecture suivantes, arrives
dans cet ordre :
1. Piste 20 secteurs 11 14
2. Piste 30 secteurs 41 42
3. Piste 40 secteurs 40 43
4. Piste 30 secteurs 05 08
5. Piste 53 secteurs 03 07.

Question 1
Rappelez le fonctionnement dune E/S disque et calculez le temps ncessaire en fonction de la vitesse de rotation et du temps de dplacement de bras unitaire. Fixez les
paramtres des valeurs correspondant aux technologies courantes.

Question 2
Quel est le temps ncessaire pour excuter les requtes en attente suivant leur ordre
darrive (stratgie FIFO) ?

Question 3
Dterminez les quatre meilleures permutations possibles des requtes minimisant le
temps dE/S disques. Parmi ces quatre squences, quelle est la meilleure ? Pourquoi ?

Question 4
Donnez le principe dun algorithme permettant de trouver la squence optimale. Quel
doit tre son temps de rponse maximal pour quil puisse tre utilis ?

Question 5
Calculez le temps ncessaire pour excuter les cinq instructions dE/S en attente en choisissant chaque fois dexcuter la requte la plus proche des ttes de lecture-criture.

Question 6
Lutilisation de disques RAID permet dacclrer les E/S disques. Discutez des diffrents types de RAID et de leur intrt pour acclrer les cinq requtes.

Exercices 725

2. MTHODES DE HACHAGE (chapitre III)

On considre un fichier hach de P paquets contenant N articles au total, dcrivant des
produits selon le format (Numro, Nom, Type, Prix, Fournisseur, Quantit). Les
articles sont composs de 80 octets en moyenne.

Question 1
Discutez le choix de la taille du paquet.
Proposez quelques fonctions de hachage afin de dterminer le numro de paquet
partir du numro de produit. Discutez de lintrt de ces fonctions selon le mcanisme
dattribution des numros de produits.

Question 2
Lorsquun paquet est plein, un produit devant tre insr dans ce paquet est crit en
dbordement. Proposez diffrentes solutions pour la gestion des dbordements. Pour
chacune delles, calculez le nombre dentres-sorties moyen ncessaires pour crire
un nouvel article et lire un article existant.

Question 3
On utilise le hachage extensible. Rappelez lalgorithme dcriture dun nouvel article
et de lecture dun article. Calculez le nombre dentres-sorties ncessaires pour crire
un nouvel article et lire un article existant.

Question 4
Mme question avec le hachage linaire.

3. MTHODES DINDEXATION (chapitre III)

Les mthodes daccs indexes des systmes actuels sont toutes bases sur les arbres
B et B+. Lobjectif de cet exercice est dtudier plus en dtail ces mthodes.

Question 1
Rappelez la dfinition dun arbre B et dun arbre B+. Illustrez ces dfinitions en
construisant un arbre B et un arbre B+ pour stocker lalphabet dans des arbres dordre
2. Quel est lintrt dun arbre B+ par rapport un arbre B ?

Question 2
Calculez le nombre de comparaisons de cls ncessaires la recherche dune lettre
dans un arbre B et B+ dordre 2. Ce nombre est-il diffrent pour un arbre dordre 3 ?

726 BASES DE DONNES : OBJET ET RELATIONNEL

Gnralisez les rsultats un arbre dordre m contenant n cls.

Question 3
Il est possible de comprimer les cls dans un arbre B ou B+ en enregistrant pour
chaque cl seulement la diffrence par rapport la prcdente. Prciser alors le format
de chaque entre dans larbre B. Donnez les algorithmes de recherche et dinsertion
dune cl dans un arbre B ou B+ en prenant en compte la compression.

Question 4
VSAM implmente les arbres B+ en essayant de les calquer la structure des disques.
Discutez de lintrt de cette approche et de ses inconvnients. Calculez le nombre
dentres-sorties ncessaires pour lire un article dans un fichier avec un seul niveau
dindex matre. Mme question pour les insertions darticles.

Question 5
Une recherche dans un fichier simplement index par un arbre B sur une cl non discriminante (cl secondaire) peut tre coteuse. Pourquoi ? Proposez des approches
pour rduire le temps dentres-sorties disques ncessaire.

4. ARBRES B+ (chapitre III)

On dsire tudier les proprits des arbres B+ pour les cls alphabtiques, pour les
attributs de type chane de caractres de longueur variable (varchar). On dfinit ici un
arbre B+ un peu particulier comme suit :
les articles sont tous stocks dans les feuilles,
lors dun clatement, la cl mdiane est recopie au niveau suprieur,
le nombre darticles dans une feuille ou le nombre de couples cl/pointeur dans un
sommet intermdiaire est contrl par le taux de remplissage (en octets) qui doit
rester compris entre 50 % et 100 %,
la racine admet un taux de remplissage quelconque,
la racine est soit une feuille soit un sommet non-feuille qui possde alors au moins
deux fils.
On notera que le taux minimal de remplissage nest qu peu prs de 50 % cause des
problmes de parit du nombre des articles lors des clatements et cause de la longueur variable des articles.
On supposera que les pages font 50 octets, quun pointeur (sur un sommet) est cod
sur 4 octets, que les cls sont de longueur variable, que les articles se composent de la

Exercices 727

cl + une information associe sur 10 octets + 2 octets qui servent de sparateurs et

que les couples cl/pointeur nutilisent quun sparateur. On ngligera dans les calculs
linformation de contrle en tte des pages qui permet de connatre le nombre
darticles ou de couples cl/pointeur, etc.
Par exemple larticle de cl Marcel est reprsent par Marcel#xxxxxxxxxx# soit
18 octets. Le couple cl/pointeur (Marc, sommet yyyy) est reprsent par
Marc#yyyy soit 9 octets.

Question 1
Donnez larbre obtenu en partant dune racine vide aprs insertion des articles de cl :
{Marcel, Marius, Martine, Maurice, Marcelle, Maude, Marc, Marguerite, Mathilde,
Maxime, Marielle, Martial, Mariette, Marina, Matthieu, Mattias} dans lordre indiqu.

Question 2
Donnez larbre obtenu si la liste des articles est trie selon lordre des cls :
{Marc, Marcel, Marcelle, Marguerite, Marielle, Mariette, Marina, Marius, Martial,
Martine, Mathilde, Matthieu, Mattias, Maude, Maurice, Maxime}.

Question 3
Proposez une procdure de construction de larbre B+ par construction directe des
feuilles et des sommets intermdiaires partir dun fichier tri des articles.

Question 4
On remarque que dans un arbre B+ les cls dans les sommets non-feuilles ne servent
que daiguilleurs dans la recherche dun article de cl donne. On utilise cette
remarque pour augmenter le nombre de couples cl/pointeur dans les sommets nonfeuilles en remplaant les cls par un prfixe de ces cls.
Donnez la rgle qui permet de dterminer le plus petit prfixe possible qui conserve la
proprit daiguiller correctement la recherche dans larbre.

Question 5
Donnez larbre obtenu en utilisant des prfixes par insertions rptes comme dans la
question 1.

Question 6
Discutez les avantages et les inconvnients de cette mthode pour de petits fichiers et
pour de grands fichiers.

728 BASES DE DONNES : OBJET ET RELATIONNEL

5. UTILISATION DINDEX SECONDAIRES

(chapitre III)
Un index secondaire est un index sur une cl de recherche (dite cl secondaire)
construit de telle sorte que linformation associe la cl soit ladresse de lenregistrement (ou tuple en relationnel) et non pas lenregistrement lui-mme. Cette adresse
peut tre soit directement une adresse relative de tuple dans le fichier le contenant,
soit indirectement la cl (dite primaire) primaire dun autre index permettant de
retrouver ce tuple. Dans ce dernier cas, que nous utiliserons ici, une recherche sur cl
secondaire consiste dabord rechercher la cl secondaire dans lindex secondaire,
obtenir linformation associe cest--dire la cl primaire, puis rechercher le tuple
dans lindex primaire laide de la valeur trouve.
Un tel index est dit non-plaant car les tuples correspondants deux valeurs successives de cl secondaire dans lindex ne se trouvent pas en squence dans le fichier les
contenant, ni non plus en gnral dans les mmes pages de disques (contrairement
lindex primaire dit plaant).
Soit R (A, B, C, D, E) une relation cinq attributs dont A est une cl unique. On suppose que la relation est place, par un index primaire, sur lattribut A en utilisant un
arbre B+ quatre niveaux (dont le dernier niveau contient les tuples).
Deux index secondaires sur C et E sont disponibles. Ces index sont galement organiss en arbre B+. Chaque index secondaire est compos de trois niveaux.
R comprend 1 000 000 de tuples et donc autant de valeurs diffrentes pour A. Les
tuples font en moyenne 100 octets, les pages de disques 1 K octets. Avec un taux de
remplissage de 75 %, le dernier niveau de larbre B+ occupe donc environ 130 000
pages de disque. Il y a 10 000 valeurs diffrentes pour C et 1 000 pour E. On suppose
de plus que toutes les distributions des attributs X sont (1) uniformes entre une valeur
MIN_X et MAX_X et (2) indpendantes.

Question
Quelle est la meilleure mthode et le nombre correspondant dentrees/sorties disques
ncessaires pour rpondre aux recherches suivantes :
Q1. (A = valeur)
Q2. (valeur < A )
Q3. (C = valeur)
Q4. (B = valeur)
Q5. (valeur 1 < C < valeur 2).
Q6. (C = valeur 1) ET (E = valeur 2)

Exercices 729

6. OPTIMISATION ET INDEX SECONDAIRES

(chapitre III)
La recherche dans les bases de donnes seffectue selon des critres multiples, du type :
<critre simple> {AND | OR } <critre simple> ...

o chaque critre simple est lui-mme du type :

<attribut> <comparateur> <valeur>.

Les comparateurs peuvent tre =, <, > , , . Les expressions de AND et OR peuvent
tre encadres de parenthses pour indiquer les priorits.
Par exemple, on recherchera dans un fichier de vins tous les articles satisfaisant :
(CRU = Volnay OR CRU = Chablis)
AND DEGR 12 AND MILLSIME = 2000.

Question 1
On suppose le fichier des vins indexs par un arbre B sur la cl secondaire DEGR.
Proposez un format dentre pour un tel index. Justifiez votre solution.
Les degrs tant nombreux car continus entre 0 et 20, comment peut-on rduire leur
nombre ?
Proposez un algorithme permettant de rpondre aux requtes prcisant DEGR > $v,
o $v dsigne un rel compris entre 0 et 20.

Question 2
Ce fichier est aussi index sur les cls secondaires CRU et MILLSIME. Proposez
trois mthodes pour rsoudre des requtes du type CRU = $c AND MILLSIME =
$m, lune utilisant les deux index, les deux autres un seul ($c et $m sont deux
constantes). Essayer destimer le cot en entres-sorties de chacune delles. Donnez
des heuristiques simples pour choisir lune ou lautre.

Question 3
De manire gnrale, proposez un algorithme capable dvaluer efficacement des
recherches avec critres multiples conjonctifs (AND).

Question 4
tendre lapproche au cas de critres multiples connects avec des AND et des OR.

Question 5
Un fichier hach peut aussi tre index selon plusieurs attributs. Comment peut-on
amliorer lalgorithme prcdent pour supporter aussi des fichiers hachs ?

730 BASES DE DONNES : OBJET ET RELATIONNEL

7. HACHAGE MULTI-ATTRIBUTS (chapitre III)

Le hachage multi-attributs consiste combiner plusieurs fonctions de hachage H1, H2,
... Hn sur des champs diffrents A1, A2, ..., An des articles dun fichier, ceci afin de calculer ladresse virtuelle dun paquet. En version statique simple, le numro du paquet
est simplement gal H1(A1) || H2(A2) ... Hn(An), o || dsigne loprateur de concatnation. En version extensible, les bits de poids faible de cette chane peuvent tre retenus pour adresser le rpertoire des paquets. Dautres solutions plus sophistiques sont
possibles, par exemple en permutant sur les fonctions de hachage pour prlever des bits
constituant ladresse du rpertoire. Dans la suite, on suppose un fichier hach statique
avec adressage des paquets par concatnation simple des fonctions de hachage.

Question 1
On dsire placer un fichier de lignes de commandes de format (NC, NP, TYPE,
QUANTIT, PRIX) par hachage multi-attributs. NC dsigne le numro de commande, NP le numro de produit et TYPE le type du produit. Sachant que 50 % des
recherches se font sur NC, 20% sur NP et 30% sur le type de produit, proposez des
fonctions de hachage optimum afin de placer un tel fichier dans 100 paquets.

Question 2
Proposez un algorithme gnral pour rpondre aux requtes multicritres prcisant
deux des attributs hachs parmi les trois, par exemple NC et TYPE.

Question 3
Gnralisez lalgorithme pour traiter des requtes multicritres avec AND et OR,
comme vu lexercice prcdent.

Question 4
Les fichiers hachs peuvent aussi tre indexs par des arbres B. Discutez des formats
dadresses darticles intressants pour grer les index en conjonction au hachage.
Intgrez les rsultats de lexercice prcdent lalgorithme de la question 3. En
dduire un algorithme gnral pour traiter des requtes multicritres sur des fichiers
hachs sur plusieurs attributs et indexs.

8. INDEX BITMAPS (chapitre III)

Les index bitmap sont adapts aux attributs ayant un nombre limit de valeurs (a0, a1,
...an) pour un attribut A. Un index bitmap est une table de bits deux dimensions. Le
bit (i, j) est 1 si le ie article du fichier la valeur ai pour lattribut A.

Exercices 731

Question 1
Prcisez le format dun index bitmap et des structures associes. Calculez la taille
dun tel index. Proposez des mthodes de compression pour un tel index.

Question 2
Donnez les algorithmes dinsertion et suppression dun enregistrement dans un fichier
avec index bitmap.

Question 3
Un index bitmap sur un attribut A est idal pour acclrer des recherches sur critre
de la forme :
A = $a0 OR A = $a1 OR ... A = $an.

Prcisez lalgorithme de recherche.

Question 4
On peut grer plusieurs index bitmap pour un mme fichier, sur des attributs A, B, etc.
Prcisez les types de critres pouvant tre traits par des index bitmap.

Question 5
On considre un fichier avec index bitmap et index secondaires sous la forme darbre
B. Que doit rfrencer une entre dans un index secondaire pour tre combinables
avec les index bitmap ? Donnez un algorithme gnral de recherche multicritres prenant en compte les index secondaires et les index bitmap.

9. MODLE RSEAU (chapitre IV)

On dsire faire circuler des camions encombrants dans une ville pour livrer un client.
Soit le schma suivant de la base de donnes urbaine dans le modle rseau :
RUE

CARREFOUR

RC

CC

CONNEXION

732 BASES DE DONNES : OBJET ET RELATIONNEL

Une rue possde un nom, une longueur, une largeur minimum, un revtement et un
nombre de voies. Un carrefour possde un nom et un indicateur de prsence de feu tricolore. Une connexion indique la prsence ventuelle dun sens interdit.

Question 1
Donnez le schma CODASYL correspondant ce diagramme.

Question 2
Donnez le graphe des occurrences correspondant au plan simplifi, trois rues (X, Y,
Z) et quatre carrefours (C1, C2, C3, C4), suivant :

C2

Rue X

Rue Y

C3

C4

C1
Rue Z

Question 3
Donnez le programme en DML CODASYL permettant de trouver tous les carrefours
avec feu de la rue Albert Einstein.

Question 4
Donnez le programme en DML CODASYL permettant de trouver toutes les rues qui
sont directement accessibles depuis la rue Albert Einstein (donc qui lintersectent o
sy raccordent). Une rue nest pas accessible si elle est en sens interdit.

Question 5
Sachant que les poids lourds partent dun dpt situ dans la rue A, doivent rejoindre
le client situ rue B et ne doivent circuler que dans des rues de largeur suprieure 10
mtres, donner le programme en DML CODASYL et pseudo-code qui recherche tous
les itinraires possibles en ne les donnant quune fois avec leur longueur et le nombre
de feux. On prcise que la partie pseudo code devra rester un niveau de quelques
blocs de commentaires et devra rsoudre le problme de la dtection des boucles.

Exercices 733

Question 6
Proposez un placement des types darticle dans un ou plusieurs fichiers pour acclrer
les performances. Donnez le nombre dentres-sorties disque ncessaires pour traiter
la question 4.

10. DU RSEAU AU RELATIONNEL

(chapitre IV et VI)
On considre la base de donnes dont le schma entit-association est reprsent cidessous :
NP

Nom

Type

FOURNISSEURS
(1,N)

Couleur

(0,N)

Date

ACHTE

NSS

Nom

Prnom

CLIENTS

Prix

VEND
(0,N)

Remise

FOURNISSEURS

NF

Nom

Rgion

Cette base dcrit des produits vendus par des fournisseurs des clients.

Question 1
Donnez le schma rseau en DDL CODASYL correspondant au diagramme entitassociation reprsent figure 1. On prcise que les entits PRODUITS et FOURNISSEURS sont ranges dans un mme fichier FOU via le set VEND, alors que les instances de CLIENTS sont ranges dans le fichier CLI.

Question 2
crire les programmes en DML CODASYL correspondant aux requtes suivantes :
1. Nom des fournisseurs vendant des produits de type informatique .
2. Nom des clients ayant achet de tels produits.

734 BASES DE DONNES : OBJET ET RELATIONNEL

3. Noms des produits et liste des fournisseurs associs ayant vendu au client de NSS
153300017012.
4. Chiffre daffaires total ralis avec le client Dupond Jules.
Utiliser du pseudo-Pascal ou pseudo-C si ncessaire.

Question 3
Donnez un schma relationnel pour la base de donnes reprsente.

Question 4
Exprimer en SQL les requtes correspondant aux questions tudies au 2.

Question 5
Pour les schmas reprsents, proposez un algorithme de traduction automatique de
requte SQL de type restriction-projection-jointure en programme DML CODASYL.
Pour cela, on traduira chaque requte en un arbre doprations de lalgbre relationnelle optimis de manire adquate ; ensuite, on traduira des groupes doprateurs
choisis en programmes DML avec du pseudo-PASCAL ou pseudo-C.

Question 6
tudiez le r-engineering de la base rseau propose en base relationnelle. Discutez
des difficults. Proposez une dmarche.

11. CALCULS DE DOMAINES ET DE TUPLES

(chapitre V)
Soit le schma entit-association reprsent figure 1, modlisant une base de donnes
dcrivant des entits R, S et T relies par les associations RS, ST1 et ST2. Tous les
attributs sont de type entier. Les cls des entits sont soulignes ; elles correspondent
simplement au premier attribut des entits. Les cardinalits minimum et maximum des
associations sont indiques sur les branches correspondantes. Ainsi, un tuple de R est
associ par lassociation RS au moins 0 et au plus n tuples de S ; rciproquement, un
tuple de S est associ par lassociation RS au moins 0 et au plus n tuples de T ; un
tuple de T correspond par lassociation ST1 un et un seul tuple de S ; etc.

Exercices 735

C2

C1

C3

S
(0,1)

C4

B1

A1

A2
A3

(0,N)

RS

(1,1)
D1

ST2

ST1

(0,N)

D2

(1,N)
T

E1

E2

E3

Question 1
Donnez le schma de la base de donnes relationnelle reprsentant directement ce diagramme entit-association (une entit gnrant une relation, une association gnrant
une relation), avec les cls et les contraintes rfrentielles ncessaires.

Question 2
Exprimer en calcul de tuples les requtes suivantes :
1. Donnez tous les attributs de S pour les tuples dont lattribut C3 est compris entre
100 et 200.
2. Donnez les attributs C1 et C2 de S, E1 et E2 de T tels que les tuples de S et T soient
associs par un tuple de ST1 dattribut D1 suprieur 10.
3. Mme question, mais on souhaite en plus quil existe un tuple de R correspondant
chaque tuple de S slectionn, via lassociation RS, ayant un attribut A2 positif.
4. Donnez les tuples de T associs par RS tout tuple de R et au moins un tuple de T
par ST1 ou ST2.

Question 3
Exprimer ces mmes requtes en calcul de domaines.

Question 4
Exprimer ces mmes requtes en QBE.

Question 5
Exprimer ces mmes requtes en SQL.

736 BASES DE DONNES : OBJET ET RELATIONNEL

12. ALGBRE RELATIONNELLE (chapitre VI)

Soit la base de donnes Scurit Routire comprenant les tables :
PERSONNE
VHICULE
CONDUCTEUR
ACCIDENT
VHPART
BLESS

(NPERS, NOM, PRNOM, ADRESSE)

(NVEH, MARQUE, TYPE)
(NPERS, NVEH, NBACC)
(NACC, DATE, DPT)
(NACC, NVEH, NCOND)
(NACC, NPERS, NVEH, GRAVIT)

En dfinissant le schma, les hypothses suivantes ont t faites :

Les cls sont soulignes.
Les relations PERSONNE et VHICULE ont les significations videntes.
La relation CONDUCTEUR associe les personnes et les vhicules et mmorise le
nombre daccidents auxquels a particip un conducteur donn au volant dun vhicule donn.
La relation ACCIDENT donne les informations globales dun accident.
La relation VHPART (vhicule participant) est dfinie de sorte que chaque vhicule impliqu dans un mme accident donne un tuple avec le mme numro daccident. Lattribut NCOND est le numro de la personne conduisant le vhicule au
moment de laccident.
La relation BLESS indique tous les blesss dun accident (un par tuple), y compris
le conducteur si celui-ci a t bless.
Lattribut GRAVIT peut prendre les valeurs Bnigne, Lgre, Srieuse,
Grave, Fatale.

Question 1
Exprimer sous la forme dun arbre de calcul de lalgbre relationnelle les requtes suivantes :
a) Donnez le nom, le prnom, la date de laccident pour chaque personne blesse fatalement dans un accident du dpartement 75 dans une voiture Citron.
b)Trouver les personnes qui ont t blesses dans tous les accidents o elles taient
conductrices.

Question 2
Que retrouve larbre algbrique suivant ?

Exercices 737

VHICULE

TYPE

VHPART

BLESS

'HONDA-CIVIC'

GRAVIT

'LGRE'

NVH

NACC
N COND
NVH

NACC
N PERS

N PERS

Question 3
Calculez le cot en entres/sorties disques de larbre de la question prcdente avec
les hypothses suivantes :
La relation VHICULE comporte 1 000 000 tuples dont 850 sont des Honda Civic;
elle est place par hachage statique sur le NVH ; elle possde un index secondaire
sur le TYPE qui est un arbre B+ 3 niveaux.
Les index secondaires du systme utilis retournent la cl primaire (ou cl de placement) et non pas directement ladresse physique.
La relation VHPART comporte 100 000 tuples ; elle est place sous forme darbre
B+ sur le NACC (index primaire).
La relation BLESS comporte 40 000 tuples dont 10 000 sont des blesss lgers ;
elle est place en squentiel avec un facteur de blocage (moyen) de 20 tuples par
page.
Les jointures sont faites par lalgorithme des boucles imbriques.
Tous les rsultats intermdiaires tiennent en mmoire centrale ; une page de
mmoire correspond un bloc de disque.

Question 4
Que devient le cot des entres/sorties si la mmoire est limite m pages ?

738 BASES DE DONNES : OBJET ET RELATIONNEL

13. OPRATEURS RELATIONNELS

(chapitre VI)
On dsire raliser un valuateur doprations de lalgbre relationnelle sur un gestionnaire de fichiers avec index secondaires. Les oprations de lalgbre relationnelle
considres sont les oprations classiques (restriction, projection, jointure, union, diffrence, intersection) avec en plus deux oprateurs spcialiss pour les calculs dagrgats (groupage et calcul de fonction). Les expressions dattributs sont aussi tendues
avec les calculs arithmtiques (par exemple A*B+C est utilisable en argument de projection, A, B et C tant des attributs simples).
Loprateur de groupage (nomm GROUP ou NEST) a pour argument un ensemble
dattributs X sur lequel est ralis le groupage et un ensemble dattributs grouper Y.
Il scrit formellement X/Y(R). Lopration de groupage des attributs Y de la relation
R sur les attributs X construit une relation non en premire forme normale (NF2) de
schma XY ; pour chaque valeur de X, lensemble des valeurs de Y correspondant
cette valeur de X est rpertori. Par exemple, soit la relation :
R

{B}

{5,7}

{8}

{8}

A/B(R) est la relation suivante :

A(B*)(R)

Loprateur de calcul de fonction applique simplement une fonction sur ensemble

une colonne dune relation value par un ensemble. Les fonctions considres sont
MIN, MAX, AVG, SUM, COUNT qui sont respectivement le minimum, le maximum,

Exercices 739

la moyenne, la somme et le compte. Par exemple, lapplication de loprateur MINB

la relation prcdente conduit au rsultat suivant :
A(B*)(R)

{B}

{5,7}

{8}

{8}

Afin dillustrer, on considre une base de donnes dcrivant un stock de jouets de type
A, B, C ou D livrs par des fabricants en une certaine quantit une certaine date. Le
schma de la base est le suivant :
JOUETS(NJ,NOMJ,TYPE,PRIX)
FABRIQUANTS(NF,NOMF,VILLE,ADRESSE)
LIVRAISONS(NF,NJ,DATE,QUANTITE)

Question 1
Exprimez en algbre relationnelle tendue les questions suivantes sur la base de donnes des jouets :
a) Donnez la liste des fabricants qui ont livr au moins un jouet de type A et de prix
suprieur 1 000 F ainsi que le nom des jouets correspondants livrs.
b)Donnez la liste des fabricants qui nont pas livr de jouets.
c) Donnez la somme des quantits livres par chaque fabricant (caractris par NOMF
et ADRESSE).

Question 2
On se propose doptimiser lalgorithme dintersection de deux relations R1 et R2.
Proposez trois algorithmes permettant de raliser cet oprateur dans les cas sans
index, respectivement bass sur :
a) le produit cartsien des deux relations ;
b)le tri des deux relations ;
c) le hachage des relations avec tableaux de bits.
En supposant quil existe trois tampons dune page en mmoire, que les relations
comportent respectivement r1 et r2 pages (r1 < r2) et que la relation intersection est
compose de i pages, calculez approximativement le cot en E/S de chaque algorithme. On supposera que les tableaux de bits tiennent en mmoire et quils permettent dliminer un pourcentage b des tuples de la deuxime relation.

740 BASES DE DONNES : OBJET ET RELATIONNEL

Question 3
On se propose dtudier lalgorithme de groupage dune relation R. Proposez trois
algorithmes permettant de raliser cet oprateur dans les cas sans index, respectivement bass sur :
a) la comparaison des tuples de la relation (proche du produit cartsien) ;
b)le tri de la relation ;
c) le hachage de la relation avec comparaisons internes aux paquets.
En supposant quil existe trois tampons dune page en mmoire, que la relation comporte r pages et que la relation groupe est compose de g pages, calculez approximativement le cot en E/S de chaque algorithme.

Question 4
Exprimer la question suivante en SQL sur la base de donnes des jouets :
Donnez les chiffres daffaires de chaque fabricant (caractris par son NOMF et son
ADRESSE) de poupes (NOMJ LIKE Poupe ).
Exprimer cette question en algbre relationnelle tendue.
Donnez un arbre doprateurs dalgbre relationnelle optimis permettant de calculer
la rponse cette question. On ajoutera pour cela loprateur de groupage (not par un
rectangle) aux oprateurs classiques.

14. LANGAGES DE REQUTES

(chapitres V, VI et VII)
Soit la base suivante dcrivant un supermarch ( les cls sont soulignes) :
RAYON (NOMR, TAGE)
ARTICLE(RFRENCE, TYPE, DESCRIPTION, COULEUR)
DISPONIBILIT(NOMR, RFRENCE, QUANTIT)
EMPLOY(NUMERO, NOME, SALAIRE, RAYON, RESPONSABLE)

Les rayons identifis par la cl NOMR sont situs un tage donn. Les articles sont
rfrencs par lentier RFRENCE et dcrit par un type, une description et une couleur. Ils sont disponibles en une certaine quantit chaque rayon. Un employ travaille un rayon et a pour responsable un autre employ. Lattribut responsable reprsente donc un numro demploy.

Exercices 741

Question 1
Proposez sous la forme dun graphe un ensemble de cls trangres pour cette base de
donnes.

Question 2
Exprimer en algbre relationnelle puis en SQL les requtes suivantes :
a) rfrences des articles de type lectromnager en rayon au second tage,
b)nom des employs travaillant dans un rayon proposant des articles de type jouet
pour une quantit totale suprieure 1 000.

Question 3
Exprimer en SQL les requtes suivantes :
c) nom des employs qui gagnent plus que leur responsable,
d)tages qui ne vendent que des vtements.

Question 4
Exprimer en calcul de tuple puis en SQL la requte suivante :
e) nom et salaire du responsable le mieux pay.

15. LANGAGES DE REQUTES

(chapitres V, VI et VII)
Soit le schma relationnel suivant du Windsurf-Club de la Cte de Rve (WCCR) :
SPOT (NUMSPOT, NOMSPOT, EXPOSITION, TYPE, NOTE)
PLANCHISTE (NUMPERS, NOM, PRENOM, NIVEAU)
MATOS (NUMMAT, MARQUE, TYPE, LONGUEUR, VOLUME, POIDS)
VENT (DATE, NUMSPOT, DIRECTION, FORCE)
NAVIGUE (DATE, NUMPERS, NUMMAT, NUMSPOT)

La base du WCCR comprend cinq relations et les cls sont soulignes. Les SPOTS
sont les bons coins pour faire de la planche, avec un numro, leur nom, lexposition
principale par exemple Sud-Ouest, le type par exemple Slalom ou Vague, et une
note dapprciation globale. Les PLANCHISTEs sont les membres du club et les invits, les niveaux varient de Dbutant Comptition. Le MATOS (jargon planchiste
pour matriel) comprend la description des planches utilises (pour simplifier les
voiles, ailerons, etc., ne sont pas reprsents). Le VENT dcrit la condition moyenne
dun spot pour une date donne. Enfin NAVIGUE enregistre chaque sortie dun plan-

742 BASES DE DONNES : OBJET ET RELATIONNEL

chiste sur un spot une date donne avec le matos utilis. Pour simplifier, on suppose
quun planchiste ne fait quune sortie et ne change pas de matos ni de spot dans une
mme journe.

Question 1
Indiquez les cls trangres ventuelles de chaque relation.

Question 2
Donnez les expressions de lalgbre relationnelle qui permettent de calculer les
requtes suivantes :
a) Nom des planchistes de niveau Confirm qui ont navigu le 20/07/99 sur un spot
o le vent moyen tait suprieur force 4 sur une planche de moins de 2,75 m.
b)Nom des planchistes qui ne sont pas sortis le 20/07/99
c) Nom des planchistes qui ont essay tous les types de planches de la marque
FANA-BIC. On suppose que tous les types sont dans la relation MATOS.

Question 3
Donnez les expressions de calcul de tuples correspondant aux trois requtes prcdentes.

Question 4
Donnez les ordres SQL correspondant aux requtes suivantes :
c) Nom des planchistes qui ont essay tous les types de planches de la marque
FANA-BIC. On suppose que tous les types sont dans la relation MATOS.
d)Pour chaque spot de la base, en indiquant son nom, donner le nombre de jours de
vent au moins de force 4 pour lanne 94.
e) Pour chaque marque de matriel reprsente par au moins 10 planches, indiquer le
nombre dutilisateurs Confirm ou Expert.

16. LANGAGE SQL2 (chapitre VII)

Soit la base de donnes touristique suivante (les cls sont soulignes) :
STATION (NUMSTA, NOMSTA, ALTITUDE, REGION)
HOTEL (NUMHOT, NOMHOT, NUMSTA, CATEGORIE)
CHAMBRE (NUMHOT, NUMCH, NBLITS)
RESERVATION (NUMCLI, NUMHOT, NUMCH, DATADEB, DATEFIN, NBPERS)
CLIENT (NUMCLI, NOMCLI, ADRCLI, TELCLI)

Exercices 743

Les clients rservent des chambres dans des htels en station. On note que pour une
rservation de plusieurs personnes (couple ou famille) un seul nom de client est enregistr. De plus une rservation porte sur une seule chambre (pour une famille dans
deux chambres il faudra deux tuples dans rservation).
Exprimer en SQL les questions suivantes :

Question 1
Donnez le nom des clients et le nombre de personnes correspondant pour les rservations de lhtel Bellevue Courchevel.

Question 2
Pour chaque station de Haute-Savoie, donner le nombre de lits en catgorie trois
toiles.

Question 3
Pour chaque station de Haute-Savoie, donner le nombre de chambres rserves le
samedi 11/02/95.

Question 4
Quels sont les noms des htels de catgorie deux toiles de Mribel qui sont complets la semaine du 12/02/2000 au 18/02/2000 ?

Question 5
Quelles sont les rgions dont toutes les stations sont plus de 1500 m daltitude ?

Question 6
Quels sont les clients qui sont alls dans toutes les stations du Jura ?

17. SQL2 ET LES JOINTURES (chapitre VII)

Soit la base de donnes suivante :
FREQUENTE (Buveur, Bar)
SERT (Bar, Vin)
AIME (Buveur, Vin)

Tous les attributs sont de type chanes de caractres notamment un bar, un buveur ou
un vin.

744 BASES DE DONNES : OBJET ET RELATIONNEL

Exprimer les questions suivantes en SQL :

1)Donnez les buveurs qui frquentent un bar servant du Beaujolais nouveau.
2)Donnez les buveurs qui aiment au moins un vin servit dans un bar quils frquentent.
3)Donnez les buveurs qui naiment aucun des vins servis dans les bars quils frquentent.

18. SQL2 ET LES AGRGATS (chapitre VII)

On considre la base de donnes relationnelle reprsente figure 1 correspondant
approximativement au benchmark TPC/D. Elle stocke des commandes de numro
NUMCO passes par des clients de numro NUMCLI dcrits dans la table CLIENTS.
Chaque commande est caractrise par un tat, un prix, une date de rception, une
priorit et un responsable. Une commande est compose de lignes, chaque ligne tant
caractrise par un numro NUMLIGNE et correspondant un produit de numro
NUMPRO, command un fournisseur NUMFOU. Les produits sont commands en
une certaine quantit pour un prix total PRIX, avec une remise en pourcentage
(REMISE) et un taux de TVA (taxe). Les produits sont dfinis par un nom, une
marque, un type et une forme, ainsi quun prix unitaire de base. Fournisseurs et clients
sont des personnes dcrites de manire standard. PRODFOURN est une table associative associant produit (NUMPRO) et fournisseur (NUMFOU) en indiquant pour
chaque lien la quantit disponible et un commentaire libre.
COMMANDES (NUMCO, NUMCLI, ETAT, DATE, PRIORIT, RESPONSABLE)
LIGNES(NUMCO, NUMLIGNE, NUMPRO, NUMFOU, QUANTIT, PRIX, REMISE, TAXE)
PRODUITS (NUMPRO, NOM, MARQUE, TYPE, FORME, PRIXUNIT)
FOURNISSEURS (NUMFOU, NOM, ADRESSE, NUMPAYS, TELEPHONE, COMMENTAIRE)
PRODFOURN (NUMPRO, NUMFOU, DISPONIBLE, COMMENTAIRE)
CLIENTS (NUMCLI, NOM, ADRESSE, NUMPAYS, TELEPHONE, COMMENTAIRE)
PAYS (NUMPAYS, NOM, CONTINENT)

Exprimer en SQL les questions suivantes :

a) Calculez le prix TTC de chaque commande.
b)Calculez le nombre de produits (rubriques) par chaque fournisseur.
c) Donnez les produits vendus par tous les fournisseurs.
d)Donnez les produits vendus par tous les fournisseurs dans tous les pays.
e) Donnez les noms et adresses des clients allemands ayant pass des commandes de
produits de type CD des fournisseurs franais.
f) Calculez les recettes effectues au travers de ventes de fournisseurs des clients du
mme pays, cest--dire les recettes rsultant de ventes internes un pays, et ceci
pour tous les pays dEurope pendant une anne commenant la date D1.

Exercices 745

19. SQL2 ET OPTIMISATION

(chapitres VII et X)
Soit le schma relationnel de la Socit Franaise dArchologie (fictive) :
OBJET (NUM-OBJ, DESCRIPTION, TYPE, DATATION, NUM-VILLE, NUM-SITE,
NUM-MUSEE)
VILLE (NUM-VILLE, ANCIEN-NOM, NOM-ACTUEL)
MUSEE (NUM-MUSEE, NUM-VILLE, NOM)
SITE (NUM-VILLE, NUM-SITE, DESCRIPTION, CIVILISATION)
PUBLICATION (NUM-PUB, TITRE, DATE, EDITEUR)
AUTEUR (NUM-AUT, NOM, PRENOM)
COOPERATION (NUM-AUT, NUM-PUB)
REFERENCE (NUM-PUB, NUM-OBJ)

Cette base gre des objets archologiques et des publications sur ces objets. La relation OBJET dcrit les objets proprement dits avec lindication de leur type (par
exemple vase), de leur datation qui est une anne, du site o ils ont t dcouverts et
du muse o ils se trouvent actuellement. La relation VILLE comprend deux noms
pour simplifier (ce qui par exemple exclut le cas BIZANCE-CONSTANTINOPLEISTAMBUL). La relation SITE indique la ville laquelle se rattache le site et un
numro qui est un numro dordre pour cette ville : toutes les villes ont un site 1, un
site 2, etc. La civilisation du site est une grande catgorie comme romaine ou crtoise. Les cls sont soulignes.

Question 1
Exprimer en SQL les requtes suivantes sur la base :
Q1. Quelles sont les frises du troisime sicle ? Donnez leur numro et leur description.
Q2. Mme question avec en plus le nom du muse o elles sont exposes.
Q3. Noms et prnoms des auteurs douvrage(s) rfrenant des objets de la civilisation Dorienne.
Q4. Quelles statues sont exposes dans la ville o elles ont t dcouvertes ?
Donnez le numro et la description.
Q5. Donnez le nom actuel des villes (sil en existe) dont le nom actuel est le mme
que le nom ancien dune autre ville.
Q6. Donnez le nombre de statues trouves dans chaque site de la civilisation phnicienne.
Q7. Quels sont les sites dAthnes qui ont fourni plus dobjets que le site 5 nen a
fourni ?
Q8. Noms et prnoms des auteurs des ouvrages qui rfrencent tous les objets trouvs dans le site 2 de Thbes.

746 BASES DE DONNES : OBJET ET RELATIONNEL

Question 2
Soit la requte SQL suivante :
SELECT P.TITRE, P.DATE
FROM
PUBLICATION P, AUTEUR A, COOPERATION C,
REFERENCE R, OBJET O, MUSEE M
WHERE A.NOM = Vieille
AND
A.PRENOM = Pierre
AND
A.NUM-AUT = C.NUM-AUT
AND
C.NUM-PUB = P.NUM-PUB
AND
P.EDITEUR = ditions archologiques modernes
AND
P.NUM-PUB = R.NUM-PUB
AND
R.NUM-OBJ = O.NUM-OBJ
AND
O.TYPE = Mosaque
AND
O.NUM-MUSEE = M.NUM-MUSEE
AND
M.NOM = Le Louvre

Proposez deux arbres algbriques diffrents pour excuter cette requte. Le premier
arbre sera optimis au mieux en utilisant les heuristiques de restructuration algbrique
et le second sera le pire possible.

Question 3
On suppose quil y a dans la base 10 000 publications, 100 diteurs distincts,
1 000 auteurs de noms diffrents (pas dhomonymes), 2000 cooprations, 100 000 objets,
200 types dobjets diffrents, 1 000 000 de rfrences et 100 muses de noms diffrents (pas dhomonyme).
On suppose de plus que toutes les distributions sont uniformes et indpendantes.
En prenant comme unit de cot la comparaison pour les slections et les jointures, en
supposant quil ny a pas dindex et en admettant que toutes les jointures se font par
produit cartsien, calculer le cot dexcution des deux arbres que vous avez propos.

Question 4
Si vous tiez autoris crer un seul index pour acclrer cette requte, lequel choisiriez-vous ? Pourquoi ?

20. INTGRIT DES DONNES (chapitre VIII)

Lobjet de ltude est de concevoir un composant logiciel capable de contrler les
contraintes dintgrit lors des mises jour dune base de donnes relationnelles. Le
composant doit tre intgr dans un SGBD qui gre des relations diffrentielles. Lors
de lexcution des commandes de mise jour (insrer, modifier, supprimer), deux

Exercices 747

relations diffrentielles sont associes chaque relation R : la relation des tuples supprims R et celle des tuples insrs R+. Un tuple modifi donne naissance deux
tuples, lun dans R-, lautre dans R+. En fin de transaction valide, les tuples de R
sont enlevs de R et ceux de R+ ajouts R. Le SGBD ralise : R = (R R-) R+.
En guise dillustration, on utilisera la base compose des tables suivantes :
PLAGE (NP, NOMP, TYPE, REGION, POLLUTION)
NAGEUR (NN, NOM, PRENOM, QUALITE)
BAIGNADE (NN, NP, DATE, DUREE).

La relation PLAGE modlise les plages de France, de nom NOMP, de type TYPE
(galets, sable ou rocher) ayant un taux de pollution donn (attribut POLLUTION). La
relation NAGEUR mmorise les nageurs de qualit excellente, bonne ou mdiocre. La
relation BAIGNADE dcrit les bains effectus par les nageurs.

Question 1
Dfinir en SQL2 les contraintes dintgrit suivantes :
1. La qualit dun nageur est excellente, bonne ou mdiocre (contrainte de domaine).
2. Toute baignade a t effectue par un nageur existant dans la base sur une plage
existante (contraintes rfrentielles).
3. Le type et la rgion dune plage dterminent sa pollution de manire unique (dpendance fonctionnelle).
4. La somme des dures des baignades dun nageur par jour ne doit pas excder deux
heures.

Question 2
Prcisez quels types de contraintes dintgrit peuvent tre vrifies aprs chaque
ordre de mise jour (INSERT, DELETE, UPDATE) ceux qui ncessitent dattendre la
fin de transaction.

Question 3
Proposez des algorithmes pour traiter chaque type de contraintes dintgrit, soient
excuts aprs la mise jour, soient en fin de transaction. Montrer quil est possible
de combiner les deux types de vrification.

Question 4
Les contraintes avec agrgats comme la somme des dures des baignades sont coteuses vrifier chaque mise jour. Proposez une mthode base sur des donnes
redondantes afin de rduire ce cot.

748 BASES DE DONNES : OBJET ET RELATIONNEL

21. VUES ET TRIGGERS (chapitres VIII et IX)

Soit la base de donnes CINMA suivante :
FILM(NUMF, TITRE, DATE, LONGUEUR, BUDGET, RALISATEUR, SALAIRER)
GNRIQUE(FILM, ACTEUR, ROLE, SALAIRE)
PERSONNE (NUMP, FNOM, LNOM, DATENAIS, SEXE, NATIONALIT, ADRESSE,
TLPHONE)
ACTEUR (NUMA, AGENT, SPCIALIT, TAILLE, POIDS)
CINMA(NUMC, NOM, ADRESSE, TLPHONE, COMPAGNIE)
PASSE (NUMF, CINMA, SALLE, DATEDEB, DATEFIN, HORAIRE, PRIX)
SALLE (CINMA, NUMS, TAILLECRAN, PLACES)

NUMF, NUMP, NUMA, NUMC, NUMS, sont des identifiants uniques (cls primaires) pour
respectivement : FILM, PERSONNE, ACTEUR, CINMA, SALLE.
Tout nom de relation utilis comme attribut est une cl trangre qui renvoie lidentifiant (cl primaire) de la relation correspondante, par exemple dans GNRIQUE,
FILM correspond NUMF de FILM et est dfini sur le mme domaine.
RALISATEUR dans FILM et NUMA dans ACTEUR sont dfinis sur le domaine des
NUMP.
Le numro de salle NUMS est un numro local pour chaque cinma (Salle 1, 2, 3, ).

Question 1
Donnez la dfinition de FILM en SQL2 en prcisant les contraintes de domaine, de
cl (primaire ou candidate), et de cl trangre.

Question 2
Mme question pour GNRIQUE si on suppose quun acteur peut jouer plusieurs
rles dans un mme film.

Question 3
Exprimer la contrainte gnralise suivante : Le budget dun film doit tre suprieur
la somme des salaires des acteurs jouant dans ce film

Question 4
crire un dclencheur qui met jour automatiquement le numro de film dans toutes
les relations o il est utilis si ce numro est modifi dans la relation FILM.
On ajoute un attribut NBSALLES a FILM qui indique le nombre de salles o le film
est actuellement visible.

Exercices 749

Question 5
Utiliser des dclencheurs pour grer automatiquement ce nombre de salles.

22. TRIGGERS ET VUES CONCRTES

(chapitre VIII et IX)
On considre la base de donnes relationnelles :
PRODUITS (NP, NOMP, QTES, PRIXU)
VENTES (NP, NC, NV, QTEV)

La relation produit dcrit des produits en stock de numro NP, de nom NOMP, en
quantit QTES, dont le prix de vente unitaire est PRIXU. La relation VENTES dcrit
les ventes ralises ; celles-ci sont numrotes par client. QTEV est la quantit vendue
pour le produit NP au client NC lors de la vente NV. Pour simplifier, on supposera que
les prix des produits ne changent pas.

Question 1
Dfinir les vues VENTEPRO (NC,NP,NV, QTEV, PRIXU) et VENTETOT (NC,
PRIXT) spcifies comme suit :
VENTEPRO donne pour chaque client, pour chaque produit et pour chaque vente la
quantit de produit vendu et le prix unitaire du produit correspondant.
VENTETOT donne pour chaque client le montant total en francs (PRIXT) des
ventes effectues.
On crira les questions SQL permettant de crer ces vues partir des relations de
base.
Montrer que la vue VENTETOT peut tre dfinie partir de la vue VENTEPRO.
Donnez sa dfinition en SQL partir de VENTEPRO.

Question 2
On introduit un oprateur partitionnement reprsent par un rectangle prparant
lapplication du GROUP BY sur une relation, utilisable dans les arbres relationnels ;
cet oprateur partitionne horizontalement la relation sur les attributs paramtres en
effectuant simplement un tri sur ces attributs : il sagit donc en fait dun oprateur de
tri. En addition, on permet lusage de fonctions agrgats et arithmtiques dans les projections. Appliques aux relations partitionnes suite loprateur prcdent, les fonctions agrgats accomplissent les calculs dagrgats selon le dernier partitionnement
effectu.

750 BASES DE DONNES : OBJET ET RELATIONNEL

Donnez larbre relationnel optimis permettant de retrouver les clients ayant achet
pour plus de 10 000 F de produits avec la liste des produits quils ont achets.

Question 3
La modification de questions sur des vues (avec ou sans agrgat) ne permettant pas
toujours doptimiser, une autre mthode dimplantation de vues peut tre base sur la
matrialisation de la vue comme une relation implante sur disque (vue concrte). Le
problme qui se pose est alors de mettre jour la vue concrte lors des mises jour
des relations de base. Une technique possible consiste gnrer des dclencheurs
(triggers).
Exprimer en SQL les dclencheurs permettant de maintenir les relations VENTEPRO et
VENTETOT lors dinsertion dun nouveau produit ou dune nouvelle vente dans la base.
De manire gnrale, prciser les rgles gnrer pour maintenir une vue lors dinsertion dans une relation de base. On pourra considrer les cas suivants :
1. La vue est sans agrgat, cest--dire issue de projection, jointure et restriction des
relations de base.
2. La vue est avec agrgat.

Question 4
Donnez les rgles permettant de maintenir les relations VENTEPRO et VENTETOT
lors dune suppression dun produit ou dune vente dans la base.
De manire gnrale, prciser les rgles gnrer pour maintenir une vue sans agrgat, puis avec agrgat, lors dune suppression dans une relation de base. Discutez
selon les cas. Prciser les attributs quil est ncessaire de rajouter la vue afin dtre
capable de grer correctement les suppressions.

23. GESTION DE VUES VIRTUELLES

(chapitre IX)
Une vue est un ensemble de relations dduites dune base de donnes, par composition des relations de la base. Dans la norme SQL la notion de vue a t rduite une
seule relation dduite. Les mises jour sont gnralement limites aux vues dont les
projections portent sur une seule relation. Soit la base de donnes VITICOLE compose des relations suivantes :

Exercices 751

BUVEURS (NB, NOM, PRENOM, VILLE, AGE)

VINS(NV, CRU, REGION, MILLESIME, DEGRE)
ABUS(NB, NV, DATE, QUANTITE)

Celles-ci dcrivent des buveurs identifis par lattribut numro NB, des vins identifis
par lattribut numro NV et des consommations (ABUS) de vins identifis par le
numro de buveur, le numro de vin et la date de consommation.

Question 1
Donnez les commandes SQL permettant de crer les vues suivantes :
BUVEURSB (NB, NOM, PRENOM, NV, DATE, QUANTITE)

dcrivant les buveurs de Beaujolais,

VINSB (NV, CRU, MILLESIME, DEGRE)

dcrivant les vins de Beaujolais bus par au moins un buveur.

Il est prcis que la vue VINSB est mettable jour et que lon souhaite la vrification
des tuples insrs dans la vue par rapport au reste de la base.

Question 2
Un utilisateur ayant droit dinterroger partir des vues prcdentes pose la question
suivante :
Donnez le nom des buveurs ayant bu du Beaujolais de millsime 1983 en quantit
suprieure 100, le mme jour .
Exprimez cette question telle que doit le faire lutilisateur en SQL. Exprimez galement la question modifie portant sur les relations BUVEURS, VINS et ABUS que traitera le systme.

Question 3
De manire gnrale, proposez en quelques botes, sous la forme dun organigramme,
un algorithme permettant de transformer une question pose sur une vue en une question exprime sur la base.

Question 4
partir de lexemple, dcouvrir et noncer quelques problmes soulevs par la mise
jour travers une vue rfrenant plusieurs tables :
1. ajout dun tuple dans BUVEURSB ;
2. suppression dun tuple dans BUVEURSB.

752 BASES DE DONNES : OBJET ET RELATIONNEL

24. LANGAGES ET OPTIMISATION

(chapitres V, VI et X)
Soit la base de donnes compose des relations :
VILLE(NOMV, POP, NDEP)
DEPARTEMENT(NDEP, NOMD, REGION)
SPECIALITE(NOMV, NOMP, TYPE)

o:
NOMV = nom de ville,
POP = population,
NDEP = numro de dpartement,
NOMD = nom de dpartement,
REGION = nom de rgion,
NOMP = nom de produit,
TYPE = type de produit.
Soit lexpression algbrique suivante rfrenant les relations de cette base de donnes (
reprsente la jointure naturelle) :
DEPARTEMENT
NOMV,NOMP(REGION=Auvergne(POP>10000 (VILLE
SPECIALITE)))
DEPARTEMENT
NOMV,NOMP ( NOMP=Fromage (VILLE
SPECIALITE)))

Question 1
Exprimez cette requte :
1) en calcul relationnel de domaine;
2) en calcul relationnel de tuple;
3) en SQL.

Question 2
Reprsentez la question sous forme dun arbre doprations algbriques.
Proposez un arbre optimis par restructuration algbrique pour cette question.

Question 3
Soit v, d et s les tailles respectives en tuples des relations VILLE, DEPARTEMENT et
SPECIALITE. En supposant luniformit des distributions des valeurs dattributs,
calculez une approximation de la taille du rsultat de la question prcdente en
nombre de tuples. On pourra introduire tout paramtre supplmentaire jug ncessaire.

Exercices 753

25. OPTIMISATION ET CHOIX DINDEX

(chapitre X)
Soit une base de donnes relationnelle compose des trois relations :
R1 (A1,A2,A3,A4,A5)
R2 (B1,B2,B3,B4,B5)
R3 (C1,C2,C3,C4,C5)

On suppose pour simplifier quil nexiste pas dindex.

On considre la requte SQL :
SELECT A2,B3,C4
FROM R1, R2, R3
WHERE A1 = B1
AND B2 = C1
AND A3 = A
AND C3 = C

o a et c dsignent des constantes.

Question 1
Donnez les arbres algbriques relationnels optimiss par les heuristiques classiques
des BD relationnelles (descente des projections et restrictions) permettant dexcuter
cette question.

Question 2
On choisit larbre qui effectue les jointures dans lordre R1 avec R2 puis avec R3. En
considrant lutilisation dun algorithme de jointure par produit Cartsien (boucles
imbriques), calculez le temps dexcution en nombre dE/S de cet arbre en fonction
de la taille en page des relations R1, R2 et R3, du nombre moyen de tuples par page T,
du nombre de valeurs distinctes et non distinctes des attributs utiliss. On supposera
pour cela une distribution uniforme des valeurs dattributs. Tout paramtre supplmentaire jug ncessaire pourra tre introduit.

Question 3
Proposez un ensemble dindex plaant et non plaant optimaux pour la base de donnes et la question considre.
Calculez alors le temps dexcution de la question.
On pourra supposer pour simplifier que tous les index sont deux niveaux et on ngligera les temps de calcul.

754 BASES DE DONNES : OBJET ET RELATIONNEL

26. OPTIMISATION ET JOINTURES

(chapitre X)
Soit une base de donnes relationnelle compose des tables suivantes :
R3 (U1, U2, U3)
R2 (V1, V2)
R1 (T1)

U1 et V1 sont respectivement les cls uniques de R3 et R2. Tous les attributs sont des
entiers tirs alatoirement.

Question 1
On considre alors la question :
SELECT U2,V2
FROM R1, R2, R3
WHERE R3.U1 = R2.V2 AND R2.V1 = R1.T1 AND R3.U3 = 100.

Donnez tous les arbres relationnels effectuant les projections ds que possible permettant dexcuter cette question.

Question 2
Calculez le cot en nombre dentre-sortie des trois arbres effectuant la restriction
dabord dans le cadre dun SGBD relationnel implmentant les restrictions par
balayage et les jointures par parcours dindex ou boucles imbriques. On prcise quil
existe un index sur les cls U1 de R3 et V1 de R2 et pas dautre index. La taille de
chaque relation R1, R2 et R3 est respectivement r1, r2 et r 3. On supposera une distribution uniforme des valeurs dattributs. Le nombre de valeurs distinctes dun attribut
est obtenu par la fonction DIST (par exemple, DIST(U2) est le nombre de valeurs distinctes de U2). Ce nombre peut tre calcul.

Question 3
Mme question avec des jointures par hachage.

Question 4
Avec un algorithme par hachage ou par boucles imbriques, il est possible de commencer une jointure avant davoir fini la prcdente. Expliquez ces algorithmes dits
de type pipeline.
Dans quel cas est-il intressant dutiliser un algorithme de type pipeline ?

Question 5
On gnralise ce type de requtes N relations Rn, Rn-1,...R1. Donnez la forme gnrale dune requte. Calculez le nombre de plans possibles pour une telle requte.

Exercices 755

27. INDEX DE JOINTURES (chapitre X)

Soit deux relations U(U1, U2, ) et V(V1, V2, ). Afin dacclrer les qui-jointures de U et V sur les attributs U1 et V1, on propose de grer un index de jointures.
Celui-ci peut tre vu comme une relation UV(IDU, IDV) o IDU reprsente lidentifiant dun tuple de U et IDV lidentifiant dun tuple de V. Chaque tuple de UV donne
donc les identifiants de deux tuples de U et V qui appartiennent la jointure. Un identifiant est une adresse invariante qui permet de retrouver un tuple dune relation en
une entre-sortie. Afin de permettre un accs rapide aux tuples de UV partir des
identifiants des tuples de U ou de V, lindex de jointure est organis comme un fichier
grille (Grid file) sur les attributs IDU et IDV (cest--dire quil est organis par
hachage extensible multi-attributs sur IDU et IDV, ladresse de hachage tant obtenue
en tournant sur les bits des deux fonctions de hachage sur IDU et sur IDV).

Question 1
Proposez un algorithme en pseudo-code, utilisant au mieux lindex de jointure, permettant de rpondre la question (bta est une constante et il ny a pas dindex sur
V2) :
SELECT U.U2
FROM U, V
WHERE U1 = V1 AND V2 = beta

Calculez le cot en nombre dentre-sortie de cet algorithme en fonction des tailles de

U et de V (respectivement u et v tuples), de la slectivit de la jointure (j), de la taille
de lidentifiant (i octets), de la taille du paquet de hachage pour UV (1 paquet = 1
page de p octets) et du taux de remplissage moyen du paquet (dnot t).

Question 2
On suppose que le systme gre un index de U sur U1 et de V sur V1 la place de
lindex de jointure. Dtailler lalgorithme pour rpondre la question prcdente en
utilisant la jointure par index. Calculez le cot dune telle jointure. On prcise que :
1. le nombre doctets occups par chaque valeur de U1 ou U2 est dnot a ;
2. le nombre de valeurs distinctes de U1 est DIST(U1), celui de U2 est DIST(U2) ;
3. les index sont des arbres B+ deux niveaux (feuille + racine).
Comparer la solution index de jointure vue en 1.

756 BASES DE DONNES : OBJET ET RELATIONNEL

28. DU RELATIONNEL LOBJET

(chapitre XI)
Lhpital X a besoin de votre aide pour exprimer des requtes sur leur base de donnes. On rappelle le schma de leur base relationnelle :
SERVICE
SALLE
EMPLOYEE
DOCTEUR
INFIRMIER
MALADE
HOSPITALISATION
SOIGNE

(CODE-S, NOM-S, BATIMENT, DIRECTEUR)

(CODE-S, NUM-SALLE, SURVEILLANT, NB-LITS)
(NUM-E, NOM-E, PRENOM-E, ADR, TEL)
(NUM-D, SPECIALITE)
(NUM-I, CODE-S, ROTATION, SALAIRE)
(NUM-M, NOM-M, PRENOM-M, ADR, TEL, MUTUELLE)
(NUM-M, CODE-S, NUM-SALLE, LIT, DIAGNOSTIC)
(NUM-D, NUM-M)

En dfinissant le schma les hypothses suivantes ont t faites :

Les cls sont soulignes.
Un service possde deux cls, CODE-S et NOM-S.
Le directeur dun service est un docteur identifi par son NUM-D.
Le numro de salle est local un service (i.e., chaque service possde une salle
numro 1).
Un(e) surveillant(e) est un(e) infirmier(re) identifi(e) par son NUM-I.
Docteurs et infirmiers(res) sont des employs, NUM-D et NUM-I sont donc galement des NUM-E et les tuples correspondants doivent exister dans EMPLOYEE.
Un(e) infirmier(re) est affect(e) un service et un seul.
Les docteurs ne sont pas affects un service particulier.
La relation HOSPITALISATION ne concerne que les malades hospitaliss ltat
courant.
Un malade non hospitalis peut toujours tre suivi par son (ses) mdecin(s) comme
patient externe.

Question 1
Donnez en UML la dfinition dun schma objet quivalent cette base relationnelle.
Exprimez ce schma en ODL.

Question 2
Puisque DOCTEUR et INFIRMIER sont des EMPLOYEE, proposez un nouveau
schma objet utilisant lhritage pour la base hospitalire.

Exercices 757

Question 3
Exprimez en OQL la requte suivante : Nom et prnom des cardiologues soignant un
malade Parisien (dont ladresse contient Paris) dans le service de Chirurgie gnrale.

Question 4
Essayez de simplifier le schma objet en introduisant des attributs multivalus.
Proposez des requtes OQL utilisant des collections dpendantes.

29. BD OBJETS (chapitre XI)

La socit REVE dsire informatiser la gestion des pres nol. Pour cela, elle a acquis
un SGBD objet ou objet-relationnel, supportant le langage OQL ou SQL3 (au choix).
Lapplication est dcrite par les phases suivantes :
Toute personne est caractrise par un nom, un prnom, une date de naissance, et
une adresse compose dun nom de ville, dun numro et nom de rue, ainsi que
dune localisation gographique 2D (X,Y).
Les pres nol effectuent des tournes, au cours desquelles ils visitent des enfants.
Les pres nol sont des personnes (on ne peut mme plus rver), ainsi que les
enfants.
Une tourne est compose dune liste denfants visiter, chaque point correspondant un ou plusieurs enfants.
chaque tourne est affecte une hotte contenant des jouets tiquets par le nom et
ladresse des enfants. La socit enregistrera aussi le prix de chaque jouet.
La transaction Effectue_Tourne consiste parcourir une tourne et ajouter
chaque enfant visiter dans la tourne les jouets qui lui reviennent, par insertion
dans lassociation nomme possde.
Une bauche de schma UML de la base est reprsente page suivante.

Question 1
Discutez de lintrt de choisir un SGBD objet ou objet-relationnel. Effectuez un
choix.

Question 2
Compltez la reprsentation UML de la base en prcisant les cardinalits des associations.

758 BASES DE DONNES : OBJET ET RELATIONNEL

Personnes

PreNoel

Enfants

Effectue
Visite
Possde

Tourne
Distribue
Hte

Contient

Jouets

Question 3
Dfinir le schma de la base en C++. Bien lire le texte et la question 4 afin de prvoir
les structures et mthodes capables dy rpondre.

Question 4
crire des programmes C++ naviguant dans la base et rpondant aux requtes suivantes :
Q1 : Nom du pre nol qui vous a visit et prix total des jouets que vous avez reus
Nol (on suppose que vous tes un enfant).
Q2 : Distance parcourue par le pre nol Georges Gardarin et liste des jouets distribus.
U1 : Mettre jour la base par enregistrement dune nouvelle tourne pour un pre
nol donn.

30. BD OBJETS (chapitre XI)

Soit le schma entit / association page suivante.
Il correspond au suivi de pices entrant dans la composition de modles davion dune
compagnie aronautique. On remarque que cette association ternaire ne peut pas tre
dcompose car (1) une mme pice peut tre utilise dans plusieurs avions, (2) un ou
plusieurs ingnieurs sont responsables du suivi de cette pice et (3) le ou les ingnieurs responsables sont dfinis de faon diffrente pour chaque modle o une pice
particulire est utilise.

Exercices 759

M#

I#

Nom

...

Nom

...

Modle

Ingnieur

Suivi

Date

Pice
Rle
...
P#

Des.

...

Question 1
Proposez une reprsentation objet de ce schma en utilisant UML. Discutez les proprits de votre reprsentation. Donnez la dfinition en ODL correspondante.

Question 2
crire les mthodes ncessaires pour faire une affectation dune pice un modle
davion avec lindication de la liste des ingnieurs chargs du suivi. Les mthodes
seront crites en Smalltalk, C++ ou Java persistant (ODMG) ou en pseudo-code pour
ceux qui ne sont pas laise avec les concepts de lun de ces langages objet. Attention
lencapsulation.

Question 3
Certaines pices sont en fait des modules composs dautres pices ou dautres
modules. Proposez une modification du schma pour Pice.

Question 4
crire une mthode qui donne la liste de tous les ingnieurs impliqus dans le suivi
dun module, soit directement soit au titre dun composant. On pourra utiliser la
mthode prdfinie union de la classe gnrique Set qui prend un autre Set en
paramtre.

760 BASES DE DONNES : OBJET ET RELATIONNEL

31. ALGBRE DOBJETS COMPLEXES

(chapitre XI)
Une algbre dobjets complexes permet dexprimer des requtes sur une base de donnes objet sous forme dexpressions algbriques. Elle rsulte en gnral dune extension de lalgbre relationnelle.

Question 1
Rappelez les extensions ncessaires lalgbre relationnelle pour exprimer les
requtes objets. Proposez des exemples gnriques de requtes illustrant chaque
extension.

Question 2
Soit une succession de classes T1, T2, ...Tn relies par des associations [M-N] via des
attributs de rle nomms A, B, ...X, comme reprsent ci-dessous :
C1

*
A

C2

*
B

C3

*
C

...

Cn1

*
X

Cn

Quels algorithmes proposeriez-vous pour traiter efficacement la requte SQL3 de parcours de chemins :
SELECT *
FROM C1, C2, ... Cn
WHERE C1.A = OID(C2)
AND C2.B = OID(C3)
...
AND Cn-1.X = OID(Cn) ?

On pourra aussi exprimer cette requte en OQL.

32. ODMG, ODL ET OQL (chapitre XII)

On considre une base de donnes gographiques dont le schma est reprsent de
manire informelle ci-dessous :
REGIONS (ID CHAR(5), PAYS STRING, NOM STRING, POPULATION INT,
carte GEOMETRie)
VILLES (NOM STRING, POPULATION INT, REGION ref(REGIONS), POSITION
GEOMETRie)
FORETS (ID CHAR(5), NOM STRING, carte GEOMETRie)

Exercices 761

ROUTES (ID CHAR(4), NOM STRING, ORIGINE ref(VILLES), EXTREMITE

ref(VILLES), carte GEOMETRIE)

Cette base reprsente des objets RGIONS ayant un identifiant utilisateur (ID), un
pays (PAYS), un nom (NOM) une population et une carte gomtrique. Les objets
VILLES dcrivent les grandes villes de ces rgions et sont positionns sur la carte par
une gomtrie. Les forts (FORETS) ont un identifiant utilisateur, un nom et une gomtrie. Les routes (ROUTES) sont reprsentes comme des relations entre villes origine et extrmit ; elles ont une gomtrie.
Une gomtrie peut tre un ensemble de points reprsents dans le plan, un ensemble
de lignes reprsentes comme une liste de points ou un ensemble de surfaces, chaque
surface tant reprsente comme un ensemble de lignes (en principe fermes). Sur le
type GEOMETRIE, les mthodes Longueur, Surface, Union, Intersection et DRAW
(pour dessiner) sont dfinies.

Question 1
Proposez une dfinition du schma de la base en ODL.

Question 2
Exprimer les questions suivantes en OQL:
Q1. Slectionner les noms, pays, populations et surfaces des rgions de plus de
10 000 km2 et de moins de 50 000 habitants.
Q2. Dessiner les cartes des rgions traverses par la RN7.
Q3. Donnez le nom des rgions, dessiner rgions et forts pour toutes les rgions
traverses par une route dorigine PARIS et dextrmit NICE.

Question 3
Rappelez les oprations dune algbre dobjets complexes permettant dimplmenter
le langage OQL. Donnez les arbres algbriques correspondants aux questions Q1, Q2
et Q3.

33. SQL3 (chapitre XIII)

On considre une base de donnes compose des entits lmentaires suivantes (les
cls sont soulignes lorsquelles sont simples) :
CLIENT
NoCl = Numro du client,
Nom = Nom du client,

762 BASES DE DONNES : OBJET ET RELATIONNEL

Rue = Numro et rue du client,

Ville = Ville dhabitation du client,
CP = Code postal du client,
Rgion = Rgion dhabitation du client.
FOURNISSEUR
NoFo = Numro du fournisseur,
Nom = Nom du fournisseur,
Rue = Numro et rue du fournisseur,
Ville = Ville dhabitation du fournisseur,
CP = Code postal du fournisseur,
Rgion = Rgion dhabitation du fournisseur.
COMMANDE
NoCo = Numro de commande,
NoCl = Numro du client,
Date = Date de la commande,
Resp = Nom du responsable de la suivie de la commande.
LIGNE
NoCo = Numro de commande,
NoPro = Numro du produit,
NoLi = Numro de ligne dans la commande,
Qtt = Quantit de produit command,
Prix = Prix total Toutes Taxes Comprises de la ligne,
PRODUIT
NoPro = Numro du produit,
Nom = Nom du produit,
Type = Type du produit,
PrixU = Prix unitaire Hors Taxe,
NoFo = Numro du fournisseur.

On se propose dtudier le passage en objet-relationnel de cette base de donnes et

linterrogation en SQL3. Pour cela, les questions suivantes seront considres :
a) Noms, types des produits et adresses des fournisseurs offrant ces produits.
b)Noms des clients ayant command un produit de type Calculateur .
c) Noms des fournisseurs et des clients habitant une rgion diffrente, tels que le fournisseur ait vendu un produit au client.
d)Chiffre daffaires toutes taxes comprises (somme des prix TTC des produits commands) de chacun des fournisseurs.

Question 1
Proposez un schma UML pour cette base de donnes. On ajoutera les mthodes
appropries pour illustrer. On supprimera tous les pointeurs cachs (cls de jointures)
qui seront remplacs par des associations. Dfinir ce schma directement en SQL3, en
utilisant des rfrences et des collections imbriques.

Exercices 763

Question 2
Exprimer en SQL3 les questions (a), (b), (c) et (d).

Question 3
Comparer limplmentation objet-relationnelle avec une implmentation directe en
relationnel.

Question 4
Reprendre les questions 1, 2 et 3 en utilisant ODL et OQL la place de SQL3.
Comparer les solutions.

34. INTERROGATION DOBJETS

(chapitres XII, XIII et XIV)
Reprendre la base de donnes de la socit RVE concernant les pres nol, vue cidessus.

Question 1
Dfinir cette base en ODL puis en SQL3.

Question 2
Exprimer les requtes suivantes en OQL puis SQL3 :
Q1 : Nom du pre nol qui vous a visit et prix total des jouets que vous avez reu
Nol (on suppose que vous tes un enfant).
Q2 : Distance parcourue par le pre Nol Georges Gardarin et liste des jouets distribus.

Question 3
Pour chacune des questions prcdentes, proposez un arbre algbrique optimis permettant de lexcuter.

Question 4
Rappelez la dfinition dun index de chemin. Proposez deux index de chemins permettant dacclrer lexcution des questions Q1 et Q2.

764 BASES DE DONNES : OBJET ET RELATIONNEL

35. OPTIMISATION DE REQUTES OBJET

(chapitre XIV)
Soit la base de donnes objet dont le schma est reprsent ci-dessous. Elle modlise
des compagnies dont les employs sont des personnes. Ceux-ci possdent 0 N vhicules. Les doubles flches reprsentent des attributs de liens de type listes de pointeurs.
Compagnies
numro
nom
employs

Personnes
nss
nom
vhicules

Voitures

date_nais

nveh

* age()

marque
couleur

Question 1
Exprimer en OQL les questions suivantes:
Q1: ensemble des numros de scurit sociale et noms de personnes ges de plus
de 40 ans possdant au moins un vhicule de couleur rouge.
Q2: liste des noms de compagnies employant des personnes de plus de 40 ans possdant une voiture rouge.

Question 2
Donnez un arbre doprations dalgbre dobjets complexes optimis par heuristique
simple permettant dexcuter la question Q2.

Question 3
La jointure de deux classes C1 et C2, telles que Personnes et Voitures relies par une
association oriente multivalue du type A>>C1 peut tre ralise par un algorithme de parcours de pointeurs ou de jointure sur comparaison didentifiant clas-

Exercices 765

sique. Nous les appellerons jointure avant JV (par pointeur) et jointure arrire
JR (par valeur). Dtailler ces deux algorithmes en pseudo-code.

Question 4
On constate que la jointure de N classes relies par des associations peut tre ralise
par un seul oprateur de jointure n-aire, traversant le graphe en profondeur dabord,
appel ici DFF. Dtailler cet algorithme en pseudo-code.

Question 5
En dnotant page(Ci) et objet(Ci) le nombre respectif de pages et dobjets dune
classe Ci, par fan(Ci,Cj) le nombre moyen de pointeurs par objet de Ci vers Cj, en
supposant un placement squentiel sans index des objets, calculez le cot de chacun
des algorithmes JR, JV et DFF. On pourra introduire dautres paramtres si ncessaire.

36. RCURSION ET ALGBRE

RELATIONNELLE (chapitre XV)
Soit le schma relationnel suivant :
PERSONNE (NUMRO, NOM, PRNOM, EMPLOI, PRE, MRE)

PRE et MRE sont des cls trangres sur la relation PERSONNE elle-mme, ce
sont donc des numros de personne. Cette relation permet donc de reprsenter un
arbre gnalogique complet.

Question 1
Donnez larbre algbrique correspondant la requte : Quels sont les enfants de M.
Martin, de numro 152487.

Question 2
Donnez larbre algbrique correspondant la requte : Quels sont les petits enfants de
M. Martin, de numro 152487.

Question 3
Donnez larbre algbrique tendu correspondant la requte : Quels sont les descendants de M. Martin, de numro 152487.
Pour cette dernire question on tendra les arbres algbriques de la faon suivante :
Un nud supplmentaire de test permettra de spcifier un branchement conditionnel ;

766 BASES DE DONNES : OBJET ET RELATIONNEL

Une boucle dans larbre sera autorise ;

Un test pourra porter sur le rsultat de lopration prcdente, par exemple (rsultat
= vide ?).
Attention la condition darrt du calcul.

37. DATALOG ET MTHODES NAVES

(chapitre XV)
PARTIE 1
Soit le programme DATALOG :
p1(X,X) p2(X,Y)
p2(X,Y) p3(X,X), p4(X,Y)
et la base de donnes :
p3(a,b), p3(c,a), p3(a,a), p3(c,c), p4(a,d), p4(a,b), p4(b,c), p4(c,a).

Question 1
Donnez une expression relationnelle quivalente ce programme pour le calcul des
faits instances des prdicats p1(X,X) et p2(X,Y).

Question 2
Donnez les faits instancis de symbole de prdicat p1 dduits de ce programme et de
la base de donnes.

PARTIE 2
Soit le programme DATALOG :
anc(X,Y) par(X,Y)
anc(X,Y) anc(X,Z), par(Z,Y)
la base de donnes :
par(baptiste,lon), par(lon,lucie), par(janine,lon), par(tienne,clo),
par(lucie,clo), par(baptiste,pierre), par(janine,pierre), par(pierre,bernard),
par(bernard,nicolas), par(bernard,lucien), par(bernard,nomie), par(lucien,ric).

Exercices 767

et la requte :
? anc(bernard,Y)

Question 1
Calculez les rponses cette requte en appliquant la mthode nave. Donnez les faits
dduits chaque itration.

Question 2
Mme question avec la mthode semi-nave.

Question 3
crire le programme modifi obtenu par la mthode des ensembles magiques.
valuez ce programme modifi sur la base, en montrant chaque itration les faits
dduits, et en prcisant pour chaque fait dduit, par quelle rgle il a t dduit.

38. OPTIMISATION DE RGLES LINAIRES

(chapitre XV)
On considre la base de donnes relationnelles :
EMPLOYE (NSS, NSER, NOM, SALAIRE)
SERVICE (NSER, NCHEF)

NSS est le numro de scurit sociale de lemploy, NSER son numro de service et
NCHEF le numro de scurit sociale du chef.

Question 1
crire un programme DATALOG calculant la relation :
DIRIGE(NSSC, NSSD)

donnant quel employ dirige directement ou indirectement quel autre employ (le
numro de scurit sociale NSSC dirige le numro de scurit sociale NSSD), ceci
pour tous les employs.

Question 2
Transformer le programme DATALOG obtenu la question 1 en appliquant la
mthode des ensembles magiques pour trouver les employs dirigs par Toto.

Question 3
Modifier le programme trouv la question 1 pour calculer la relation
DIRIGE(NSSC, NSSD, NIVEAU)

768 BASES DE DONNES : OBJET ET RELATIONNEL

NIVEAU est le niveau hirarchique du chef (1 chef direct, 2 chef du chef direct, etc.).
Dans quel cas ce programme a-t-il un modle infini ?

Question 4
Donnez le graphe Rgle-But et le graphe doprateurs relationnels correspondant la
question ? DIRIGE(Toto, x, 2) pour le programme trouv en 3.

Question 5
crire en DATALOG avec ensemble la question permettant de calculer la table
STATISTIQUE (NSER, CHEF, SALMAX, SALMIN, SALMOY)

donnant pour chaque service, le nom du chef, le salaire maximum, le salaire minimum
et le salaire moyen, ceci pour tous les services dont le salaire minimum dpasse
7 000 F.

39. DATALOG ET RGLES REDONDANTES

(chapitre XV)
Soit une base de donnes relationnelle compose de trois relations binaires B1, B2 et
B3. Le but de lexercice est doptimiser le programme DATALOG suivant pour une
question prcisant le premier argument de R :
R(x,y) B1(x,y)
R(x,y) B3(x,z),R(z,t), B2(t,u), R(u,y)
R(x,y) R(x,v), B3(v,z), R(z,t), B2(t,u), R(u,y)
On considre donc la question ? R(a,y), o a est une constante.

Question 1
En utilisant les ensembles magiques, donnez le programme de rgles transformes
permettant de calculer la rponse cette question.

Question 2
Simplifier le programme obtenu par limination des rgles redondantes. Peut-on proposer une mthode gnrale permettant dviter de transformer des rgles
redondantes ?

Exercices 769

40. DATALOG ET OBJETS (chapitre XV)

On considre une base de donnes dcrivant des lignes de chemins de fer dont le
schma est reprsent figure 1. Cette base reprsente des objets VILLES ayant nom
(NOM) une population (POPULATION) et une carte gomtrique (PLACE). Certains
objets villes sont relis par des tronons de voies ferres de type 1 (normal) ou 2
(T.G.V.) reprsents par une gomtrie et ayant une longueur (LONG) exprime en
km. On prcise que lidentifiant de tout objet est obtenu par la mthode OID() ; celleci peut donc tre vue comme un attribut implicite calcul au niveau de chaque classe.
CLASS VILLES (NOM STRING, POPULATION INT, PLACE GEOMETRIE)
CLASS TRONCONS (ID CHAR(4), TYPE INT, ORIGINE Obj(VILLE),
EXREMITE obj(VILLE), CARTE GEOMETRIE)

Une gomtrie peut tre un ensemble de points reprsents dans le plan, un ensemble
de lignes reprsentes comme une liste de points ou un ensemble de surfaces, chaque
surface tant reprsente comme un ensemble de lignes (en principe fermes). Sur le
type GEOMETRIE, les mthodes LONG, UNION, INTERSECTION et DRAW (pour
dessiner) sont dfinies. LONG est suppose calculer la longueur dune gomtrie en
km.

Question 1
Donnez un programme DATALOG avec fonctions (utiliser en particulier les fonctions
OID et DRAW) permettant de gnrer et tracer tous les parcours allant de la ville de
nom A la ville de nom B en parcourant moins de K km.
Discutez de loptimisation de ce programme.

Question 2
On dsire calculer le cot dun billet de train. Le cot est proportionnel au nombre de
km parcourus. Il existe des billets normaux, des billets rduits, des billets T.G.V., et
des billets T.G.V. rduits. La majoration sur les lignes T.G.V. est un cot de rservation initial plus un cot proportionnel la longueur du trajet. La rduction est un pourcentage du prix appliqu au seul cot proportionnel la distance parcourue. Proposez
une organisation en classes et sous-classes pour les billets de train. Programmer en
pseudo C++ une mthode TARIF qui calcule le prix de chaque billet. On prcise quil
est possible dappeler une mthode dune classe (qui peut tre une super-classe) par la
syntaxe classe::mthode ().

Question 3
Proposez une intgration de la mthode TARIF dans le programme ralis la question 1 afin de calculer le prix de chaque itinraire de moins de x km permettant daller
de A B et de choisir le moins coteux.

770 BASES DE DONNES : OBJET ET RELATIONNEL

41. CONTRLE DE CONCURRENCE

(chapitre XVI)
Soit une base compose de 4 granules A, B, C, D et une excution de 6 transactions
T1 T6. Les accs suivants ont t raliss sur les granules (Ei signifie criture par la
transaction i et Lj lecture par la transaction j du granule indiqu) :
A
B
C
D

:
:
:
:

E2
L2
E5
L6

E3
L4
L1
L2

L5
L1
L3 E4
E3

Question 1
Dessiner le graphe de prcdence. Que peut-on en conclure ?

Question 2
On suppose que les demandes se font dans lordre global suivant :
E2(A) L2(B) L6(D) E5(C) E3(A) L5(A) L1(C) L2(D) L3(C) E4(C) E3(D)
L4(B) L1(B)

Aucune transaction na relch de verrous. Lalgorithme utilis est le verrouillage

deux phases. Donnez le graphe dattente. Que se passe-t-il ?

Question 3
On rappelle que pour lalgorithme destampillage multiversion, les accs doivent tre
effectus dans lordre des estampilles des transactions, sauf les lectures qui peuvent se
produire en retard. Une lecture en retard obtient la version quelle aurait d lire si elle
tait arrive son tour. Les critures en retard provoquent par contre un abandon de
transaction.
Toujours avec lordre des accs de Q2, que se passe-t-il en estampillage multiversion ?

Question 4
Pour grer le multiversion on suppose que lon dispose dune table en mmoire pouvant
contenir 100 000 versions avec les estampilles correspondantes (pour lensemble des granules). De plus on conserve sur disque la dernire version produite de chaque granule.
On se propose de modifier lalgorithme destampillage multiversion de la faon suivante : chaque nouvelle version dun granule mis jour est crite sur disque tandis
que la version prcdente est recopie dans la table en mmoire. Cette table est gre
comme une file circulaire : chaque nouvelle version entre chasse la version la plus
ancienne (tous granules confondus). Lors dune lecture on recherche dans la table (ou

Exercices 771

sur disque) la version ncessaire si elle est disponible. Une lecture peut donc chouer
et conduire un abandon.
Donnez en pseudo-code les algorithmes LIRE et CRIRE correspondants.

42. CONCURRENCE SMANTIQUE

(chapitre XVI)
Soit une classe C++ persistante Rel dfinie comme suit :
Class Rel: Pobject {
private:
Rel Valeur;
public:
operator+;
operator*}.

Les actions de base indivisibles pour le contrle de concurrence tudier sont les oprations sur objets, cest--dire + et * sur lexemple.
On considre trois transactions travaillant sur des rels nomms A et B :
T1: { A+1 -> A; B+1 -> B }
T2: { A+2 -> A: B+2 -> B}
T3: { A*3 -> A: B*3 -> B}

Question 1
Donnez un exemple dexcution simultane des transactions T1 et T3 non srialisable.
Tracer le graphe de prcdence associ.

Question 2
Montrer que la commutativit de lopration daddition garantie la correction de toute
excution simultane de T1 et T2.

Question 3
La commutativit des oprations permet donc daccepter des excutions simultanes
non priori srialisable. On se propose de munir chaque classe persistante dun
contrleur de concurrence utilisant une matrice de commutativit des oprations et un
vecteur doprations en cours par transaction.
Dfinir les primitives ncessaires un tel contrle de concurrence.
Prciser les algorithmes sous-jacents.

772 BASES DE DONNES : OBJET ET RELATIONNEL

43. TRANSACTIONS (chapitre XVI)

Soit le programme suivant crit en C avec des requtes SQL imbriques (ESQLC de
INGRES) :
#include <stdio.h>;
main (){
exec sql
begin declare section;
char nombase [20];
char instr [150];
exec sql
end declare section;
int i;
char rep;
printf (Nom de la base : );
scanf (%s, nombase);
exec sql whenever sqlerror stop;
exec sql connect :nombase;
exec sql whenever sqlerror goto erreur;
for (i=1, rep = O; rep = O; i++){
printf (\n\n Instruction %d : , i);
scanf (%s, instr);
exec sql execute immediate :instr;
exec sql commit;
suite :
printf (\n\n Encore ?);
scanf (%c, &rep);
}
printf (\n\n Au revoir ...);
exec sql disconnect;
return;
erreur :
exec sql whenever sqlerror continue;
Affic_Erreur ();
procdure de gestion des erreurs
exec sql rollback;
exec sql whenever sqlerror goto erreur;
goto suite;
}

Question 1
Que fait ce programme ? Prcisez le dbut et la fin de la (des) transaction(s).

Question 2
Que se passe-t-il si on supprime linstruction exec sql commit ?

Question 3
Prcisez les effets du rollback.

Exercices 773

Question 4
On lance plusieurs instances simultanes du programme prcdent. Une transaction ne
peut pas lire (et encore moins modifier) les donnes mises jour par une transaction
non valide. Pourquoi ?
Prcisez les complications des procdures de reprise quimpliqueraient la leve de
cette limitation, cest--dire le non respect de la proprit disolation des mises jour.

44. VALIDATION DE TRANSACTIONS

(chapitre XVI)
Soit la base de donnes issue du banc dessai TPC/A dont le schma entit-association
est reprsent ci-dessous (en UML) :
Agences
Numro

Comptes
*

Numro

Ville

IdClient

Avoir

Avoir

*
Caissiers

Comptes

Numro

Numro

Ville

IdClient

Avoir

Avoir

Lobjectif de ltude est dtudier la rsistance aux pannes dans un contexte centralis
puis rparti sur une telle base de donnes implmente en relationnel.

Question 1
Donnez le schma relationnel de la base. crire le code de la transaction dbit/crdit
sous la forme de requtes SQL.

Question 2
Le systme dmarre aprs un point de reprise et excute quatre instances de la transaction dbit/crdit notes T1, T2, T3, T4. T1 crdite 1 000 F sur votre compte avec

774 BASES DE DONNES : OBJET ET RELATIONNEL

succs. T2 tente de crditer 2 000 F mais choue, T3 crdite 3 000 F avec succs et T4
dbite 4 000 F avec succs. Donnez le format du journal (images aprs et avant
comme dans ARIES) aprs excution de ces quatre transactions.
Ce journal est gr en mmoire. Quand est-il crit sur disque ?

Question 3
Le systme tombe en panne aprs validation (commit) de T4. Que se passe-t-il lors de
la procdure de reprise ?

Question 4
Chaque agence bancaire possde un serveur grant sa base de donnes. crire le code
dune transaction sexcutant depuis un client C et effectuant le transfert de m francs
depuis un compte dune agence A sur le compte dune agence B. Prciser les messages changs entre client et serveurs dans le cas dexcution avec succs dune telle
transaction, puis dans le cas o le site A ne rpond plus lors de la premire phase du
commit.

Question 5
Le site client lance la transaction de transfert qui est bien excute sur A et B.
Malheureusement, le site client se bloque juste avant lenvoi de la demande de validation (COMMIT). Prciser ltat du systme (messages changer et journaux). Que se
passe-t-il alors ?
Afin de sortir des situations de blocage, proposez une extension au protocole de validation deux phases en ajoutant une phase et en introduisant un tat intermdiaire
basculant automatiquement en chec de la transaction aprs un dlai dattente.

45. GESTION DES AUTORISATIONS

(chapitre XVI)
Lorsquun usager cre une relation, tous les droits (lecture, insertion, suppression,
modification) lui sont accords sur cette relation. Cet usager a galement le droit de
transmettre ses droits dautres usagers laide de la commande GRANT. Un usager
ayant transmis des droits un autre peut les lui retirer par la commande REVOKE.

Question 1
crire la commande permettant de transmettre les droits de lecture et insertion sur la
relation VINS lusager FANTOMAS, en lui garantissant le droit de transmettre ces
droits.

Exercices 775

crire la commande permettant de supprimer le droit prcdent.

Question 2
Afin de rendre plus souple lattribution de droits, on introduit la notion de rle.
Prcisez les commandes ncessaires la gestion des rles.

Question 3
Les droits donns aux usagers sont mmoriss dans une relation DROITS. Proposez
un schma pour la relation DROITS.

Question 4
Dcrivez en quelques lignes ou par un organigramme les principes des algorithmes
daccord de droit (GRANT), de suppression de droits (REVOKE) et de vrification dun
droit.

46. NORMALISATION DE RELATIONS

(chapitre XVII)
PARTIE 1
Soit la relation R (A, B, C, D, E, F, G, H) avec la liste de dpendances fonctionnelles
suivantes :
DF = { AB, AC, DE, FA, FC, FG, ADC, ADH }

Question 1
Proposez une couverture minimale DF pour DF.

Question 2
Dessiner le graphe des dpendances fonctionnelles.

Question 3
Proposez une dcomposition en troisime forme normale pour R.

PARTIE 2
Soit la liste suivante de donnes lmentaires utilises pour construire une base de
donnes Commandes :

776 BASES DE DONNES : OBJET ET RELATIONNEL

NUMCOM : numro de commande

Identifiant unique

DATECOM : date de la commande

NUMCLI : numro de client

Identifiant unique

NOMCLI : nom du client

Doubles possibles

ADCLI : adresse client

Doubles possibles

NOMVEND : nom du vendeur

Identifiant unique du vendeur

qui passe la commande

NUMPRO : numro du produit

Identifiant unique

NOMPRO : nom du produit

Doubles possibles

PRIX : prix unitaire produit

QTE : quantit commande dun produit
MONTANT : montant pour la quantit
commande du produit
TOTAL : prix total commande

Montant total de la commande

pour tous les produits commands

On suppose que lon commence par former une unique relation Commandes avec les
donnes prcdentes pour attributs.

Question 1
Proposez une liste de dpendances fonctionnelles entre ces attributs en respectant les
hypothses.

Question 2
Dessiner le graphe des dpendances fonctionnelles en utilisant des arcs en traits pleins
pour la couverture minimale et des arcs en pointill pour ceux qui peuvent se dduire
par transitivit.

Question 3 :
Proposez une dcomposition en troisime forme normale de la relation.

Exercices 777

47. INTGRIT DES BD OBJETS

(chapitre XVII)
Soit le schma de base de donnes objet suivant, donn dans un langage proche de
C++ utilisant une dfinition de classe de grammaire CLASS <nom de classe>
{ [<type> <nom dattribut>] }, un type pouvant tre simple (exemple: integer) ou
complexe (exemple: SET<>). Le constructeur de collection SET est utilis pour
prciser un ensemble dobjets du type indiqu entre crochets (exemple
SET<PISTE*> dsigne un ensemble de rfrences des pistes).
CLASS STATION { CHAR(20) NOMS, INTEGER ALTITUDE,
INTEGER HAUTEUR_NEIGE, SET<PISTE*> PISTES,
CHAR(10) REGION, CHAR(10) PAYS}
CLASS PISTE{ CHAR(12) NOMP, INTEGER LONG,
INTEGER DENIVELEE, SET<BOSSE*> DIFFICULTES}
CLASS BOSSE { INTEGER POSITION, CHAR CATEGORIE}

On prcise que:
1. Il nexiste pas deux stations de mme nom (NOMS)
2. Une rgion appartient un pays unique.
3. ALTITUDE et HAUTEUR_NEIGE sont dtermins par le nom de station NOMS.
4. Deux pistes de stations diffrentes peuvent avoir le mme nom.
5. Une piste dans une station possde une longueur et une dnivele unique.
6. La position dune bosse la dtermine de manire unique sur une piste donne.

Question 1
En considrant chaque classe, donnez le graphe des dpendances fonctionnelles entre
attributs. Ajouter au graphe des arcs reprsentant les dpendances hirarchiques de 1
vers N reprsents par des arcs tte multiple (du style ->>). Complter ce graphe
par les dpendances interclasses fonctionnelles ou hirarchiques.

Question 2
partir du graphe prcdent, dduire un schma relationnel en 3e forme normale permettant de reprsenter la base de donnes objet initiale.

Question 3
Prciser les contraintes dunicit de cl du schma relationnel. Spcifier ensuite les
contraintes rfrentielles permettant dimposer lexistence dune station pour insrer
une piste puis lexistence dune piste pour insrer une bosse.

778 BASES DE DONNES : OBJET ET RELATIONNEL

Question 4
Proposez un langage de dfinition de contraintes permettant dexprimer les mmes
contraintes dans le monde objet. Illustrez sur la base objet initiale.

48. CONCEPTION COMPLTE DUNE BD

(chapitre XVII)
Lassociation (fictive) des Amateurs de Vins de Monde Entier (AVME) est une organisation a but non lucratif dont le but principal est de promouvoir lentente entre les
peuples par lchange et la promotion des meilleurs vins du monde entier. Ses
membres sont principalement des dgustateurs professionnels et des amateurs clairs
(qui bien sr dgustent aussi). Ils dsirent constituer une base de donnes recensant
les vins, les dgustateurs (les membres) et tous les vnements de dgustations. Ils ont
demand votre aide pour la conception du schma relationnel, qui ne doit prsenter ni
anomalie ni redondance. La liste des donnes lmentaires qui doivent figurer dans la
base est la suivante :
NUM_VIN
Numro dun vin
NUM_PRO
Numro dun producteur de vin
PRODUCTEUR Par exemple Chteau Talbot ou Burgess Cellars
DESIGNATION Dsignation additionnelle pour un vin, comme Rserve
MILLESIME
Anne de production dun vin
CEPAGE
Comme Cabernet-Sauvignon ou Chardonnay
NOTE_MOY
Note moyenne dun millsime dun vin
PAYS
Pays dorigine
REGION
Grande rgion de production, comme Californie aux
USA, Rioja en Espagne ou Bourgogne en France
CRU
Petite rgion de production dont les vins ont un caractre
marqu, comme Napa Valley ou Haut-Mdoc
QUALITE
Qualit moyenne dun cru pour un millsime
NUM_MEM
Numro dun membre
NOM
Nom dun membre
PRENOM
Prnom dun membre
DATE
Date dun vnement de dgustation
LIEU
Lieu dun vnement de dgustation
NOTE
Note attribue un millsime dun vin par un dgustateur
(membre) lors dun vnement dgustation
RESP_REG
Membre responsable dune rgion viticole

Exercices 779

titre dexplication et/ou de simplification on notera que :

les dgustations se font lors dvnements mettant en jeu de nombreux membres et
de nombreux vins ;
il ny a jamais deux vnements de dgustation la mme date ;
un mme vin est got de nombreuses fois lors dun vnement et reoit une note
pour chaque dgustateur qui la got, un dgustateur ne gotant pas tous les vins ;
deux rgions de production nont jamais le mme nom ;
un mme vin donne lieu plusieurs millsimes (un par an) et tous les vins de la
base sont des vins millsims ;
le producteur est le mme pour tous les millsimes du mme vin.

Question 1
Donnez la liste des dpendances fonctionnelles non triviales entre donnes lmentaires sous la forme dun graphe. Sassurer quil ne reste aucune dpendance fonctionnelle qui puisse se dduire des autres par transitivit (les enlever sil en reste).

Question 2
Proposez un schma normalis en 3FN pour la base DGUSTATION partir de
lensemble des dpendances fonctionnelles et laide de lalgorithme vu en cours.

Question 3
Exprimez en SQL les requtes suivantes sur le schma propos :
a) Quels sont les vins de 1991 de la rgion du Pimont (en Italie) qui ont reu au
moins une note suprieure 17 lors de la dgustation du 14/05/1994 ?
b)Quelle est la note moyenne dcerne tous vins confondus par chaque membre
(dgustateur) ?
c) Quels sont les crus qui nont pas reu de note infrieure 15 pour le millsime 1989 ?
d)Quels sont les dgustateurs qui ont particip tous les vnements ?

Question 4
Donnez une expression des requtes a) c) et d) en algbre relationnelle (en utilisant de
prfrence la notation graphique vue en cours).

Question 5
Proposez un schma physique pour le schma relationnel prcdent. On suppose que
lon peut placer en squentiel (avec index primaire non plaant), par des index primaires plaant de type arbre B+ ou par hachage classique. Choisir un mode de placement pour chaque relation en le justifiant.

780 BASES DE DONNES : OBJET ET RELATIONNEL

Question 6
Proposez les index secondaires les mieux mme dacclrer la manipulation de la
base. Indiquer les organisations dindex retenues dans chaque cas et donner les justifications des choix raliss.

TRANSPARENTS
Pour chacun des chapitres, une srie de transparents peut tre obtenue pour lenseignement public en contactant le site Web du laboratoire PRiSM de luniversit de
Versailles :
www.prism.uvsq.fr/~gardarin/home.html

INDEX
A
acteur, 448
action, 269, 591
administrateur, 30
dapplication, 30
dentreprise, 30
de bases de donnes, 30
de donnes, 16, 30
adressage ouvert, 75
adresse relative, 66
affinement du schma logique,
662
agrgat, 210
agrgation 21, 668, 369, 670
composite, 668, 676
indpendante, 668, 675
agrgats auto-maintenables,
295
algorithme
dunification, 169
gntique, 501, 503
amlioration itrative, 343,
497, 498
analyseur
de rgles, 266
de requtes, 43
annotation, 302
annulation de transaction, 619
anomalies de mise jour,680
aplatissage dune collection,
387
apparition dincohrence, 589
appel de mthodes, 572
approche
par synthse, 683
relationnelle tendue, 678

arbre
algbrique, 306
B, 85
B+, 88
de segments, 136
de traitement, 306
de versions dobjet, 642
ET/OU, 548
linaire droit ou gauche,
335
ramifi, 335
relationnel, 207
relationnel, 306
architecture
deux strates, 47
trois strates, 48
BD rpartie, 50
client-serveur, 45
rpartie, 50
article, 60, 61, 113
association, 21, 670
bijective, 673
atome, 113, 523
instanci, 523
atomicit des transactions, 37,
588
attribut multivalu, 676
attribut, 22, 182, 356, 663
attribution de droits, 648
authentification, 644
autorisation, 646

B
balayage squentiel, 326
base cohrente, 254
base de donnes
active, 264, 248

dductive, 154
hirarchique, 137
logique, 154
blocage, 67
permanent, 607
boucles imbriques, 330

C
cache volatile, 621
calcul relationnel
de domaine, 157
de tuples, 166
capture des besoins, 662
cardinalits dassociation, 665
catalogue, 68
de base, 71
hirarchis, 69
certification de transaction,
614
chanage, 75
arrire, 543
avant, 542
champ, 136
classe, 358, 670
de base, 362
drive, 362
gnrique, 367
paramtre, 367
clause, 151
de Horn, 152
cl, 63,136, 185
base de donnes, 122, 123
candidate, 689
darticle, 63
de relation, 689
primaire, 100, 186, 689
prive, 650

784 BASES DE DONNES : OBJET ET RELATIONNEL

publique, 650
secondaire, 100
secrte, 649
clich, 294
cohrence, 588
de contraintes, 254
collection, 367
dpendante, 418
compactage, 67
complment, 200, 201
comptage magique, 570
concatnation darbre, 286,
287
conception du schma
logique, 662
concurrence daccs, 374
condition, 269
de dclencheur, 269
de rgle, 523
conflits de noms, 364
connecteurs logiques, 523
consquence immdiate, 529
constante, 225, 523
de Skolem, 152
constructeur, 448
dobjet, 375
contexte dun vnement,
268
contrainte
dentit, 188
dintgrit, 37, 247
dunicit de cl, 37
de colonnes, 220
de comportement, 250
de domaine, 37, 189, 249
de non nullit, 250
de relations, 220
quationnelle, 251
redondante, 255
rfrentielle, , 37, 187,
249
structurelle, 249
temporelle, 251
contrleur de requtes, 43
coordinateur de validation,
628
corps de rgle, 523
correction des transactions,
38

couverture minimale, 688

cration dobjets, 572
croisement, 502
curseur, 129, 235

D
DATALOG, 522
avec double ngation
avec ensemble, 539
avec fonction , 537, 538
avec ngation, 533
dclencheur, 38, 248, 264
dcomposition, 682, 686
prservant
les dpendances, 693
sans perte, 683
dfinition
de classe, 407
de littral , 408
degr disolation, 600
dgroupage, 385, 386, 539
dune collection, 386
dmarche objet, 678
dnormalisation, 705
densit dun index, 83
dpendance
algbrique, 703
dinclusion, 251, 703
de jointure, 702
fonctionnelle lmentaire,
686
fonctionnelle, 250, 684
gnralise, 251
multivalue, 251, 700
multivalue lmentaire,
701
drivation
exclusive, 642
partage, 642
descripteur de fichier, 68
destructeur, 448
dobjet, 375
destruction
dobjets, 572
de valeurs, 572
dtachement, 320
dtection, 601
deuxime forme normale,
691

diagramme
de Bachman, 116
UML, 663
dictionnaire
de rgles, 266
des donnes, 30
diffrence, 191, 387
distribution des objets, 374
division, 199
domaine, 181
de discours, 150
donnes prives, 357
durabilit, 588

E
clatement, 201, 202
criture des clauses, 153
effet
domino, 610
net, 275
laboration
du schma conceptuel,
662
du schma physique, 662
limination
de duplicata, 387
des implications, 152
des quantificateurs, 152
encapsulation des donnes,
439
enregistrement de compensation, 637
ensemble, 367
entit, 21, 663, 672
entrept de donnes, 290,
714
quation au point fixe, 567
qui-jointure, 196
espace des plans, 340
estampille, 604
de transaction, 604
valuateur de conditions, 266
valuation
Bottom-up, 542
top-down, 544
vnement, 265, 267, 268
excuteur
dactions, 266
de plans, 43

Index 785

excution, 592
de transactions, 592
ensembliste, 307, 308
pipline, 308
srialisable, 595
expression
dactions, 535
dattributs, 209
de chemin, 383, 418
de chemin monovalu,
418
de chemins multivalue,
383
de mthodes, 383
fonctionnelle, 383
valuable, 382
extension, 185
de classe, 359, 407
de prdicat, 154
extraction dobjets, 419

F
facilit dinterrogation, 374
facteur de slectivit, 338
fait relevant, 531, 544
fermeture transitive, 204
fiabilit des objets, 374
fichier, 60
grille, 101, 102
hach statique, 73
index, 89
inverse, 100
squentiel index, 91
squentiel index
rgulier, 95
fonction
arguments ensemblistes,
566
de hachage, 74
membres, 357
forme normale
de boyce-codd, 696
de projection-jointure,
703
formule, 149
atomique, 149, 523
de Tang, 494
de Yao, 493
ferme, 151

G
gnralisation, 668, 362
gnration
nave, 556
semi-nave, 558
gestionnaire de fichiers, 4
granule, 67
dallocation, 68
de concurrence, 591
graphe
dhritage, 362
de connexion de
prdicats, 550
de connexion
des attributs, 311
de connexion
des relations, 310
de gnralisation, 362
de groupage, 474
de prcdence, 597
de propagation, 561
de stockage, 476
des allocations, 603
des appels de mthodes,
371
des attentes, 601
des dpendances
fonctionnelles, 686
des jointures, 310
rgle/but, 549
relationnel de rgles, 547,
548
groupage, 385, 474, 539
conjonctif, 475
dune collection, 386
disjonctif, 475
simple, 475
groupe, 113
groupement, 705
groupes dutilisateurs, 645

H
hachage, 73
extensible, 77
linaire, 79
hritage, 362
doprations
et de structures, 439

de table, 442
de type, 442
multiple, 364, 375
simple, 375
hypothse du monde ferm,
154, 532

I
identifiant
dobjet, 355
logique, 470
physique, 470
identification, 644
identit dobjet, 355, 375,
438
image
dune collection, 386
rciproque, 290
incohrence, 590
incorporation dobjet, 473
indpendance
logique, 60
physique, 60
index, 81, 82, 327
bitmap, 104
daires, 98
dintervalles, 97
index de chemin, 471
de chemin imbriqu, 472
de chemin simples, 471
hirarchis, 84
matre, 98
secondaire, 99
inqui-jointure, 196
insertion, 218
dans table dpendante,
262
de valeurs, 572
instance, 15, 185
dobjet, 15
intention, 184
interface dobjet, 357
interprtation dun langage
logique, 153
intersection, 198, 387
isolation des transactions, 38,
588

786 BASES DE DONNES : OBJET ET RELATIONNEL

J
jointure, 195
de collections, 387
externe, 202
naturelle, 196
par rfrence, 388
par valeur, 388
-projection, 320
journal des images
aprs, 622
avant, 622
journalisation
avant criture, 624, 637
de valeur et dopration,
635

L
label, 68
de volume, 68
langage
complet, 33, 206
de description de donnes
(LDD), 16
de rgles, 518
DEL, 573
hte, 61
ROL, 571
liaison, 473
dobjet, 473
dynamique, 367
lien, 115
liste, 367
littral positif, 523

M
manipulation de collections,
465
matrice dautorisations, 647
mmoire
un seul niveau, 382
secondaire, 57
stable, 620, 621
volatile, 623
message, 370
dexception, 375
mta-rgles, 535
mtabase, 31, 43

mthode, 357
daccs, 61
daccs slective, 63
daccs squentielle, 62
de dtection, 258, 259
de prvention, 259
de rsolution, 171
interprte, 564
virtuelle, 366
mise jour de colonne rfrenante, 262
mise en forme
normale conjonctive, 153
prenex, 152
mode
dexcution, 276
de couplage, 276
de synchronisation, 276
modle
analytique, 704
dactivits, 641
de description
de donnes, 16
de transaction volu,
374
ferm, 640
ouvert, 640
relationnel imbriqu, 439
simul, 704
modification, 218
de question, 286
de requte, 43
module, 236
modus ponens, 169
moniteur dvnements, 266
mot de passe, 644
moteur de rgles, 266
moyennage de cot, 494
multi-ensemble, 367
multi-index, 472
multiclasse, 361
mutateur, 448
mutation, 502
de pointeurs, 380

N
navigation entre objets, 380
ngation par chec, 528, 532
niveau dautorisation, 648

non premire forme normale,

439
non-reproductibilit des lectures, 590

O
objet, 354, 355, 644
versions, 374
long, 438
persistant, 374
transient, 374
versionnable, 374
observateur, 448
occurence, 15
ODL, 403
ODMG, 401
ODMG 2.0, 403
OML, 403
ontologie, 671
oprateur
de slection, 320
monotone, 532
opration, 35, 593, 644
compatible, 595
permutable, 594
prive, 358
optimisation
deux phases, 497
logique, 302
physique, 302
optimiseur
de requtes, 43
extensible, 481
ferm, 341
OQL, 403
ordonnancement par estampille, 613
organisation de fichier, 61

P
page, 66
panne
catastrophique, 634
dune action, 617
dune transaction, 617
de mmoire secondaire,
618
du systme, 618
paquetages, 669

Index 787

parcours de graphes, 570

partage rfrentiel, 356
participant validation, 628
partitionnement
horizontal, 706
vertical, 706
passage en premire forme
normale, 677
patron de collection, 441
pattern de classe, 367
persistance
des objets, 374
manuelle, 377
par atteignabilit, 430
par hritage, 377, 378
par rfrence, 378, 380
perte
dinformations, 680
de mise jour, 589
pipeline, 308
placement, 123
proximit, 123, 705
calcul, 123
CODASYL, 123
direct, 123
multi-attribut, 101
multi-attribut statique,
101
par homothtie, 123
plan dexcution, 302, 308
planning, 308, 309
plus petit modle, 528
point
de reprise systme, 625,
637
de validation, 630
polymorphisme, 366, 375,
465
post-test, 259
pr-test, 260
prcdence, 596
prdicat, 225
de comparaison, 156, 523
extensionnel, 156, 520
intensionnel, 520
relationnels, 523
prmisse de rgle, 523
prvention, 601
principe dencapsulation, 357

problme des fantmes, 607

procdure
de reprise, 631
stocke, 46
produit cartsien, 192
programme
confluent, 536
stratifi, 534
projection, 193
dune collection, 386
propagation dinformations,
561
protocole
daccs aux donnes
distantes, 45
de validation en deux
tapes, 628
Dfaire et Refaire (Undo,
Redo), 633
Dfaire sans Refaire
(Undo, No Redo), 634
Ni Refaire Ni Dfaire
(No Undo, No Redo),634
Refaire sans Dfaire (No
Undo, Redo), 633

Q
qualification, 32
de chemin, 140
de question, 32
quatrime forme normale,
700
question
contradictoire, 312
correcte, 312
irrductible, 322
mal formule, 312
questions quivalentes, 312

R
recherche, 218
taboue, 497, 500
recuit simul, 497, 499
redfinition, 366
rduction de la porte des
ngations, 152
rcriture, 308
smantique, 310
syntaxique, 310

rfrence dobjet, 442

rgion, 67
rgle, 523
champ restreint, 538
dinfrence de Robinson,
169
DATALOG, 523
de correspondance, 35
de production, 535
ECA, 265
fortement linaire, 568,
569
linaire, 524, 553, 563
quadratique, 524, 554
rectifie, 529
rcursive, 524
signe, 563
rehachage, 75
relation, 182
rcursive, 526
universelle, 681
reprise, 619
chaud, 632
froid, 634
de transaction, 619
granulaire oriente page,
635
partielle de transactions,
635
requte
chane, 487
dynamique, 305
statique, 305
rseaux de Petri prdicats,
550
rsolvant, 171
restriction, 194
rvlation de cot, 494
rle, 645, 665

S
sac, 367
sagas, 640
sauvegarde, 625
schma
conceptuel, 17, 20
de BD objet, 371
de classes, 371
de donnes, 16

788 BASES DE DONNES : OBJET ET RELATIONNEL

de relation, 184
externe, 18, 20
interne, 18, 20
segment, 136
slecteur de proprit, 371
slection, 388
dobjets, 386
smantique
bien fonde, 537
de la preuve, 527
des oprations, 611
du modle, 528
du point fixe, 530
inflationiste, 537
semi-jointure, 203, 322
srialisabilit, 595
SGBD
actif, 264
dductif, 521
externe, 5
interne, 4
signature, 563
simultanit inter-usagers,
63, 64
sous-but, 523
sous-classe, 362
sous-schma, 127
spcialisation , 169, 362, 668,
674
SQL2
complet, 238
entre, 238
intermdiaire, 238
stratgie
alatoire, 343
de recherche, 340
des frres siamois, 72
du meilleur choix, 72
du plus proche choix, 72
du premier trouv, 72
numrative, 343
exhaustive, 343
gntique, 343

par augmentation, 343

substitution, 320
succession, 595
sujet, 644
super-classe, 362
supercl, 689
support dobjets atomiques et
complexes, 375
suppression, 218
dans table matre, 263
surcharge, 366
systmes lgataires, 111

T
table
des pages sales, 636
des transactions, 636
support, 479
tableau, 367
de disques, 59
technique
de mmoire virtuelle, 381
des pages ombre, 627
terme, 149, 225, 523
test diffrentiel, 257
trane dune transaction ,
610
transaction, 586, 588
de compensation, 640
de complment, 640
multi-niveaux, 642
transactions imbriques, 639
transformation de donnes,
35
traverse
de chemin, 465
en largeur dabord, 479
en profondeur dabord,
478
tri externe, 329
troisime forme normale, 691
tuple, 183
tuple, 308

type
dobjet, 15
de donnes abstrait, 358,
441
de donnes utilisateur,
441

U
UML 668
UML/OR, 678
UML/RO, 678
unicit de cl, 249
unification, 169
union, 190, 387
unit duvre, 618
usine objets, 359
utilisation de doubles pointeurs, 381

V
valeur nulle, 188
validation aprs criture, 624,
637
validation bloque, 624
validation de transaction, 619
variable, 523
dinstance, 356
vecteur, 113
verrou
court, 600
long, 600
mortel, 600
verrouillage
altruiste, 610
deux phases, 598
multi-versions, 610
version dobjet, 374
volume, 58
vue, 25, 281, 283
auto-maintenable, 292
concrte, 291
mettable jour, 288

Mise en page : EDIE

N dditeur : 6917