Sie sind auf Seite 1von 826

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
dsig