Académique Documents
Professionnel Documents
Culture Documents
0b3fad PDF
0b3fad PDF
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.
Au sommaire
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
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
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 ............................................................................................................
4. BIBLIOGRAPHIE..........................................................................................................................................
10
13
1. INTRODUCTION...........................................................................................................................................
13
15
15
16
17
18
18
19
20
23
24
25
26
26
3.5.
3.6.
3.7.
3.8.
3.9.
27
28
28
28
29
29
30
32
33
35
37
37
38
39
39
42
44
45
45
49
7. CONCLUSION .................................................................................................................................................
50
8. BIBLIOGRAPHIE..........................................................................................................................................
51
55
1. INTRODUCTION...........................................................................................................................................
55
57
57
60
61
62
63
64
Sommaire XI
64
64
66
66
66
67
68
69
71
71
71
72
72
73
73
76
76
77
79
81
81
81
82
84
84
88
89
91
91
92
92
93
94
95
95
95
97
98
99
99
101
101
101
104
112
112
113
115
119
121
122
122
125
127
127
128
129
130
130
131
132
132
132
133
133
133
134
134
Sommaire XIII
148
148
150
151
156
156
157
158
168
168
169
170
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
185
185
186
188
188
189
190
190
191
192
193
193
194
195
198
198
199
200
201
202
203
204
Sommaire XV
219
219
220
221
222
222
223
223
224
226
227
228
230
230
232
232
233
233
234
234
235
236
238
238
239
239
240
241
242
242
242
249
249
250
251
254
254
255
256
258
258
259
262
262
262
263
263
264
264
264
266
267
267
268
269
269
269
270
270
271
271
271
272
273
273
274
275
276
Sommaire XVII
288
288
288
289
290
290
292
294
303
303
304
305
308
310
310
310
312
312
314
315
315
319
320
321
322
325
325
325
326
327
328
329
330
334
334
335
335
337
339
340
341
341
342
343
354
354
357
358
361
365
Sommaire XIX
373
373
375
377
378
380
382
382
385
386
387
388
389
390
391
392
401
402
403
404
406
406
408
409
409
410
410
412
412
413
414
417
417
418
419
419
420
420
427
427
428
429
429
430
430
430
431
431
421
421
422
422
422
423
423
424
424
425
426
427
427
Sommaire XXI
436
436
437
438
439
444
444
444
445
446
446
446
447
448
449
450
450
452
453
454
454
454
455
456
457
465
465
466
466
467
468
468
469
469
471
472
474
476
477
478
479
480
481
481
481
483
484
484
486
487
489
489
490
491
493
494
495
496
Sommaire XXIII
7.3.
7.4.
7.5.
7.6.
498
499
500
500
501
501
503
504
505
518
518
519
520
521
522
522
526
526
528
529
531
532
532
533
534
537
539
545
546
548
550
553
553
556
556
558
559
559
561
563
564
564
566
566
569
570
586
586
588
588
588
Sommaire XXV
589
589
591
593
594
596
597
598
600
600
600
601
604
605
607
608
609
610
610
611
612
613
614
615
617
617
618
619
620
620
621
622
625
625
631
631
632
633
634
634
635
636
637
638
639
640
641
642
644
644
645
646
648
649
663
663
667
670
672
672
672
673
Sommaire XXVII
679
679
680
681
683
684
684
685
686
687
688
689
689
690
691
692
693
695
695
697
697
699
700
702
704
704
705
706
706
707
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
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
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
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.
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.
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 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-
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
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
Disques
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.
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
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.
Fichier
VINS
Nom
Cru
Prnom
Millsime
Adresse
Qualit
NbAbus
Quantit
Cru
Millsime
RefVin
Date
Date
Quantit
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
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
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
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.
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
Dans la pratique, ces objectifs ne sont que trs partiellement atteints. Ci-dessous nous
analysons plus prcisment chacun deux.
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.
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.
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.
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>
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).
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;
(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 ;
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
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 ;
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] ;
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
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.
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
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
(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.
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
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.
Programme
Utilisateur
Programme
Utilisateur
Sous-schma
Sous-schma
Sous-schma
DML
SCHMA
SCHMA DE
STOCKAGE
SGBD
OS
BD
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.
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
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
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-
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
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.
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
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.
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.
[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.
ds que survient un vnement dans le monde rel : on parle alors de traitement transactionnel, mode de traitement privilgi par les bases de donnes.
Livraisons
Factures
Saisie
Impression
Catalogue
des prix
Comptabilit
Fichier
Comptes
clients
Comptes
clients
Fichier
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
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.
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.
Cylindre interne
Cylindre externe
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.
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.
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.
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
Compilation
Code machine
translatable
Chargement
dition de liens
Code machine
excutable
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.
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.
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.
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 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
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.
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.
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
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.
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-
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.
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.
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
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.
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
...
...
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.
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.
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 ;
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.
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.
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.
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.
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.
Iga1
Article a1
de longueur lga1
a1
Iga2
Article a2
de longueur lga2
a2
L Octets
Iga3
Article a3
de longueur lga3
a3
Index optionnel
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.
Cl
Nombre de 0 N-1
...
...
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.
(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].
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.
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).
H (KEY)
XXXX
X X X
000
001
010
011
100
101
110
111
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.
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
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.
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
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.
Dans cette section, nous tudions les principes de base des organisations avec index et
les principales mthodes pratiques.
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
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.
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,
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 -
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
lequel sont fondes des organisations telles ISAM, VSAM et UFAS. Il est impossible
dassocier un index non dense un fichier non tri.
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
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
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.
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.
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
22 23 24 26
N = 1 + 2 ((m+1)h-1-1).
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)
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
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.
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
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.
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+.
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
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-
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.
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.
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)
Zone de dbordement
de cylindre
Zone de dbordement
indpendante
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
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.
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
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.
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
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-
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.
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-
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.
Zone index
15
31
51
27
43
47
37
20
22
40
33
53
30
Aire 0 compose de quatre intervalles
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
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
7
22
Zone index
10
31
15
20
51
43
47
37
13
27
40
33
53
30
Aire 0 compose de quatre intervalles
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
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-
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
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.
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
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
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.
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.
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.
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
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
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
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.
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
0
0
0
1
0
0
1
0
0
1
0
0
1
0
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
1
2
3
4
5
Produits
Cot
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
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.
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.
[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.
[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.
[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.
[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.
[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.
[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
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),
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.
De plus, les mots cls obligatoires sont souligns. Les paramtres des clauses sont
prciss entre crochets triangulaires (<>).
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.
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>
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}
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.
PRODUCTEURS
RCOLTE
VINS
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.
P2
P1
V11
V21
V13
V12
DGUSTATION
VINS
BUVEURS
RCOLTE
VENTE
PRODUCTEURS
ACHAT
COMMANDES
Chablis
Volnay
10
20
15
Paul
10
Pierre
11
Jacques
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
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.
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.
25
Article insrer
Last
First
Volnay
30
Prior
Sorted
10
20
Article courant
du programme
Next
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.
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
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
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}
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.
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.
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>+}
FIND
{FIRST | LAST | NEXT | PRIOR | <i> | <paramtre>}
<nom-darticle> WITHIN <nom-de-fichier>
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>
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.
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>+}
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.
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).
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.
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.
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.
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
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].
Arbre 1
Arbre 2
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
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
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-
/*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
/*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
/*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
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-
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.
Chapitre V
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-
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))
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.
Une clause ayant un seul littral situ aprs limplication (on dit en tte de clause),
donc un seul Qi, est dite clause de Horn.
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,
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))).
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
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)
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
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.
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> : := = | < | | > | |
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
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.
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.
NPRO
NOMP
QTES
P.
COULEUR
P.
NPRO
NOMP
QTES
COULEUR
P.
P.
Rouge
ACHAT
NPRO
NOMP
100
P.
NACH
DATE
QTES
NPRA
COULEUR
QTEA
NOMF
100
P.
NPRO
NOMP
QTES
COULEUR
ALL.100
ACHAT
NACH
DATE
NPRA
QTEA
NOMF
100
P.
NPRO
P.
NOMP
QTES
COULEUR
> 1000
boite condition
COULEUR = "Rouge" OR COULEUR = "Verte"
NVEN
NOMC
NPRV
QTEV
DATE
P.ALL.Cx
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
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.
NOMENCLATURE
COMPOSE
COMPOSANT
Voiture
Porte
Voiture
Chassis
Voiture
Moteur
Moteur
Piston
Moteur
Bielle
Moteur
Chemise
Piston
Axe
Piston
Segment
NOMENCLATURE
COMPOSE
COMPOSANT
Voiture
Cx
Cx
P. Cy
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.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)
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.
QTES
COULEUR
"Vins" P.SUM.ALL.Q
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 ;
NPRO
NOMP
QTES
COULEUR
200
"Balais"
100
"Bleu"
NPRO
NOMP
200
200
QTES
COULEUR
10
10 + 100
"Rouge"
Figure V.14 : Mise jour des quantits en stock des produits rouges
NPRO
NOMP
QTES
COULEUR
"Rouge"
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].
(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.
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.
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 ;
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) ;}
DIRIGE(y,z) DIRIGE(x,z).
DIRIGE(marie,z)
DIRIGE(pierre,z)
DIRIGE(pierre,julie)
DIRIGE(pierre, marie)
DIRIGE(marie, julie)
DIRIGE(pierre,julie)
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.
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
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.
[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
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.
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.
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
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
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.
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
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
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.
Soulignons que le schma dune relation reprsente son intention, cest--dire les
proprits (au moins certaines) communes et invariantes des tuples quelle va contenir
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.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
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.
ABUS
BUVEURS
VINS
NB
NV
Degr
Nom
Cru
Type
Prnom
Adresse
Quantit
Date
Millsime
Qualit
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)
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.
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.
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
Cru
Mill
CHENAS 1983
Vins2
Rgion
Couleur
BEAUJOLAIS
ROUGE
TOKAY
1980
ALSACE
BLANC
TAVEL
1986
RHONE
ROSE
Cru
Mill
Rgion
Couleur
TOKAY
1980
ALSACE
Cru
Mill
CHENAS 1983
BLANC
ROUGE
Rgion
Couleur
BEAUJOLAIS
ROUGE
TOKAY
1980
ALSACE
BLANC
TAVEL
1986
RHONE
ROSE
ROUGE
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
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
Cru
Mill
CHENAS 1983
TAVEL
1986
Rgion
Couleur
BEAUJOLAIS
ROUGE
RHONE
ROSE
X
RELATION1
RELATION2
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
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
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
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.
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
VINS
Cru
Mill
Rgion
Qualit
VOLNAY
1983 BOURGOGNE
VOLNAY
1979 BOURGOGNE
CHENAS
1983
BEAUJOLAIS
JULIENAS
1986
BEAUJOLAIS
Cru
Mill
Rgion
Qualit
JULIENAS
1986
BEAUJOLAIS
VINS
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.
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>
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
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
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
QualMoy
B
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.
RSULTAT
RELATION1
RELATION2
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}
RSULTAT
RELATION1
RELATION2
VINS
QUALITE
CRU
Cru
Mill
Qualit
VOLNAY
1983
VOLNAY
1979
CHABLIS
1983
CHABLIS
1979
JULIENAS
1986
Mill
Qualit
1983
1979
Cru
CHABLIS
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).
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
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-
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.
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
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.
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
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
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)
(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)
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.
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
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
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
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.
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].
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>})
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
11,64
SUM
Cru
Quantit
VOLNAY
300
CHABLIS
550
JULIENAS
400
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-
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
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 :
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 ;
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
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
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
avec :
<PRIVILGES> ::= ALL PRIVILEGES | <ACTION>+
<ACTION>
::=
<RCEPTEUR> ::=
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.
Une expression de valeurs est une expression arithmtique (compose avec les oprateurs binaires +, , * et /), ventuellement parenthse, de spcifications de constantes
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
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.
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
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
(Q6) SELECT
FROM
WHERE
*
VINS
CRU IS NULL
(Q7) SELECT
FROM
WHERE
CRU
VINS
QUALITE IN (A,B,C)
*
VINS, ABUS
*
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
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.
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
(Q15) SELECT
FROM
WHERE
DISTINCT NOM
BUVEURS
NB IN
SELECT NB
FROM
ABUS
WHERE
NV IN
SELECT
FROM
WHERE
NV
VINS
CRU = CHABLIS
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
CRU
VINS
DEGRE > 13
CRU
VINS
MILLESIME = 1977
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 :
AVG(DEGRE)
VINS
CRU = Chablis
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
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
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
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).
(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
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.
Update
Insert
Delete
MMOIRE
Commit Work
Rollback Work
BD
NANT
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>+)].
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.
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.
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.
*
ABUS
DATE 21/08/1996 < N
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)
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.
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>+)]
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
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
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.
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.
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.
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].
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).
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.
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}]
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.
On peut donc ainsi crire des contraintes trs complexes, difficiles vrifier pour le
systme.
EXEMPLE
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 12 ;
et :
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR < 11 ;
EXEMPLE
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 12 ;
et :
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 11 ;
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.
Dbut Transaction
BD
U1
tat transitoire
U2
...
Un
BD
Fin Transaction
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.
Opration
Suppression
Insertion
Mise jour
Type de contrainte
Cl primaire K de R
Pas de vrification
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
Pas de forme
simplifie
Contrainte
temporelle
sur attribut
Pas de vrification
S : Les cls K de S
ne figurent pas dans
A de R.
Pas de vrification
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)
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.
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.
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)).
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 :
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.
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.
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.
etc. Elle est certes un peu complexe, ce qui dmontre finalement la difficult de traiter
efficacement les contraintes exprimables en SQL2.
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.
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.
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 ?
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.
valuateur
Moteur
Analyseur
Excuteur
Moniteur d'vnements
Requtes
Noyau du SGBD
BD active
Dictionnaire
Externe
Heure
Interne
Appel
Modification
Update
Insert
Interrogation
Delete
Select
Transaction
Begin
Commit
Abort
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.
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.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}])
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.
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.
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.
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.
[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.
[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
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-
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.
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
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 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
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.
Base
Vue
R1
...
;;;
;
Rponse
Rn
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.
B.NOM, B.PRENOM
Question
B.ADRESSE =
Vue
"Versailles"
Vue
A.NB
B.NB
Dfinition de vue
A.QTE >10
BUVEURS B
ABUS A
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.
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 multitables
avec cls
Vues monotables
avec cls
Figure IX.4 : Classification des vues selon les possibilits de mise jour
Mise jour u
Vue
as Question V
BD
Vue
as Question V
BD
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
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>.
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.
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].
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
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.
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.
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.
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.
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.
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
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)
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
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.
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 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.
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
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-
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
T.NUMCONT
P
$D1
O.DATE
<$D1+1
O
T.NOM
"EUROPE"
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-
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.
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.
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.
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-
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
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"
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.
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).
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-
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 ;
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
B.NB
A.NV
A.NB
R.NV
=
V.NV
R.NP
P.NP
A1,Ap
A1,Ap
Ai,...Aj,
A1, Ap
Ai = a
Ai = a
et
Aj = b
Aj = b
A1,Ap
A1,Ap
Ai = a
Ai = a
Ai,
A1,Ap
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...)
Ai = a
Ai = a
Ai = a
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...)
A1,Ap
A1,Ap
A1,Ap
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.
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.
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].
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-
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
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
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
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.
Init
U
S
Echec
E
E
Succs
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).
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)).
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)
1,5,18
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
10
5,14,18
11
1,7,15
12
2,3,6,25
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)}
}
}
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.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) }
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.
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
.
.
.
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) ;
}
}
}
}
R2).
Arbre ramifi
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 !
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.
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.
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)
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.
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.
Enumrative
Exhaustive
Augmentation
Alatoire
Amlioration
itrative
Recuit
simul
Gntique
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
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.
[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.
[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.
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
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
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.
Un objet est donc une instance dentit. Il possde une identit qui permet de le reprer. Par exemple, un vhicule particulier V1 est un objet. Un tel vhicule est caractris par un tat constitu dun numro, une marque, un type, un moteur, un nombre de
kilomtres parcourus, etc. Il a aussi un comportement compos dun ensemble doprations permettant dagir dessus, par exemple crer(), dmarrer(), rouler(), stopper(),
dtruire(). Chaque opration a bien sr des paramtres que nous ne prcisons pas pour
linstant.
Lobjet de type vhicule didentit V1 peut tre reprsent comme un groupe de
valeurs nommes avec un comportement associ, par exemple :
V1 {
Numro: 812 RH 94, Marque: Renault, Type: Clio, Moteur: M1 ;
crer(), dmarrer(), rouler(), stopper(), dtruire() }.
Une personne est aussi un objet caractris par un nom, un prnom, un ge, une voiture habituellement utilise, etc. Elle a un comportement compos dun ensemble
doprations { natre(), vieillir() , conduire(), mourir() }. Lobjet de type personne
didentit P1 peut tre dcrit comme suit :
P1 {
Nom: Dupont, Prnom: Jules, Age: 24, Voiture: V1 ;
natre(), vieillir(), conduire(), mourir() }.
Un objet peut tre trs simple et compos seulement dune identit et dune valeur
(par exemple, un entier E1 {Valeur: 212}). Il peut aussi tre trs complexe et luimme compos dautres objets. Par exemple, un avion est compos de deux moteurs,
de deux ailes et dune carlingue, qui sont eux-mmes des objets complexes.
travers ces exemples, deux concepts importants apparaissent associs la notion
dobjet. Tout dabord, un objet possde un identifiant qui matrialise son identit.
Ainsi, deux objets ayant les mmes valeurs, mais un identifiant diffrent, sont considrs comme diffrents. Un objet peut changer de valeur, mais pas didentifiant
(sinon, on change dobjet).
Notion XI.2 : Identifiant dobjet (Object Identifier)
Rfrence systme unique et invariante attribue un objet lors de sa cration permettant de le
dsigner et de le retrouver tout au long de sa vie.
internes invariants dans les bases de donnes objets soppose aux bases de donnes
relationnelles dans lesquelles les donnes (tuples) ne sont identifis que par des
valeurs (cls). Deux objets O1 et O2 sont identiques (on note O1 == O2) sils ont le
mme identifiant ; il ny a alors en fait quun objet dsign par deux pointeurs O1 et
O2. Lidentit dobjet est donc lgalit de pointeurs. Au contraire, deux objets sont
gaux (on note O1 = O2) sils ont mme valeur. O1 == O2 implique O1 = O2,
linverse tant faux.
Lidentit dobjet apporte une plus grande facilit pour modliser des objets complexes ; en particulier, un objet peut rfrencer un autre objet. Ainsi, le vhicule V1
rfrence le moteur M1 et la personne P1 rfrence le vhicule V1. Les graphes peuvent tre directement modliss (voir figure XI.1). Le partage rfrentiel dun sousobjet commun par deux objets devient possible sans duplication de donnes. Par
exemple, une personne P2 { Nom: Dupont; Prnom: Juliette; Age: 22; Voiture: V1 }
peut rfrencer le mme vhicule que la personne P1.
Objet P1
Objet P2
Objet V1
Figure XI.1 : Partage rfrentiel dun objet par deux autres objets
Comme le montre ces exemples, en plus dun identifiant, un objet possde des attributs aussi appels variables dinstance. Un attribut mmorise une valeur ou une
rfrence prcisant une caractristique dun objet. La valeur peut tre lmentaire (un
entier, un rel ou un texte) ou complexe (une structure valeurs multiples). La rfrence correspond un identifiant dun autre objet. Elle permet de pointer vers un autre
objet avec des pointeurs invariants.
Notion XI.3 : Attribut (Attribute)
Caractristique dun objet dsigne par un nom permettant de mmoriser une ou plusieurs valeurs,
ou un ou plusieurs identifiants dobjets.
Le terme mthode sera aussi employ pour dsigner une opration. Issu de Smalltalk,
ce concept a cependant une connotation plus proche de limplmentation, cest--dire
que lorsquon dit mthode, on pense aussi au code constituant limplmentation. Quoi
quil en soit, un objet est manipul par les mthodes qui lencapsulent et accd via
celles-ci : le principe dencapsulation hrit des types abstraits cache les structures
de donnes (les attributs) et le code des mthodes en ne laissant visible que les oprations exportes, appeles oprations publiques. Par opposition, les oprations non
exportes sont qualifies de prives. Elles ne sont accessibles que par des mthodes
associes lobjet. Lencapsulation est un concept fondamental qui permet de cacher
un groupe de donnes et un groupe de procdures associes en les fusionnant et en ne
laissant visible que linterface compose des attributs et des oprations publics.
Notion XI.5 : Interface dobjet (Object Interface)
Ensemble des signatures des oprations, y compris les lectures et critures dattributs publics, qui
sont applicables depuis lextrieur sur un objet.
Linterface dun objet contient donc toutes les oprations publiques que peuvent utiliser les clients de lobjet. Pour viter de modifier les clients, une interface ne doit pas
tre change frquemment : elle peut tre enrichie par de nouvelles oprations, mais il
faut viter de changer les signatures des oprations existantes. En consquence, un
objet exporte une interface qui constitue un vritable contrat avec les utilisateurs. Les
attributs privs (non visibles lextrieur) et le code des oprations peuvent tre
modifis, mais changer des oprations de linterface ncessite une reprise des clients.
Ce principe facilite la programmation modulaire et lindpendance des programmes
limplmentation des objets. Par exemple, il est possible de dvelopper une structure
de donnes sous la forme dun tableau, permettant de mmoriser le contenu dun
cran. Cette structure peut tre encapsule dans des oprations de signatures fixes
permettant dafficher, de redimensionner, de saisir des caractres. Le changement du
tableau en liste ncessitera de changer le code des oprations, mais pas linterface, et
donc pas les clients.
En rsum, les oprations et attributs publics constituent linterface dun objet. Ceuxci sont les seuls accessibles lextrieur de limplmentation de lobjet. Le code qui
constitue cette implmentation peut tre structur. Certaines oprations sont alors
invisibles lextrieur de lobjet : elles sont appeles oprations prives. Par
exemple, la saisie dun texte peut seffectuer par plusieurs appels dune mthode saisissant une ligne : la mthode SaisirLigne restera invisible au monde extrieur et seule
la mthode SaisirTexte pourra tre invoque. Dans la suite et afin de simplifier, nous
supposerons que toutes les mthodes dun objet sont publiques. Si nous ne le prcisons pas, les attributs sont publiques. Mettre des attributs publics ne respecte pas trs
bien le principe dencapsulation qui consiste cacher les proprits servant limplmentation. Briser ainsi lencapsulation conduit des difficults si lon veut changer
par exemple le type dun attribut : il faut alors prvenir les clients qui doivent tre
modifis !
Notez quun attribut dun objet peut tre lu par une fonction applique lobjet dlivrant
la valeur de lattribut. Nous noterons cette fonction GetAttribut, o Attribut est le nom
de lattribut considr. Ainsi, lattribut Nom dfinit une fonction GetNom qui, applique
une personne P, dlivre un texte (son nom). La proprit Voiture peut aussi tre lue par
une fonction GetVoiture qui, applique une personne, dlivre lidentifiant de lobjet
constituant son vhicule habituel. Un attribut peut aussi tre crit par une fonction particulire que nous noterons PutAttribut. En rsum, tout attribut dfinit implicitement
deux mthodes (criture : Put, et lecture : Get) qui peuvent tre prives ou publiques,
selon que lattribut est visible ou non lextrieur. Le formalisme unificateur des fonctions est trs puissant, car il permet de raccrocher une mme thorie (les types abstraits) les proprits mmorises (attributs) et calcules (fonctions) dun objet.
Notez que certains systmes objets sparent la fonction de cration des objets de la
classe : on obtient alors des classes qui sont simplement des implmentations de types
abstraits et lon ajoute des usines objets (Object factory) pour crer les objets.
Chaque classe doit alors avoir son usine, ce qui complique le modle.
Une classe spcifie donc la structure et le comportement communs des objets quelle
permet de crer. Au-del du nouveau type de donnes abstrait ajout lenvironnement par une dfinition de classe, une classe supporte une implmentation : cest le
code des oprations. Elle donne aussi naissance une famille dobjets : on parle alors
de lextension de la classe. Cette extension est une collection dobjets ayant mmes
structure et comportement. La classe est donc un peu lanalogue de la table dans les
bases de donnes relationnelles, bien quune table ne permette que de modliser la
structure commune des tuples qui la composent.
En rsum, le concept de classe est plutt complexe. Par abus de langage, le mot
classe dsigne gnralement une intention (le type abstrait), mais aussi parfois une
extension (la collection des objets membres de la classe), dautre fois une implmentation (la structure des objets et le code des oprations). La spcification progressive
des classes dobjets composant une base de donnes objets permet de modliser le
comportement commun des objets de manire modulaire et extensible. Elle permet
aussi de spcifier les collections contenant les objets ou extensions de classes. La plupart des systmes distinguent lintention de lextension, une classe (ou un type selon
le vocabulaire) pouvant avoir plusieurs extensions.
Du point de vue de la reprsentation dune dfinition de classe, nous utiliserons la
notation prconise par UML [Rational97] et illustre figure XI.2. Nous avons
gauche le cadre gnrique servant reprsenter une classe, droite le cas de la classe
Vin. Chaque attribut a un nom, de mme que chaque opration. Un attribut est typ.
Les oprations peuvent avoir des paramtres, et un type dans le cas de fonctions. Un
attribut ou une opration publics sont prcds de + ; de mme pour une opration.
Nous pouvons maintenant illustrer la notion de classes par quelques exemples. La
syntaxe choisie pour les dfinitions de classe est proche de C++, chaque attribut ou
mthode ayant un type suivi dun nom et dventuels paramtres. Notre premier
exemple (voir Figure XI.3) vise modliser le plan gomtrique sous forme de points.
Pour crer et rassembler les points crs, nous dfinissons une classe comportant deux
attributs, X et Y, de type flottant. Une mthode sans paramtre Distance permet de calculer la distance du point lorigine ; cette mthode retourne un flottant. Une
mthode Translater permet de translater un point dun vecteur fourni en para-
mtre et ne retourne aucun paramtre (void en C++). Une autre mthode Afficher
permet de gnrer un point lumineux sur un cran ; elle ne retourne aucun paramtre.
Classe
Nom
attributs
oprations
Vins
+ Cru : char[20]
+ Millsime : int
- Degr : fixed 5.2
- Quantit: int
+ Produire()
+ Livrer()
+ Int Get_Degr()
+ Set_Degr(degr int)
Illustrations
non
UML
Class Point {
Float X;
Float Y;
Float Distance();
Void Translater(Float DX, Float DY);
Void Afficher(); };
La figure XI.4 permet de dfinir les classes Vin, Personne et Vhicule dont
quelques objets ont t vus ci-dessus. Les mots cls Public et Private permettent
de prciser si les proprits sont exportes ou non. Par dfaut, il restent cachs dans la
classe, donc privs. Notez que comme en C++, nous dfinissons une rfrence par le
type de lobjet point suivi dune toile (par exemple Vhicule*). Deux mthodes
sont attaches la classe Personne : Vieillir qui permet dincrmenter de 1 lge
dune personne et rend le nouvel ge, Conduire qui permet de changer le vhicule
associ et ne retourne aucun paramtre. Notez que la classe Vhicule rfrence
dautres classes (Constructeur, Propulseur) non dfinies ici.
Class Vin {
Fixed 5.2 degr ;
Int quantit ;
Public :
Char cru [20] ;
Int millsime ;
void Produire()
void Livrer()
Int Get_Degr()
void Set_Degr(Int degr) } ;
Class Personne {
String Nom;
String Prnom;
Int Age;
Vhicule* Voiture;
Public :
Int Vieillir();
Void Conduire(Vhicule V); };
Class Vhicule {
Public :
String Numro;
Constructeur* Marque;
String Type;
Propulseur* Moteur; };
Une opration dfinie dans le corps dune classe sapplique un objet particulier de la
classe. Par exemple, pour translater un point rfrenc par P dun vecteur unit, on
crira PTranslater(1,1). Pour calculer la distance de P lorigine dans une
variable d, on peut crire d = PDistance(). Certaines mthodes peuvent
sappliquer plusieurs objets de classes diffrentes : une telle mthode est dite multiclasse. Elle est en gnral affecte une classe particulire, lautre tant un paramtre.
La possibilit de supporter des mthodes multiclasses est essentielle pour modliser
des associations entre classes sans introduire de classes intermdiaires artificielles.
gnrale pour obtenir une classe plus spcifique. On peut aussi procder par mise en
facteur des proprits communes diffrentes classes afin de dfinir une classe plus
gnrale. La notion de gnralisation ainsi introduite est emprunte aux modles
smantiques de donnes [Hammer81, Bouzeghoub85].
Notion XI.7 : Gnralisation (Generalization)
Lien hirarchique entre deux classes spcifiant que les objets de la classe suprieure sont plus gnraux que ceux de la classe infrieure.
Personne
- nss
- nom
- prnom
- ge
- photo*
+ vieillir()
Employ
Buveur
- profession
- lieu de travail
- salaire
- primes
- tat
- abus
+ boire()
+ dormir()
+ travailler()
Cadre
+ travailler()
Non cadre
Dans ce cas, la sous-classe hrite des proprits et oprations de toutes ses superclasses. Lhritage multiple permet de dfinir des classes intersection comme dans la
figure XI.7, o les EmploysBuveurs hritent la fois des Buveurs et des Employs.
Ils hritent certes dun seul nom provenant de la racine Personne.
Employ
Buveur
- profession
- lieu de travail
- salaire
- primes
- tat
- abus
+ boire
+ dormir
+ travailler()
EmployBuveur
+BoireTravailler()
dambigut de noms. Enfin, un choix automatique peut tre fait par le systme, par
exemple le premier gauche. Dans lexemple de la figure XI.8, les triangles rectangles isocles vont hriter de trois fonctions de calcul de surface. Deux dentres
elles sont identiques et proviennent de lopration surface associe aux triangles. Il
faut pouvoir choisir parmi les deux restantes, soit en conservant les deux en les
renommant polygone_surface et triangle_surface, soit en en slectionnant une, par exemple la premire gauche, donc celle des polygones droits.
Triangle
+Surface
PolygoneDroit
+Surface()
TriangleIsocle
TriangleRectangle
TriangleRectangleIsocle
Dire quune classe C1 est plus gnrale quune classe C2 permet de dfinir une relation dordre C2 C1, qui reprsente le fait que les instances de C2 sont incluses dans
celles de C1. Cette relation dordre correspond donc une inclusion au niveau des
ensembles dobjets. La relation dordre ainsi dfinie permet de considrer le treillis
des classes. Ce treillis possde en gnral un plus grand lment qui est la classe
dnomme Objet (Object) ; cette classe apparat alors comme la racine de la hirarchie dhritage qui fournit toutes les mthodes de base de manipulation des objets,
mthodes hrites par toutes les autres classes. La hirarchie des types et lhritage de
proprits ont t formellement tudis dans le contexte des types abstraits sous forme
de sigma-algbres [Guogen78], et plus rcemment dans le contexte de la programmation objet [Castagna96].
classe une fonctionnalit similaire de mme signature dopration, mais avec un code
diffrent. On parle alors de redfinition.
Notion XI.10 : Redfinition (Overriding)
Spcification dune mthode existante dans une super-classe au niveau dune sous-classe, avec une
implmentation diffrente.
Par exemple, une mthode globale telle que Travailler peut tre spcifie au
niveau de la classe Employ, puis redfinie de manire spcifique au niveau de la
classe Cadre. En effet, la mthode Travailler de la classe Employ pourra tre
redfinie par un code correspondant un travail de direction au niveau de la classe
Cadre. Il est mme possible de ne pas dfinir le code de lopration au niveau dune
classe et dimposer de le dfinir au niveau des sous-classes : on parle alors de
mthode virtuelle au niveau de la super-classe.
Pour une mme classe, il est aussi possible de dfinir plusieurs implmentations pour
une mme opration. Chacune delle sera alors distingue par des paramtres diffrents. Ceci correspond la notion de surcharge.
Notion XI.11 : Surchage (Overloading)
Possibilit de dfinir plusieurs codes pour une mme opration dune classe, le code appropri
tant slectionn selon le type des paramtres fournis lors dun appel.
La possibilit de surcharge rend ncessaire le choix du code dune mthode en fonction de ses arguments. Cette possibilit est dailleurs gnralise : une opration dun
nom donn peut avoir diffrentes signatures; un code est alors attach chaque signature. Par exemple, au niveau de la classe Personne, il est possible de dfinir plusieurs mthodes Vieillir, lune sans paramtre ajoutant un lge, lautre avec un
paramtre indiquant le nombre dannes ajouter. Chaque signature aura alors un
code spcifique. Cette possibilit est souvent utilise pour grer des valeurs par dfaut
de paramtres.
Redfinition et surcharge sont deux formes de polymorphisme. Cette fonctionnalit
importante peut tre dfinie comme suit :
Notion XI.12 : Polymorphisme (Polymorphism)
Facult pour une opration davoir diffrentes signatures avec un code spcifique attach chaque
signature.
Collection
Insert
Delete
Get
IsEmpty
Count
Apply
Aggregate
Search
Set
Include
Choice
All
Exist
Union
Intersection
List
Array
First
Next
Last
Tail
Append
Put[i]
Get[i]
Extract[i,j]
class Phrase {
List <Array <char>> Squence; };
class Paragraphe {
Phrase Thme;
List <Phrase> Dtails;
Phrase Conclusion; };
class Texte {
List <Paragraphe*> Contenu; };
Lexistence de collections imbriques traduit le fait que certains objets sont inclus
dans dautres. Il sagit en fait dune reprsentation de la relation dagrgation entre
classes.
Notion XI.15 : Agrgation (Aggregation)
Association entre deux classes exprimant que les objets de la classe cible sont des composants de
ceux de la classe source.
Lagrgation traduit la relation fait partie de ; par exemple, les caractres font partie de la phrase. Les collections permettent dimplmenter les agrgations multiva-
lues. Lagrgation peut tre implmente par une rfrence (par exemple
List<Paragraphe*>) ou par une imbrication, selon que lon dsire ou non partager
les objets inclus. La reprsentation des agrgations par un graphe permet de visualiser le
processus de construction des objets complexes. La figure XI.11 reprsente le graphe
dagrgation, encore appel graphe de composition, de la classe Texte. Les cardinalits
multiples sont mentionnes par des toiles (*), conformment la notation UML
[Rational97].
Texte
Contenu
*
Paragraphe
Thme
*
Dtails
Conclusion
Phrase
Squence
*
Char
Personne
Employ
Buveur
Boire
Abus
Vin
BuPar
Date
Quantit
Reprsentation
Figure
Caricature
sourire()
pleurer()
Reprsente
Tte
ilD
Nez
Bouche
Forme
ilG
*
Point
Cercle
Centre
- Rayon
-x
-y
Figure* Bouche ;
// operations sur personnage
void Sourire () ;
void Pleurer () ;
Graphic Dessiner (Int Echelle) ; }
Class Cercle {
Point Centre ;
Double Rayon ; }
Class Figure {
List <Point> Forme ; }
Soulignons quun schma de classes modlise la fois la structure (les attributs des
classes) et le comportement (les mthodes) des objets. La dfinition complte dune
base de donnes objets ncessite donc un langage de programmation afin de spcifier le code des programmes. Ce langage est un langage orient objet, du type
Smalltalk, ou de plus en plus souvent C++ ou Java.
La persistance des objets. Tout objet doit pouvoir persister sur disque au-del du
programme qui le cre. Un objet peut tre persistant ou transient. Dans le
deuxime cas, sa dure de vie est au plus gale celle du programme qui le cre ; il
sagit dun objet temporaire qui reste en mmoire.
Notion XI.18 : Objet persistant (Persistent object)
Objet stock dans la base de donnes dont la dure de vie est suprieure au programme qui le
cre.
Notion XI.19 : Objet transient (Transient object)
Objet restant en mmoire, dont la dure de vie ne dpasse pas celle du programme qui le cre.
En C++ ou en Java, le constructeur dun objet est une fonction membre de la classe. Il
fait en gnral appel une fonction de rservation de mmoire et des fonctions
dinitialisation. Les constructeurs sont normalement dfinis par le programmeur, mais
C++ et Java insrent un constructeur minimal dans les classes qui nen possdent pas.
Le nom du constructeur est le nom de la classe. Par exemple, un point origine pourra
tre dfini comme suit :
Point Origine(0,0).
Le destructeur libre la place mmoire associe lobjet. Il peut tre fourni par le programmeur. Certains langages orients objet tels Java et Smalltalk sont munis dun
ramasse-miettes dtruisant automatiquement les objets non rfrencs, si bien que le
programmeur na pas se soucier dappeler le destructeur dobjets.
Le problme qui se pose dans les SGBDO est dassurer la persistance des objets sur
disques pour pouvoir les retrouver ultrieurement. En effet, constructeur et destructeur
dobjets ne font que construire et dtruire les objets en mmoire. Une solution couramment retenue pour sauvegarder les objets sur disques consiste donner un nom
chaque objet persistant et fournir une fonction permettant de faire persister un objet
pralablement construit en mmoire. Cette fonction peut tre intgre ou non au
constructeur dobjet. Sa signature pourra tre la suivante :
// Rendre persistant et nommer un objet point.
Oid = Persist(<Nom>, <Ref>);
Nom est le nom attribu lobjet qui permettra ultrieurement de le retrouver (dans le
mme programme ou dans un autre programme). Ref est la rfrence en mmoire de
lobjet. Oid est lidentifiant attribu lobjet dans la base par le SGBDO.
Un objet persistant pourra ensuite tre retrouv partir de son nom, puis mont en
mmoire partir de son identifiant dobjet (adresse invariante sur disque). On trouvera
donc deux fonctions plus ou moins caches au programmeur dans les SGBD objets :
// Retrouver loid dun objet persistant partir du nom.
Oid = Lookup(<Nom>);
Un objet actif en mmoire pourra tre dsactiv (rcriture sur disque et libration de
la mmoire) par une fonction du style:
Finalement, il sera aussi possible de rendre non persistant (dtruire) dans la base un
objet persistant partir de son identifiant dobjet ou de son nom, en utilisant lune des
fonctions suivantes :
// Supprimer un objet persistant dsign par son nom
Void UnPersist(<Nom>);
Une telle bibliothque de fonction peut tre utilise directement par le programmeur
dans un langage orient objet comme C++ ou Java pour grer manuellement la persistance des objets. De plus, des fonctions de gestion de transactions devront tre intgres afin dassurer les critures disques, la gestion de concurrence et de fiabilit. Les
critures peuvent tre explicites par une fonction Put ou implicites lors de la validation, en fin de transaction. Un tel systme est voisin de celui offert par Objective-C
pour la persistance des objets dans des fichiers. Il constitue un niveau minimal de
fonctionnalits ncessaire la gestion de la persistance que nous qualifierons de persistance manuelle. Ce niveau de fonctions peut tre cach au programmeur du
SGBDO par lune des techniques tudies ci-dessous.
Dans tous les cas, un problme qui se pose lors de lcriture dun objet dans la base
est la sauvegarde des pointeurs vers les autres objets persistants. Comme lors de
lactivation dun objet persistant, il faut restaurer les pointeurs en mmoire vers les
autres objets actifs. Des solutions sont proposes par chacune des techniques de persistance dcrites ci-dessous. Notez que les systmes implmentent parfois des techniques de persistance mixtes, qui empruntent un peu aux deux dcrites ci-dessous.
Objet
New
Delete
Pobjet
New {Persist}
Delete {Unpersist}
operator
Classes dobjets
transients
Classesdobjets
persistants
Outre les constructeurs et destructeurs destins grer lobjet sur disque, la technique
de persistance par hritage surcharge en gnral le parcours de rfrence (oprateur
en C++). Cela permet dactiver automatiquement un objet point par un objet dj
actif lors du premier parcours de la rfrence, en utilisant une technique de mutation
de pointeur, comme nous le verrons ci-dessous.
En rsum, nous dfinirons la persistance par hritage comme suit :
Notion XI.23 : Persistance par hritage (Persistance by inheritance)
Technique permettant de dfinir la qualit dun objet tre persistant par hritage dune classe
racine de persistance, rendant invisible lactivation et la dsactivation des objets.
Cette technique prsente lavantage dtre simple raliser. Cependant, elle nassure
pas lorthogonalit de la persistance aux types de donnes, si bien que tout type ne
peut pas persister. Si lon veut avoir dans une mme classe des objets persistants et
transients (par exemple des personnes persistantes et des personnes transientes), on est
conduit dupliquer les classes. Ceci peut tre vit en marquant les objets non persistants dune classe persistante simplement par un boolen. La performance de la technique de persistance par hritage est discute, la surcharge des oprateurs (constructeurs et parcours de rfrences) pouvant tre coteuse.
condition dtre dclar comme tel, puis que tout objet point par un objet persistant
est persistant (voir figure XI.15). En gnral, les objets persistants sont les objets
nomms, nom et persistance tant dclars dans la mme commande de cration
dobjet persistant. Cela conduit ajouter un mot cl persistant ou db au langage de programmation (par exemple C++) et donc ncessite un prcompilateur qui
gnre les appels aux fonctions Persist, Unpersist, Activate, etc. Par
exemple, un employ pourra tre cr persistant par la dclaration :
Employe* emp = new persistant Employe(Toto);
De mme, une simple variable x pourra tre rendue persistante par la dclaration :
persistant int x;
Au vu de ces dclarations, le prcompilateur gnrera les commandes de persistance
et de recherche ncessaires. Tout objet racine de persistance (donc dclar persistant)
sera rpertori dans un catalogue o lon retrouvera son nom et son oid.
Catalogue
toto
lulu
x 7
adresse
.
.
.
voiture
moteur
garage
Tout objet rfrenc par un objet persistant sera persistant. L encore, le pr-compilateur devra assurer la gnration des appels aux fonctions de persistance lors des assignations ou des parcours de rfrences. Les rfrences devront aussi tre rendues persistantes par lune des techniques que nous allons tudier ci-dessous.
En rsum, nous dfinirons la persistance par rfrence comme suit :
Dans les langages objet comme C++, la navigation seffectue en mmoire par simple
dcodage de pointeurs. Dans une base dobjets, les choses ne sont pas aussi simples :
un objet pointant sur un autre objet est en effet crit dans la base, puis relu par un
autre programme plus tard. Lobjet point nest alors plus prsent en mmoire (voir
figure XI.16). Le problme soulev est donc de mmoriser de manire persistante les
chanages dobjets sur disques, puis de les dcoder en mmoire de manire efficace.
Toto
VoitureToto
Vhicule*
Peugeot
Toto
Mmoire
Pointeur invalide
Disque
Vhicule*
En rsum, il faut pouvoir utiliser des identifiants dobjets comme des pointeurs sur
disques et des adresses en mmoire. Le passage dun type de pointeur lautre est
appel mutation de pointeurs.
Notion XI.26 : Mutation de pointeurs (Pointer swizzling)
Transformation consistant passer de pointeurs disques des pointeurs mmoire lors de la premire navigation en mmoire via un objet et inversement lors de la dernire.
PREF
REF
OID
Disques
En criture
si OID = NUL ALORS {OID = AllouerBD(Objet) ; Ecrire (REF, OID) } ;
En lecture
si REF = NUL ALORS {REF = AllouerMC(Objet) ; Lire (OID, REF) } ;
Page Manquante
0
Mmoire Virtuelle Client
2**32
1 Accs
2 Violation
4 Retour Page
O.S.
3 Accs Serveur
Image Disque
Cette technique est parfois appele mmoire un seul niveau (Single Level Store) ;
en effet, lutilisateur travaille directement sur limage de la base en mmoire. Elle est
trs efficace lorsquun mme objet est travers plusieurs fois et que les objets parcourus sont groups dans une mme page. Cependant, la dpendance du programme la
structure de la mmoire virtuelle peut constituer un inconvnient encore mal mesur
aujourdhui.
Une expression de chemin permet deffectuer un parcours dans le graphe des associations de classes. Sur la base de la figure XI.12, Reprsente.Tte.Centre.x est une
expression de chemins : partant dun buveur B, elle permet datteindre un rel reprsentant labscisse du cente de la tte, en traversant les classes Caricature Cercle et
Point. De telles expressions sont la fois utilisables en algbre dobjets complexes et
en SQL tendu, comme nous le verrons dans les chapitres suivants. Ds que lon rencontre un chemin multivalu, la traverse devient ambigu ; par suite, la plupart des
langages interdisent les expressions de chemins multivalues du style Abus.cru sur
la base de la figure XI.12, car bien sr un buveur boit plusieurs vins.
Notion XI.28 : Expression de mthodes (Method Expression)
Squence dappels de mthodes de la forme M1.M2Mn, avec dventuels paramtres pour certaines mthodes Mi de la forme Mi(P1, P2Pj).
Nom
dattribut
Constante
Numrique
Entier
Expression
arithmtique
Chane de
caractres
Expression
fonctionnelle
Expression
de mthode
Expression
de chemin
Rel
partir des expressions valuables gnralises, il est possible de spcifier une qualification de restriction ou jointure gnralise, capable de traiter des objets complexes.
Une telle qualification peut tre vue comme un arbre ET-OU de prdicats lmentaires (voir figure XI.20). Un prdicat lmentaire est de la forme :
<Prdicat lmentaire> ::= <Expression valuable>
[<Comparateur> <Expression valuable>].
AND
P1
OR
P2
P3
P4
Cette opration, note dans certaines extensions de lalgbre relationnelle, fait donc
apparatre des attributs valeur dans des ensembles. Elle est illustre figure XI.21.
Une dfinition plus gnrale pourrait consister grouper la relation selon un schma
hirarchique des attributs : on pourrait ainsi faire plusieurs groupages en une seule
opration. Dans le monde objet, cette opration peut tre applique une collection
pour gnrer une nouvelle collection, avec pour chaque objet obtenu par groupage,
attribution dun nouvel identifiant.
Lopration de dgroupage est lopration inverse (voir figure XI.21).
Pice
Type
Numro
Grouper(Type,{Numro})
Pice
Dgrouper(Type,{Numro})
Type
{Numro}
{ 1,7 }
{ 3,8 }
{2}
Attention il nest pas toujours vrai quun dgroupage aprs un groupage donne la relation initiale, en particulier si cette dernire a des doubles.
Notion XI.30 : Dgroupage (Unnest)
Opration transformant une relation attributs groups en relation plate, crant pour cela un tuple
pour chaque valeur du groupe en dupliquant les valeurs des autres attributs.
Laplatissage dune collection est utilis pour restructurer des collections de collections. Il est dfini par : Flatten(Collection) = {r t Collection r t}.
La jointure de collections sur un prdicat p est une transposition simple de la jointure par valeur du relationnel : OJoin(Collection1, Collection2,A1,A2,p) = {<A1 :
s, A2 : r> s Collection1 r Collection2 p(s,r)}.
Afin dliminer les doubles, une opration dlimination de duplicata est introduite.
Elle est note DupEliminate (Collection, e). e est un paramtre permettant de dfinir
lgalit dobjets dans la collection. Ce peut tre par exemple lgalit didentifiants
ou de valeurs. Coallesce (Collection, Ai, e) est une variante permettant dliminer les
doubles dans un attribut Ai dun tuple avec attribut multivalu.
Les oprations ensemblistes classiques dunion, intersection et diffrence de collections sont considrer. Elles ncessitent la dfinition du type dgalit dobjets considr, sur identifiant ou sur valeur.
Lalgbre distingue les oprations par valeur et par rfrence, dont largument est en
gnral un ou plusieurs identifiants. Les oprations sont classes en oprations de
recherche, oprations ensemblistes, oprations de groupement et enfin oprations de
mise jour. La figure XI.23 reprsente la hirarchie de gnralisation des oprations
de lalgbre propose.
Opration
Algbrique
Recherche
Jointure
VJoindre
Slection
Ensemble
Groupe
MiseAJour
Union
Grouper
InsrerCol
Intersection
Dgrouper
InsrerObj
Diffrence
Aplatir
Changer
RJoindre
Supprimer
Les suppressions seffectuent partir dune collection calcule qui contient les identifiants des tuples supprimer dans lautre collection. La suppression est quivalente
une diffrence sur identifiant dobjets. Elle est dfinie figure XI.27.
Les modifications seffectuent aussi partir dune extension de classe calcule qui
contient les identifiants de tuples modifier dans une classe de base et les lments
pour calculer les nouvelles valeurs des champs modifis. Ces lments sont exprims,
pour chaque attribut, sous la forme dune expression de calcul (par exemple
A = A *1,1 pour une augmentation de 10 % de A). La figure XI.28 dfinit plus prcisment lopration Changer.
Constructeur
+ nom
+ ville
+ directeurs
Employ
+ nss
+ nom
- date naissance
+ age()
Project
[numro]
RefJoin
[directeurs]
Select[age()
Select[ville
<
50]
"Paris"]
Employ
RefJoin
[Fabriquant]
Constructeur
Select[couleur
"Rouge"]
Vhicule
Class Nud {
Operation* Oper; // Operation effectuer en ce nud.
Flot* Input[MaxIn]; // collections dentre (fils).
Flot* Output[MaxOut]; // collections de sortie (parents).
};
Class Flot {
Int TailleEst; // Taille du flux estime.
} ;
5. CONCLUSION
Dans ce chapitre, nous avons prsent les concepts de modlisation introduits par
lorientation objet, les techniques de gestion de la persistance des objets et une algbre
dobjets complexes. Ces concepts et techniques constituent lessentiel des fonctionnalits aujourdhui offertes par les SGBDO par le biais du langage de dfinition dobjets, du
langage de requtes et du langage de manipulation dobjets. Au-del, il est important de
mentionner que les SGBDO offrent pour la plupart des environnements de dveloppements visuels labors. Ceux-ci permettent de parcourir les graphes de gnralisation et
de composition (agrgation et association) de classes, mais aussi de visualiser les objets,
voire de crer de nouvelles classes et de programmer des mthodes. Ces diteurs volus (en anglais, browsers) sont un des attraits importants des SGBDO : en exploitation
par exemple, ils autorisent la vision des classes dobjets sous forme dicnes clicables
pour dclencher les mthodes associes. Ces mthodes peuvent dailleurs tre des oprations de recherche ou de mise jour proches de celles de lalgbre dobjets.
Outre ceux tudis dans ce chapitre, les bases de donnes objets soulvent de nombreux problmes difficiles. Les plus cruciaux sont sans doute ceux darchitecture et de
performance. Quelle architecture client-serveur retenir ? Faut-il plutt des serveurs
dobjets ou de pages [Dewitt90] ? Comment optimiser les performances, en grant des
caches dobjets, en utilisant des techniques de type mmoire virtuelle dobjets, en dveloppant des mthodes de regroupement des objets souvent accds ensemble, etc. ? Du
point de vue du langage de requtes tendu aux objets, nous allons voir que deux propositions de standards sopposent quelque peu. Les techniques doptimisation sont encore
mal matrises en pratique. Un autre problme important est celui pos par les modifications de schmas : comment viter de dcharger la base et recompiler les mthodes, par
exemple lors dajout de super-classes ou de suppression de sous-classes ? Une solution
est sans doute la gestion de versions dobjets et de schmas [WonKim90]. Les problmes de concurrence en prsence de transactions longues (une transaction de conception peut durer plusieurs heures) sont eux aussi cruciaux. Tous ces problmes (notre liste
nest malheureusement pas exhaustive) seront tudis dans les chapitres qui suivent.
Sous sa forme pure ou sous forme intgre au relationnel, lobjet constitue sans doute
la voie davenir pour les bases de donnes, comme pour bien dautres domaines. Des
standards de reprsentation se dveloppent au niveau des applications selon les techniques de modlisation oriente objet, en particulier les standards XML, SGML,
EXPRESS et CMIS/CMIP respectivement pour le WEB, la gestion de donnes techniques, la CAO et ladministration de rseaux. Ces langages de modlisation de documents ou de composants semblent bien adapts aux bases de donnes objets.
Lapproche objet reste cependant limite, car elle ncessite de bien connatre les
objets pour en dfinir le type. Fond sur un typage fort, lobjet est peu adapt pour
aborder les applications donnes faiblement structures, comme le Web. Des extensions sont ncessaires.
6. BIBLIOGRAPHIE
[Abiteboul95] Abiteboul S., Foundations of databases, Addison-Wesley, Reading,
Mass., 1995.
Ce livre prsente les fondements thoriques des bases de donnes en faisant le
lien avec des domaines de recherche connexes, tels que la logique et la complexit. Il fait le point sur les problmes avancs des bases de donnes, notamment sur le couplage des modles dductifs et objets.
[Abiteboul87] Abiteboul S., Beeri C., On the Power of Languages for the
Manipulation of Complex Objects , International Workshop on Theory and
Applications of Nested Relations and Complex Objects, 1987, aussi rapport
INRIA n 846, Paris, mai 1988.
Cet article prsente une vue densemble thorique mais progressive des algbres
pour objets complexes. Il discute de la puissance des langages rsultants.
[Arnold96] Arnold K., Gosling J., Le Langage Java, International Thomson
Publishing France, Traduction de The Java Programming Language par S.
Chaumette et A. Miniussi, Addison Wesley Pub., 1996.
Ce livre est la rfrence sur le langage Java, par les inventeurs. Il inclut une
brve introduction au langage et une prsentation dtaille des commandes,
constructions et bibliothques. Sont couverts les aspects dfinition de classes et
dinterfaces, traitement des exceptions, multitche, package, classes systmes
et bibliothques.
[Atkinson89] Atkinson M., Bancilhon F., DeWitt D., Dittrich K., Maier D.,
Zdonick S., The Object-Oriented Database System Manifesto , Deductive
and Object-Oriented Databases Int. Conf., Kyoto, Japan, 1989.
Le fameux manifesto pour les bases de donnes pures objet. Les caractristiques
obligatoires et optionnelles des SGBDO sont prcises comme vu ci-dessus.
[Banerjee87] Banerjee J., Kim W., Kim H.J., Korth. H.F., Semantics and
Implementation of Schema Evolution in Object-Oriented Databases , ACM
SIGMOD Int. Conf., San Fransisco, Cal., 1987.
Cet article pose les problmes de modification de schmas dans les bases de
donnes objets: suppression ou addition dattributs, de mthodes, de surclasses, etc. Les solutions retenues dans ORION, qui permettent une grande
souplesse condition de respecter des rgles prcises (par exemple, pas de
cycle de gnralisation), sont prsentes.
[Bouzeghoub85] Bouzeghoub M., Gardarin G., Mtais E., SECSI: An Expert
System for Database Design , 11 th Very Large Data Base International
Conference, Morgan Kaufman Pub., Stockolm, Sude, 1985.
Cet article dcrit le systme SECSI bas sur un modle smantique appel
MORSE. MORSE supporte lagrgation, la gnralisation, lassociation et
linstanciation. SECSI est construit selon une architecture systme expert. Cest
un outil daide la conception de bases de donnes relationnelles qui transforme le modle smantique en relations normalises. Le modle smantique
est labor partir de langages quasi naturels, graphiques ou de commande.
[Bouzeghoub91] Bouzeghoub M., Mtais E., Semantic Modelling of Object
Oriented Databases , 17th Very Large Database International Conference,
Morgan Kaufman Pub., Barcelone, Espagne, aot 1991.
Cet article propose une mthodologie de conception de bases de donnes
objets, fonde sur un rseau smantique. Lapplication est spcifie par un langage de haut niveau bti autour dun modle smantique et permet de dfinir
des contraintes dintgrit et des rgles de comportements. Cette approche est
intgre dans la version objet du systme daide la conception SECSI.
[CACM91] Communication of the ACM, Special Issue on Next-Generation
Database Systems , Communication of the ACM, vol. 34, n 10, octobre 1991.
Ce numro spcial des CACM prsente une synthse des volutions des SGBD
vers une nouvelle gnration. Les produits O2 commercialis par O2 Technology,
ObjectStore commercialis par Object Design, GemStone commercialis par
Servio, et les prototypes Postgres de luniverst de Californie Berkeley et
Starbust du centre de recherche dIBM Alamaden sont dcrits en dtail.
[Cardelli84] Cardelli L., Wegner P., On Understanding Types, Data, Abstraction,
and Polymorphism , ACM Computing Surveys, vol. 17, n 4, dcembre 1985.
Vaste article de synthse sur le typage, les abstractions de type et le polymorphisme. Les conditions de typage sr, cest--dire vrifiable la compilation,
sont tudies.
[Castagna96] Castagna G., Object-Oriented Programming A Unified Foundation,
366p., Birkhauser, Boston, 1997.
Ce livre dveloppe une thorie de lorientation objet, plus spcialement du polymorphisme, qui couvre les mthodes multiclasses. Il apporte un nouvel clairage
au problme du typage des paramtres des mthodes dans les cas de surcharge et
redfinition. En clair, la nouvelle thorie en vogue dans le monde objet.
[Cattell91] Cattell R.G., The Engineering Database Benchmark , in [Gray91].
Article prsentant les rsultats du premier benchmark comparant bases de donnes objets et relationnelles. Les rsultats dmontrent la supriorit des
SGBD objets pour les parcours de graphes.
[Cluet90] Cluet S., Delobel C., Lcluse C., Richard P., RELOOP, an Algebra Based
Query Language for an Object-Oriented Database System , Data &
Knowledge Engineering, vol. 5, n 4, octobre 90.
Une prsentation du langage dinterrogation du systme O2. La smantique du
langage est base sur une algbre tendue. Bien que possdant une syntaxe
particulire, le langage est dun point de vue smantique proche dun SQL
tendu supportant des objets complexes.
[Delobel91] Delobel C., Lcluse Ch., Richard Ph., Bases de donnes : des systmes
relationnels aux systmes objets, 460 pages, Interditions, Paris, 1991.
Une tude trs complte de lvolution des SGBD, des systmes relationnels
aux systmes objets, en passant par les systmes extensibles. Une attention
particulire est porte sur les langages de programmation de bases de donnes.
Le livre dcrit galement en dtail le systme O2, son langage CO2 et les techniques dimplmentation sous-jacentes. Un livre en franais.
[Dewitt90] DeWitt D., Futtersack P., Maier D., Velez F., A Study of Three
Alternative Workstation-Server Architectures for Object-Oriented Database
Systems , 16 th Very Large Database International Conference, Morgan
Kaufman Pub., Brisbane, Australie, aot 1990.
Une tude comparative de trois architectures (serveur dobjets, de pages et de
fichiers) client-serveur pour les SGBDO. Lanalyse dmontre sommairement
que lapproche serveur de pages est plus performante sous certaines conditions
dans un contexte mono-utilisateur.
[Gardarin89] Gardarin G., Kiernan J., Cheiney J.P., Pastre D., Managing Complex
Objects in an Extensible Relational DBMS , 15th Very Large Databases International Conference, Morgan & Kaufman Ed., Amsterdam, p. 55-65, Aot 1989.
Cet article prsente le SGBD Sabrina ralis lINRIA de 1988 1990, qui fut
un des premiers SGBD relationnels intgrer lobjet. Les objets taient dfinis
comme des types abstraits dont les oprations taient programmes en LeLisp ou
en C. Ils taient intgrs au relationnel comme valeurs de domaines des tables.
Ce SGBD fut commercialis par une start-up qui fut malheureusement plus soutenue aprs 1988, les pouvoirs publics prfrant une dmarche objet pure.
[Gardarin94] Gardarin G., Nowak M., Valduriez P., Flora : A Functional-Style
Language for Object and Relational Algebra , 5th DEXA (Database and Expert
System Application) Intl. Conf., Athens, in LNCS n 856, p. 37-46, Sept. 1994.
FLORA est un langage fonctionnel permettant dcrire des plans dexcution
rsultant de la compilation de requtes objet. Il est du mme niveau quune
algbre dobjets complexes, mais bas sur une approche fonctionnelle. FLORA
manipule une riche bibliothque de collections.
[Goldberg83] Goldberg A., Robson D., Smalltalk-80: The Language and its
Implementation, Addison-Wesley, Reading, Mass., 1983.
Le livre de rfrence de Smalltalk, par les inventeurs du langage.
[Gray91] Gray J. Ed., The Benchmark Handbook, Morgan & Kaufman Pub., San
Mateo, 1991.
Le livre de base sur les mesures de performances des SGBD. Compos de diffrents articles, il prsente les principaux benchmarks de SGBD, en particulier le
[Stoustrup86] Stoustrup B., The C++ Programming Language, New York, AddisonWesley, 1986.
Le livre de rfrence de C++ par son inventeur. Stoustrup a cr C++ pour
modliser des problmes de rseaux de tlcommunications.
[WonKim88] Won Kim et. al., Features of the ORION Object-Oriented Database
System , dans le livre Object-Oriented Concepts, Applications and
Databases , W. Kim et Lochovsjy Ed., Addison-Wesley, 1988.
Une description du systme ORION, le SGBDO qui a popularis lapproche
bases de donnes objets. Dvelopp MCC ds 1985, ORION est un SGBDO
trs complet. Initialement bas sur Lisp, le produit, commercialis aujourdhui
par Itasca Systems, a volu vers C et C++.
[WonKim89] Won Kim, A Model of Queries for Object-Oriented Database , Very
Large Database International Conference, Morgan Kaufman Pub., Amsterdam,
Pays-Bas, aot 1989.
Cet article prsente les mthodes doptimisation utilises dans le systme
ORION pour le langage dinterrogation. La technique retenue est trs proche
de la restructuration darbre, considrant en plus les jointures par rfrences et
les parcours de chemins.
[WonKim90] Won Kim, Introduction to Object-Oriented Databases, 235 pages, The
MIT Press, 1990.
Ce livre dcrit les diffrentes techniques des SGBD objets. Il sinspire fortement du systme ORION. Plus particulirement, les problmes de modle
orient objet, de modification de schma, de langage SQL tendu aux objets, de
structures de stockage, de gestion de transactions, doptimisation de requtes et
darchitecture sont abords. Une bonne rfrence sur les bases de donnes
objets.
[Zaniolo85] Zaniolo C., The Representation and Deductive Retrieval of Complex
Objects , 11th Very Large Data Bases International Conference, Morgan
Kaufman Pub., Stockholm, Sude, aot 1985.
Cet article prsente une extension de lalgbre relationnelle aux fonctions permettant de retrouver des objets complexes. Des oprateurs dductifs de type
point fixe sont aussi intgrs.
[Zdonik90] Zdonik S., Maier D., Readings in Object-Oriented Database Systems,
Morgan Kaufman Pub., San Mateo, California, 1990.
Une slection darticles sur les bases de donnes objets.
Chapitre XII
LE STANDARD DE LODMG :
ODL, OQL ET OML
1. INTRODUCTION
Depuis 1988, une dizaine de petites socits commercialisent des SGBDO, avec un
succs encore limit. Elles se heurtent au problme de la portabilit des applications.
Il existe maintenant des langages de programmation objet ayant une bonne portabilit
comme C++, ou vraiment portables comme Java, qui a t conu pour tre port. Mais
porter des applications accdant des bases de donnes exige la portabilit des interfaces daccs. Ceci est possible en relationnel, avec SQL et des middlewares universels comme ODBC ou JDBC pour Java. Ceci tait trs difficile en objet devant
labsence de standards.
Ainsi, afin de dfinir des interfaces portables, sest constitu lObject Database
Management Group (ODMG), form au dpart par cinq vendeurs de SGBDO.
LODMG vise raliser pour les bases de donnes objets lquivalent de la norme
SQL, ou au moins dun projet de norme. Deux versions du standard propos ont t
publies assez rapidement : lune en 1993 [Odmg93], lautre prsente dans ce chapitre, en 1997 [Odmg97]. Un des buts des SGBDO, et donc de lODMG, est dviter
le problme soulev par les SGBD classiques o deux systmes cohabitent lors de
linterfaage avec un langage : celui du SGBD et celui du langage. Pour permettre une
utilisation directe des types des langages objet, lODMG a choisi de dfinir un modle
abstrait de dfinition de bases de donnes objet, mis en uvre par un langage appel
ODL (Object Definition Language). Ce modle est ensuite adapt un langage
objet particulier : lODMG propose un standard dintgration en C++, Smalltalk, et
Java. Un langage dinterrogation pour ce modle est propos : il sagit dOQL (Object
Query Language), pour beaucoup issu du langage de requte du systme O2 ralis
lINRIA [Bancilhon92, Adiba93]. OQL est aussi intgrable dans un langage de programmation objet.
Ce chapitre prsente le standard de lODMG, en lillustrant par des exemples. Aprs
cette introduction, la section 2 prcise le contexte et larchitecture dun SGBDO
conforme lODMG. La section 3 dveloppe le modle abstrait et le langage ODL.
La section 4 prsente un exemple de base et de schma en ODL. La section 5 aborde
le langage OQL travers des exemples et des syntaxes types de requtes constituant
des exemples gnriques, appels profils. La section 6 se consacre lintgration dans
un langage de programmation ; le cas de Java est dtaill. La section 7 conclut ce chapitre en montrant les limites du standard de lODMG.
2. CONTEXTE
Dans cette section, nous prsentons le contexte gnral du standard : les auteurs,
le contenu de la proposition et larchitecture dun systme conforme lODMG.
ODMG93. En fait, il ne sagit pas dun standard avalis par les organismes de normalisation, mais plutt dune proposition dun groupe de pression reprsentant des
vendeurs de SGBDO.
Le groupe a continu travailler et sest enrichi de reprsentants de POET Software,
UniSQL, IBEX et Gemstone Systems, ainsi que de multiples gourous et observateurs
externes. Une nouvelle version du livre a t publie en 1997, sous le titre
ODMG 2.0 ; elle comporte dix auteurs. Le groupe est maintenant bien tabli et collabore avec lOMG et lANSI, notamment sur lintgration CORBA et SQL3. Les
constructeurs participants sengagent suivre les spcifications de lODMG, malheureusement sans dates prcises. Un des checs majeurs du groupe est sans doute
labsence de systmes conformes aux nouvelles spcifications. O2, qui est le systme
le plus proche, ne rpond pas exactement aux fonctionnalits requises [Chaudhri98].
Une dfinition peut aussi tre effectue directement dans lun des langages supports.
La partie la plus intressante de la proposition est le langage OQL (Object Query
Language).
Notion XII.2 : OQL (Object Query Language)
Langage dinterrogation de bases de donnes objets propos par lODMG, bas sur des requtes
SELECT proches de celles de SQL.
Une intgration est propose avec les langages objets C++, Smalltalk et Java. Celle-ci
prcise les conversions de types effectues et permet la manipulation des objets grs par
le SGBD depuis le langage. Elle est appele OML (Object Manipulation Language).
Notion XII.3 : OML (Object Manipulation Language)
Langage de manipulation intgr un langage de programmation objet permettant la navigation,
linterrogation et la mise jour de collections dobjets persistants, dont lOMG propose trois
variantes : OML C++, OML Smalltalk et OML Java.
La figure XII.1 illustre les diffrentes interfaces proposes par le standard ODMG. Ce
sont celles permettant de raliser des applications autour dun SGBDO. Sont-elles suffisantes pour assurer la portabilit ? Probablement non, car les interfaces graphiques sont
aussi importantes et souvent spcifiques du SGBDO. Quoi quil en soit, le respect de
ces interfaces par les produits amliorerait de beaucoup la portabilit des applications.
OQL
ODL
OML Java
OML C++
OML Smalltalk
SGBDO
2.3. ARCHITECTURE
La figure XII.2 illustre larchitecture typique dun SGBDO conforme lODMG.
Autour dun noyau grant la persistance des objets, lattribution des identifiants, les
mthodes daccs, et les aspects transactionnels, gravitent trois composants : le prprocesseur ODL permet de compiler les dfinitions dobjets et de gnrer les donnes
de la mtabase ; le composant langage OML spcifique chaque langage de programmation permet de manipuler les objets conformes aux dfinitions depuis un langage
de programmation tel C++, Smalltalk ou Java ; le composant OQL comporte un analyseur et un optimiseur du langage OQL capables de gnrer des plans dexcution
excutables par le noyau. Au-dessus de ces trois composants, diffrents outils interactifs permettent une utilisation facile des bases ; ce sont par exemple un diteur de
classes pour diter les schmas ODL, un manipulateur dobjets pour naviguer dans la
base (les deux runis constituent souvent le browser), une bibliothque dobjets graphiques, des dbogueurs et diteurs pour les langages de programmation, etc.
Du ct interface avec les langages de programmation, le schma prconis est bas
sur un systme de type unique entre le langage et le SGBDO, chaque type du modle
objet du SGBDO (en principe celui de lODMG) tant traduit directement dans un
type correspondant du langage. Un principe de base est aussi de ne ncessiter aucune
modification du compilateur du langage. Les dclarations de classes persistantes peuvent tre crites en ODL, ou directement dans le langage de programmation (PL
ODL). Un prcompilateur permet de charger la mtabase du SGBDO et de gnrer la
dfinition pour le langage de programmation. Les programmes enrichis avec les dfinitions de classes dobjets persistants sont compils normalement. Le binaire rsultant
Outils interactifs
OML
OQL
ODL
Persistance
Identification
Accs
Grant d'objets
Concurrence
Fiabilit
Scurit
Application
Source en PL
Pr-compilateur
de dclarations
Compilateur
de PL
ODBMS
Runtime
Application
Binaire
diteur
de liens
Excutable
3. LE MODLE DE LODMG
Nous dcrivons maintenant le modle abstrait propos pour la dfinition des schmas
des bases de donnes objet.
Nous dfinissons par exemple figure XII.4 une interface calculateur modlisant une
machine calculer.
INTERFACE CALCULATEUR {
CLEAR();
FLOAT ADD(IN FLOAT OPERAND);
FLOAT SUBSTRACT (IN FLOAT OPERAND);
FLOAT DIVIDE(IN FLOAT DIVISOR);
FLOAT MULTIPLY (IN FLOAT MULTIPLIER);
FLOAT TOTAL();}
Une classe implmente ainsi une ou plusieurs interfaces. En plus dun comportement,
une classe dfinit un tat abstrait. Pour mmoriser les tats abstraits de ses instances,
une classe possde aussi une extension de classe.
Notion XII.6 : Extension de classe (class extent)
Collection caractrise par un nom contenant les objets crs dans la classe.
Le comportement abstrait pourra tre hrit dune interface. On voit donc quune
classe donne une spcification dune ou plusieurs interfaces en prcisant quelques lments dimplmentation, en particulier ltat des objets (abstrait car indpendant de
tout langage) et lextension qui va les contenir. Dans certains cas complexes, une
classe peut dailleurs avoir plusieurs extensions. Il est aussi possible de prciser une
cl au niveau dune extension de classe : comme en relationnel, il sagit dun attribut
dont la valeur dtermine un objet unique dans lextension. La figure XII.5 illustre une
dfinition de classe incorporant linterface calculateur.
CLASS ORDINATEUR (EXTENT ORDINATEURS KEY ID) : CALCULATEUR {
ATTRIBUTE SHORT ID ;
ATTRIBUTE FLOAT ACCUMULATEUR;
VOID START();
VOID STOP(); }.
Notez quune interface peut aussi comporter des attributs abstraits, mais ceux-ci sont
vus comme des raccourcis doprations, une pour lire lattribut, lautre pour lcrire.
Une interface na en principe pas dextension.
Interfaces et classes sont des spcifications de types. Il est aussi possible de spcifier
des types de valeurs : ceux-ci sont appels des littraux.
Les littraux correspondent aux types de base tels entier, rel, chane de caractres,
mais aussi aux structures. Un exemple de littral est un nombre complexe : struct
complex {float re; float im}. Les littraux sont directement implments comme des
types de valeurs en C++. Dans les autres langages purs objets (Smalltalk ou Java), ce
seront des objets.
En rsum, lODMG propose donc un systme de types sophistiqu, capable dtre
facilement mapp en C++, Smalltalk ou Java. Il y a donc des types, des interfaces, des
classes et des littraux. Lensemble forme la hirarchie de spcialisation reprsente
figure XII.6.
Type
Littral
Interface
Classe
Soulignons que lhritage de comportement (not :) peut tre multiple : une classe
peut implmenter plusieurs interfaces, mais elle ne peut driver que dune seule autre
classe. En cas de conflits de noms, cest lutilisateur quil incombe de distinguer les
noms.
CLASS ORDINATEURAREGISTRE EXTENDS ORDINATEUR: CALCULATEUR {
ATTRIBUTE FLOAT REGISTRE;
VOID RTOA();
VOID ATOR (); }.
INTERFACE OBJECTFACTORY {
OBJECT NEW(); // CRATION DUN NOUVEL OBJET
};
INTERFACE OBJECT {
ENUM LOCK_TYPE{READ, WRITE, UPGRADE}; // TYPES DE VERROUS
EXCEPTION LOCKNOTGRANTED(); // ERREUR VERROU REFUS
VOID LOCK(IN LOCK_TYPE MODE) RAISES (LOCKNOTGRANTED); //VERROUILLAGE
BLOQUANT
BOOLEAN TRY_LOCK(IN LOCK_TYPE MODE);// VERROUILLAGE NON BLOQUANT
BOOLEAN SAME_AS(IN OBJECT ANOBJECT); // COMPARAISON DIDENTIFIANTS
DOBJETS
OBJECT COPY(); // COPIE AVEC GENERATION DUN NOUVEL OBJET
VOID DELETE()}; // SUPPRESSION DUN OBJET
proprits (taille, vide ou non, ordre ou non, doubles permis ou non, appartenance
dun lment), pour insrer ou supprimer un lment, pour parcourir la collection par
le biais dun itrateur mono ou bidirectionnel.
INTERFACE COLLECTIONFACTORY : OBJECTFACTORY {
COLLECTION NEW_OF_SIZE(IN LONG SIZE)
};
INTERFACE COLLECTION : OBJECT {
EXCEPTION INVALIDCOLLECTIONTYPE(), ELEMENTNOTFOUND(ANY ELEMENT);
UNSIGNED LONG CARDINALITY();
BOOLEAN IS_EMPTY(),IS_ORDERED(),ALLOWS_DUPLICATES(),
CONTAINS_ELEMENT(IN ANY ELEMENT);
VOID INSERT_ELEMENT(IN ANY ELEMENT);
VOID REMOVE_ELEMENT(IN ANY ELEMENT) RAISES(ELEMENTNOTFOUND);
ITERATOR CREATE_ITERATOR(IN BOOLEAN STABLE);
BIDIRECTIONALTERATOR CREATE_BIDIRECTIONAL_ITERATOR()RAISES(INVALID
COLLECTIONTYPE);
};
Comme son nom lindique, un itrateur permet ditrer sur les lments. Pour cela, il
fournit une interface rsume figure XII.10. Un itrateur bidirectionnel permet daller
en avant, mais aussi en arrire.
INTERFACE ITERATOR {
VOID RESET() ; // INITIALISATION AU DBUT
ANY GET_ELEMENT() RAISES(NOMOREELEMENTS); // OBTENTION LMENT
VOID NEXT_POSITION RAISES(NOMOREELEMENTS); // AVANCE POSITION
REPLACE_ELEMENT (IN ANY ELEMENT) RAISES(INVALIDCOLLECTIONTYPE) ;
...
};
Object
Atomic Obj
Literal
Date
Time
Timestamp
Interval
Atomic Lit.
Long
Short
Ulong
Ushort
Float
Double
Character
Boolean
string
octet
enum <>
Collection Lit.
Structured Lit.
Set <>
Bag <>
List <>
Array <>
Dictionary <>
Structure<>
Date
Time
Timestamp
Interval
(1:1), (1:N), ou (N:M), sans donnes. Une association de A vers B dfinit deux chemins de traverse inverses, A->B et B->A. Chaque chemin doit tre dfini en ODL au
niveau du type dobjet source par une clause RELATIONSHIP. Lassociation pointe vers
un seul objet cible ou vers une collection. Elle porte un nom et son inverse doit tre
dclar. Pour la gestion, le SGBDO doit fournir des oprations sur associations telles
que Add_member, Remove_member, Traverse et Create_iterator_for.
De fait, les associations sont simplement des dclarations abstraites dattributs coupls, valus par une valeur simple ou une collection, contenant des identifiants
dobjets rciproques. La figure XII.13 illustre lassociation classique entre VINS et
BUVEURS, mais sans donnes.
INTERFACE BUVEURS {
...
RELATIONSHIP LIST<VINS> BOIRE INVERSE VINS::EST_BU_PAR;
...
};
INTERFACE VINS {
...
RELATIONSHIP SET<BUVEURS> EST_BU_PAR INVERSE BUVEURS::BOIRE;
...
};
INTERFACE BUVEURS {
...
INT BOIRE(IN VINS V, IN INT QTE) RAISES(NOVINS); //SIGNATURE DE
LOPRATION
...
};
Class
Instantiate
key_list
extent_name
super_class
*
1
*
OID
has_name
names
class
create
delete
exits
same_has?
Property
Attribute
attr_name
attr_type
set_value
get_value
Operation
signature
invoke
return
return_abnormally
Has
Object
Extends
Traversal path
path_name
to_cardinality
to_type
traverse
creator_iterator
2
Relationship
Define
1
add_member
remove_member
Habite
Voiture
nveh
couleur
marque
km
rouler()
Possde
Appart.
Personne
nss
nom
prenom
datenais
vieillir()
dormir()
Loge
Infrieur
Boire
Employ
*
Suprieur
tage
no
rue
code
ville
fonction
salaire
primes
travailler()
Buveur
type
tat
boire()
Vin
*
Bu_par cru
millsime
degr
qualit
EmployBuveur
short vieillir();
void dormir()
short age(); };
class Employ : Personne(extent Employs key nss) { //classe avec extension
attribute enum fonct{ingnieur, secrtaire, analyste, programmeur}
fonction;
attribute float salaire ;
attribute list<float> primes ; //attribut multi-valu
relationship Set<Employ> inferieur inverse suprieur;
relationship Employ suprieur inverse infrieur;
void travailler(); };
class Buveur : Personne(extent buveurs key nss) { // classe avec extension
attribute typebuv{petit,moyen,gros} type;
attribute etabuv{normal,ivre} etat;
relationship list<Vin> boire inverse vin::bu_par;
void boire(in Vin v); // paramtre dentre v };
class Appart (extent Apparts) { // classe avec extension
attribute struct adresse (short etage, unsigned short numero, string rue,
unsigned short code, string ville);
relationship Set<personne> loge inverse Personne::habite; };
class Vin (extent Vins) { // classe avec extension
attribute string cru;
attribute string millesime;
attribute string degre;
attribute string qualite;
relationship list<Buveur> bu_par inverse Vin::boire; };
class EmployBuveur extends Employ { // classe sans extension hrite
de employ
attribute typebuv{petit,moyen,gros} type;
attribute etabuv{normal,ivre} etat;
relationship list<Vin> boire inverse vin::bu_par;
void boire(in Vin v); // paramtre dentre v
};
Une dcision prendre lors de la dfinition est de choisir entre interfaces et classes.
Certaines classes peuvent avoir des extensions. Nous avons choisi dimplmenter les
extensions de Voiture, Vin, Appartement, Buveur et Employ. Personne
devient une interface. Lhritage multiple ntant pas possible au niveau des classes,
les employs buveurs sont des employs avec les proprits de buveurs rptes. On
aurait pu viter cette rptition en dfinissant une interface Buveurs, puis une classe
CBuveurs implmentant cette interface. Nous ne lavons pas fait pour ne pas perturber
le lecteur. Le bon choix est probablement de dfinir des interfaces pour tout ce qui est
visible lextrieur, puis de raliser ces interfaces par des classes.
5. LE LANGAGE OQL
Cette section dtaille le langage de requtes OQL et introduit des profils de requtes
typiques.
point de vue typage. OQL nest pas seulement un langage dinterrogation, mais bien
un langage de requtes avec mises jour. En effet, il est possible de crer des objets et
dinvoquer des mthodes mettant jour la base.
OQL permet aussi la navigation via les objets lis de la base, mais seulement avec des
expressions de chemins monovalues.
Il est possible de naviguer par des expressions de chemins un peu particulire,
rduites des chemins simples, que lon dfinira comme suit :
Notion XII.8 : Expression de chemin monovalu (Monovalued path expression)
Squence dattributs ou dassociations monovalues de la forme X1.X2Xn telle que chaque Xi
lexception du dernier contient une rfrence un objet ou un littral unique sur lequel le suivant
sapplique.
Par exemple, chaque buveur rfrence par lassociation Boire une liste de Vins. Si B
est un buveur, B.Boire est une collection dpendante, ici une collection de Vins. Par
des variables ainsi lies du style B in Buveurs, V in B.Boire, OQL va permettre de
parcourir les associations multivalues. Ceci est puissant pour naviguer, mais plutt
procdural.
Pour prsenter un peu plus prcisment ce langage somme toute remarquable, nous
procdons par des exemples un peu gnraliss. Avant de les lire, il est bon de se rappeler que dans toute syntaxe une collection peut tre remplace par une requte produisant une collection. Rciproquement, il est possible de crer des collections intermdiaires et de remplacer chaque sous-requte par une collection intermdiaire. Cela
peut permettre de simplifier des requtes nombreuses sous-requtes imbriques.
optionnel, [a]* signifie une liste de 0 N a spars par des virgules, [a]+ de 1 N a
spars par des virgules, {a|b} signifie un choix entre a ou b, et... indique une syntaxe
libre compatible avec celles dj introduites. Cette syntaxe peut servir de profil (les
patterns sont la mode) pour formuler un type de requte. Nous appelons aussi
lexpression syntaxique un profil, ou plus simplement un format. Chaque profil est
prcd dun nom de trois lettres suivi de : servant de rfrence pour un usage
ultrieur ventuel. Nous donnons aussi le type du rsultat infr par le compilateur
(aprs la requte, sous forme ===> type). Le langage tant complexe, nous ne donnons pas une dfinition, celle-ci pouvant tre trouve dans [ODMG97]. Il y en a
dailleurs deux, une formelle, une autre en BNF, et elles ne semblent pas totalement
cohrentes !
Ceci donne en principe la chane 25TOTO . Cette requte montre la fois le calcul
dexpressions et les conversions de type. Son profil syntaxique est :
PEX: (<TYPE>) <EXPRESSION>
o lexpression peut tre calcule avec tous les oprateurs classiques (+, *, , /, mod,
abs, concatnation). Plus gnralement, lexpression peut aussi tre une collection
dobjets, et donc une requte produisant une telle collection, comme nous en verrons
beaucoup ci-dessous.
Plus gnralement, OQL permet de naviguer dans la base en parcourant des chemins
monovalus, comme vu ci-dessus. Par exemple, la question (Q2) retourne le nom du
propritaire de ma voiture (en principe, Gardarin !) :
(Q2) MAVOITURE.APPARTIENT.NOM
===> LITTRAL STRING
Le profil syntaxique dune requte de slection avec un ou plusieurs critres de slection et une ou plusieurs jointures est :
(PSJ) SELECT [<VARIABLE>.<ATTRIBUT>]+
FROM <VARIABLE> IN <COLLECTION>,[<VARIABLE> IN <COLLECTION>]+
[WHERE <VARIABLE>.<ATTRIBUT> <COMPARATEUR> <VARIABLE>.<ATTRIBUT>
[AND <VARIABLE>.<ATTRIBUT> <COMPARATEUR> <VARIABLE>.<ATTRIBUT>]*
[{AND|OR} <VARIABLE>.<ATTRIBUT> <COMPARATEUR> <CONSTANTE>]]*
De manire gnrale, les qualifications peuvent faire intervenir, comme en SQL, des
AND et des OR, et des expressions parenthses contenant ces connecteurs logiques.
Une question quivalente peut utiliser le type EMPLOYEBUVEUR comme suit :
(Q5) SELECT ((EMPLOYBUVEUR)B).NOM, ((EMPLOYBUVEUR)B).PRENOM
FROM B IN BUVEURS
WHERE B.TYPE = GROS
==> LITTRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>
Lvaluateur doit alors vrifier lexcution lappartenance des gros buveurs trouvs
la classe des EMPLOYEBUVEUR.
Le profil de telles questions avec indicateurs de classe est :
PIC: SELECT [((<CLASSE>)<VARIABLE>).<ATTRIBUT>]+
FROM...
[WHERE...]
Bien sr, la clause WHERE peut tre compose de slections, de jointures, etc.
Par similarit avec SQL, la collection rsultat est un BAG. Il est aussi possible dobtenir une collection de type SET en rsultat ; on utilise alors le mot cl DISTINCT,
comme en SQL :
(Q8) SELECT DISTINCT (NAME: B.NOM, CITY: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.NOM = DUPONT
===> LITTRAL SET <STRUCT(NAME, CITY)>
(SELECT [DISTINCT]
[STRUCT] ([<ATTRIBUT>: <VARIABLE>.<CHEMIN>]+)
FROM...
[WHERE...])
[DISTINCT]...,
[<VARIABLE>.<CHEMIN>.<OPERATION>([<ARGUMENT>]*)]*
FROM...
[WHERE....
[AND<VARIABLE>.<CHEMIN>.<OPERATION>([<ARGUMENT>]*) <COMPARATEUR>
<CONSTANTE>]*]
NOM:JEAN, SALAIRE:100000).
Plus gnralement, il est possible demployer tous les buveurs sans emploi par la
requte suivante :
(Q14) EMPLOY(SELECT STRUCT(NSS : B.NSS, NOM: B.NOM, SALAIRE : 4000)
FROM B IN BUVEURS
WHERE NOT EXIST E IN EMPLOYS : E.NSS=B.NSS)
==> BAG<EMPLOYS> INSR DANS EMPLOYS
Notez que cette requte utilise une quantification que nous allons expliciter plus loin.
Le profil gnral de ces requtes de cration dobjets est donc :
PCO : <CLASSE>(<QUESTION>).
PAG: SELECT...[<AGGREGAT>(<ATTRIBUT>)]*
FROM...
[WHERE...]
GROUP BY {<ATTRIBUT>+ | <PREDICAT>+}
HAVING <PRDICAT>
AGGREGAT dsigne une fonction dagrgats choisie parmi COUNT, SUM, MIN, MAX et
AVG. PREDICAT dsigne un prdicat expression logique de prdicats simples de la
forme <ATTRIBUT>
<COMPARATEUR>
<CONSTANTE> ou
<AGGREGAT>(PARTITION) <COMPARATEUR> <CONSTANTE>. On voit donc
que OQL gnralise les agrgats de SQL2 en permettant de grouper par prdicats
explicites. Cest aussi possible en SQL3 avec dautres constructions.
5.2.14.1. Tris
La premire syntaxe tait fonctionnelle. La nouvelle est copie sur SQL, comme suit :
(Q19) SELECT E.NOM, E.SALAIRE
FROM E IN EMPLOYS
WHERE E.SALAIRE > 21000
ORDER BY DESC E.SALAIRE
Les priorits sont selon lordre indiqu, les parenthses tant aussi possibles.
au type de collection. Les constructeurs de collections struct, set, list, bag, array sont
aussi utilisables pour construire des collections comme nous lavons dj vu. Ainsi :
(Q21) SELECT B.NOM, FIRST(B.BOIRE)
FROM B IN BUVEURS
Les collections apparaissant en rsultat de requtes sont parfois imbriques. Les collections peuvent tre aplaties laide de loprateur FLATTEN. Par exemple :
(Q23) FLATTEN (SELECT B.NOM, SELECT V.MILLSIME
FROM V IN B.BOIRE
WHERE V.CRU = VOLNAY
FROM B IN BUVEURS)
slectionne simplement des doublets nom de buveurs et millsime de Volnay pour les
buveurs ayant bu du Volnay.
En gnral, les profils permis sont donc :
PCO : LISTTOSET(<COLLECTION>)|
ELEMENT(<COLLECTION>)|
DISTINCT(<COLLECTION>)|
FLATTEN(<COLLECTION>)
LODMG propose trois intgrations de son modle et de son langage de requtes, une
pour C++, une autre pour Smalltalk, une enfin pour Java. Autrement dit, la vision de
lusager dune BD conforme aux spcifications de lODMG est prcise pour ces trois
langages objet. Les objectifs essentiels de ces propositions sont :
1. La fourniture dun systme de types unique lutilisateur. En principe, le systme de types utilis est celui du langage de programmation parfois tendu, par
exemple avec des collections. En effet, les vendeurs de SGBDO ayant longtemps
dcri les SGBD relationnels pour lhtrognit des types des langages de programmation et de SQL, ils se devaient dviter cet cueil.
2. Le respect du langage de programmation. Cela signifie que ni la syntaxe ni la
smantique du langage ne peuvent tre modifies pour accommoder la manipulation des donnes. Des classes supplmentaires seront gnralement fournies, mais
le langage de base ne sera pas modifi.
3. Le respect du standard abstrait ODMG. Ceci signifie que lintgration propose
doit donner accs toutes les facilits abstraites du modle ODMG et de son langage de requtes OQL. Ce principe nest que partiellement suivi dans ltat actuel
du standard, certaines facilits ntant pas supportes, par exemple les associations
en Java. Mais ceci devrait tre le cas dans une future version.
Pour illustrer ces principes, nous traitons ci-dessous de lintgration Java, celles
avec les autres tant similaires, mais un peu plus complexes. Auparavant, nous allons
discuter des interfaces gnrales de gestion des bases de donnes et des transactions
qui doivent tre fournies.
SGBDO : dfinir la classe en ODL et crire un compilateur ODL gnrant des dfinitions de classes Java, avoir un prprocesseur reconnaissant les classes persistantes ou
ajouter une interface spcifique de persistance ces classes, etc. Le standard actuel ne
se prononce pas sur le moyen de dclarer une classe Java persistante. De telles classes
sont supposes existantes et connues du SGBDO. Elles peuvent alors contenir des
objets persistants, mais aussi toujours des objets transients.
Alors, comment rendre un objet (dune classe persistante) persistant ? Le mcanisme
retenu est la persistance par atteignabilit. Les racines de persistance sont les objets
nomms au moyen de lopration bind de linterface base de donnes vue ci-dessus.
Tout objet rfrenc par un objet persistant est persistant. Tout objet non rfrenc par
un objet persistant doit tre dtruit automatiquement de la base, ce qui sous-entend
lexistence dun ramasse-miettes sur disques. Au-del, le standard propose que les
objets persistants puissent conserver des attributs non persistants, ce qui nest sans
doute pas simple dclarer sans modifier Java.
De manire plus complte, une classe OQLQuery est propose afin de composer des
requtes paramtres OQL sous forme dobjets, de demander leur excution et de
rcuprer les rsultats dans des objets Java, en gnral des collections. La classe
OQLQuery comporte plus prcisment les oprations :
OQLQuery(String question) pour crer des requtes avec le texte paramtr (les paramtres sont nots $i) en OQL pass en argument ;
OQLQuery() pour crer des requtes gnriques, le texte tant pass ensuite par
lopration create(String query) ;
bind(Object parameter) pour lier le premier paramtre non encore li de la
requte ;
execute() pour excuter une requte pralablement construite et rcuprer un
objet Java de type collection ou simple en rsultat.
Voici une illustration simple de cette classe pour retrouver les buveurs dun cru quelconque, par exemple de Volnay ; Java ne supportant pas les associations, on supposera
que lattribut Boire de buveurs est implment comme une collection de vins :
SET BUVEURSCRU;
QUERY = OQLQUERY
6.3.6. Bilan
Java OML propose une vision simple dune base de donnes ODMG en Java. La premire version de cette proposition est assez brivement dcrite dans le standard. Nous
en avons donn un aperu ci-dessus. La cl du problme semble tre dans le support
des collections en Java, qui est loin dtre standard. Le problme de lODMG pourrait
tre terme de faire concider son standard avec le standard Java, notamment pour les
collections. Sinon, il y aurait vraiment opposition de phase (impedance mismatch), ce
qui serait paradoxal ! Ceci ne serait cependant pas tonnant, car peut-on construire
deux standards (un pour les bases de donnes, lautre pour le langage) indpendamment et conserver un systme de type unique ? Une meilleure approche est probablement de dvelopper un langage de programmation bas sur les types du SGBD pour
viter les problmes de conversion de types. Cest ce que propose SQL3, comme nous
le verrons dans le chapitre qui suit.
7. CONCLUSION
Depuis 1991, les vendeurs de SGBDO tentent de crer un standard afin dassurer la
portabilit des programmes utilisateurs, donc des applications. Cette dmarche est
importante car elle seule peut garantir la prennit de lapproche bases de donnes
objet pour les utilisateurs. Deux versions de ce standard ont t publies, lune en
1993, lautre en 1997. Nous nous sommes bass sur la version 1997 (ODMG 2.0)
pour crire ce chapitre. Bien que remarquable, la version 2 est quelque peu complexe
et nest gure supporte par les systmes actuels (ni dailleurs celle de 1993). Aussi,
elle est parfois ingale dans le niveau de dtails fourni. Elle se compose dun modle
abstrait de bases de donnes objet et dinterfaces concrtes pour chacun des langages
supports.
En outre, le langage de requtes OQL constitue une contribution importante de cette
proposition. OQL offre les fonctionnalits du SQL de base avec en plus des extensions pour manipuler les expressions de chemins, les mthodes et surtout les collections. Cest un langage trs puissant, mais complexe, qui a aussi quelques dficiences,
comme labsence de contrle de droits et de gestion de vues. Il peut tre intgr
C++, Smalltalk et Java de manire standard. Tout ceci est positif.
Alors, peut-on enfin parler de portabilit des applications des SGBDO, par exemple
crites en Java ? Il y a pour linstant peu de retour dexpriences. De plus, les vendeurs de SGBDO, lexception sans doute de O2, nimplmentent pas OQL et ne se
soucient finalement gure plus que dans le discours du standard ODMG. Pour garantir
une certaine portabilit, il faut donc utiliser du pur Java, sans requte. Cest encore
faible. Mais que les adeptes des langages objets, et particulirement les dfenseurs de
Java se rassurent : il ny a pas besoin de SGBDO conforme lODMG pour faire persister et retrouver des objets Java et garantir la portabilit des applications. JDBC,
dvelopp par SunSoft, est un package vraiment standard pour faire persister et
retrouver via SQL des objets Java dans toute base de donnes, y compris dailleurs
certaines bases de donnes objet. Vous pouvez aussi regarder du ct de Persistant
Java et dinterfaces plus spcifiques comme JSQL.
8. BIBLIOGRAPHIE
[Adiba93] Adiba M., Collet C., Objets et Bases de Donnes : Le SGBD O2, Herms,
Paris, 1993.
Cet ouvrage de 542 pages dcrit la gnration des SGBD objet et dtaille plus
particulirement le SGBD O2. Il dcrit tout le cycle dutilisation de ce SGBD et
les principaux composants du systme.
[Bancilhon89] Bancilhon F., Cluet S., Delobel C., A Query Language for an ObjectOriented Database System , In 2nd Intl. Workshop on Database Programming
Language, DBPL, p. 301-322, 1989.
Cet article introduit la premire version du langage de requtes du systme O2,
prcurseur du langage OQL. Cette version souligne les aspects fonctionnels du
langage.
[Bancilhon92] Bancilhon F., Delobel C., Kanellakis P., Building an Object-Oriented
Database System : The Story of O2, Morgan Kaufmann Pub., San Fransisco,
CA, 1992.
Ce livre est une collection darticles prsentant lhistoire, la conception et
limplmentation du systme O2, un des premiers SGBD pur objet.
[Chaudhri98] Chaudhri A.B., Workshop Report on Experiences Using Object Data
Management in the Real-World , SIGMOD Record, V. 27, n 1, p. 5-10, Mars
1998.
Cet article rsume les prsentations effectues un Worshop portant sur les
applications relles des BD objet. Il discute en particulier de quelques insuffisances dObjectStore et des multiples diffrences entre O2 et le standard ODMG.
[Ferrandina95] Ferrandina F., Meyer T., Zicari R., Ferran G., Madec J., Schema and
Database Evolution in the O2 Object Database System , Proc. of 21st Intl.
Conf. On Very Large Databases, Zurich, p. 170-181, 1995.
Cet article souligne la difficult dvolution des schmas ODL dans une base
de donnes objet. Il dcrit les algorithmes implments dans O2 pour faire voluer la base en conformit au schma.
[Fishman88] Fishman et. al., Overview of the IRIS DBMS, Hewlett-Packard Internal
Report, Palo Alto, 1988.
Cet article prsente le systme IRIS et son langage OSQL. OSQL est une version fonctionnelle dun SQL tendu aux objets. OSQL est un langage qui permet de dfinir des types abstraits comme des ensembles de fonctions, de crer
des classes dobjets accessibles par des fonctions, puis dappliquer ces fonctions en les imbriquant partir darguments ventuellement instancis. Il sagit
dun des premiers SQL tendus aux objets bas sur une approche fonctionnelle,
donc un prcurseur de OQL.
[ODMG93] Cattell R. (Ed.), Object Databases : The ODMG-93 Standard, MorganKaufman, San Mato, CA, 1993.
Ce livre prsente la premire version du standard ODMG pour les bases de
donnes. Il dcrit le modle objet, le langage de dfinition ODL, le langage de
requtes OQL et les interfaces avec C++ et Smalltalk.
[ODMG97] Cattell R.G.G., Barry D., Bartels D., Berler M., Eastman J.,
Gammerman S., Jordan D., Springer A., Strickland H., Wade D., Object
Database Standard : ODMG 2.0, Morgan Kaufmann Pub., San Fransisco, CA,
1997.
Ce livre prsente la deuxime version du standard ODMG dcrit dans ce chapitre. Il inclut tous les aspects tudis et donne le dtail des spcifications de
ODL, OQL, OML C++, Smalltalk et Java.
[Won Kim95] Won Kim, Modern Database Systems, Addison-Wesley, New-York,
1995.
Cette collection darticles sur les BD objets aborde tous les aspects dun SGBD
objet, en particulier les interfaces avec les langages objet (OQL-C++) ainsi
que les promesses et dceptions des systmes purs objet.
Chapitre XIII
LOBJET-RELATIONNEL ET SQL3
1. INTRODUCTION
Le dveloppement des SGBD objet sest rapidement heurt la ncessit de conserver
la compatibilit avec lexistant. En effet, la fin des annes 80 a vu le dploiement des
SGBD relationnels et des applications client-serveur. Les utilisateurs ntaient donc
pas prts remettre en cause ces nouveaux systmes ds le dbut des annes 90.
Cependant, les tables relationnelles ne permettaient gure que la gestion de donnes
alphanumriques. Avec lavnement du Web au milieu de la dcennie 90, la ncessit
de supporter des donnes complexes au sein de la base de donnes sest amplifie.
Ces donnes complexes peuvent tre des documents textuels, des donnes gomtriques ou gographiques, audiovisuelles ou soniques. En bref, il sagit de supporter
de manire intelligente des donnes multimdia (voir figure XIII.1).
Ce chapitre est consacr ltude du modle objet-relationnel et du langage de
requtes associ SQL3. SQL3 est une extension de SQL2, dveloppe par le groupe
de normalisation ANSI X3 H2 et internationalise au niveau de lISO par le groupe
ISO/IEC JTC1/SC21/WG3. Il sagit de la nouvelle version de SQL. SQL3 comporte
beaucoup daspects nouveaux, lessentiel tant sans doute son orientation vers une
intgration douce de lobjet au relationnel. Ce chapitre traite en dtail de cette intgration et survole les autres aspects de SQL3.
Types de
donnes
ABC123
Temps
1996
riques. Le concept de table dont les lignes constituent les enregistrements successifs
est simple, bien adapt pour reprsenter par exemple des employs, des services, ou
des paiements. Avec SQL2, les domaines se sont diversifis. Les dates, les monnaies,
le temps et les intervalles de temps sont parfaitement supports.
Dans les annes 80, les SGBD relationnels se sont centrs sur le transactionnel (On
Line Transaction Processing OLTP) et sont devenus trs performants dans ce
contexte. Les annes 90 ont vu le dveloppement du dcisionnel (On Line Analysis
Processing OLAP). Le relationnel sest montr capable dintgrer la prsentation
multidimensionnelle des donnes ncessaire lOLAP. En effet, il est simple de coder
un cube 3D en table, trois colonnes mmorisant les valeurs dune dimension et la quatrime la grandeur analyse.
En bref, grce au langage assertionnel puissant que constitue le standard universel
SQL2, sa bonne adaptation aux architectures client-serveur de donnes, sa thorie
bien assise aussi bien pour la conception des bases (normalisation), loptimisation de
requtes (algbre, rcriture, modle de cots) et la gestion de transactions (concurrence, fiabilit) intgre, le relationnel sest impos dans lindustrie au cours des
annes 80.
Les objets longs prsentent deux inconvnients majeurs : ils ne sont pas structurs et
ne supportent pas les recherches associatives. La seule possibilit est de les lire
squentiellement. Ils sont donc particulirement insuffisants pour le stockage intelligent de documents structurs, o lon souhaite accder par exemple une section sans
faire dfiler tout le document. En clair, il faut pouvoir lever la contrainte datomicit
des domaines, serait-ce que pour stocker des attributs composs (par exemple
ladresse compose dune rue, dun code postal et dune ville) ou multivalus (par
exemple les points dune ligne).
La non intgration des oprations dans le modle relationnel constitue un manque.
Celui-ci rsulte dune approche traditionnelle o lon spare les traitements des donnes. Certes, les procdures stockes ont t introduites dans le relationnel pour les
besoins des architectures client-serveur, mais celles-ci restent spares des donnes.
Elles ne sont pas intgres dans le modle. Il est par exemple impossible de spcifier
des attributs cachs de lutilisateur, accessibles seulement via des oprations manipulant ces attributs privs.
Tout ceci conduit un mauvais support des applications non standard telles que la
CAO, la CFAO, les BD gographiques et les BD techniques par les SGBD relationnels. En effet, ces applications grent des objets structures complexes, composs
dlments chans souvent reprsents par des graphes. Le relationnel pur est finalement mal adapt. Il en va de mme pour le support dobjets multimdia que lon souhaite pouvoir rechercher par le contenu, par exemple des photos que lon souhaite
retrouver partir dun portrait robot.
Lencapsulation des donnes permet disoler certaines donnes dites prives par des
oprations et de prsenter des interfaces stables aux utilisateurs. Ceci facilite lvolution des structures de donnes qui peuvent changer sans modifier les interfaces
publiques seules visibles des utilisateurs. Au lieu doffrir des donnes directement
accessibles aux utilisateurs, le SGBD pourra offrir des services cachant ces donnes,
beaucoup plus stables et complets. Ceux-ci pourront plus facilement rester invariants
au fur et mesure de lvolution de la base de donnes.
Lhritage doprations et de structures facilite la rutilisation des types de donnes. Il permet plus gnralement ladaptation de composants son application. Les
composants pourront tre des tables, mais aussi des types de donnes abstraits, cest-dire un groupe de fonctions encapsulant des donnes caches. Il sera dailleurs possible de dfinir des oprations abstraites, qui pourront, grce au polymorphisme, porter le mme nom mais sappliquer sur des objets diffrents avec pour chaque type
dobjet un code diffrent. Cela simplifie la vie du dveloppeur dapplications qui na
plus qu se soucier doprations abstraites sans regarder les dtails dimplmentation
sur chaque type dobjet.
EXEMPLE
Chef
Adresse
24
Paul
Versailles
25
Patrick
Paris
Employs
Dpenses
Nom
Age
NDep
Montant
Motif
Pierre
45
2 600
Livres
Marie
37
8 700
Mission
14 500
Portable
Nom
Age
NDep
Montant
Motif
Eric
42
3 000
Livres
Julie
51
4 000
Mission
3. LE MODLE OBJET-RELATIONNEL
Le modle objet-relationnel est fond sur lide dextension du modle relationnel
avec les concepts essentiels de lobjet (voir figure XIII.3). Le cur du modle reste
donc conforme au relationnel, mais lon ajoute les concepts cls de lobjet sous une
forme particulire pour faciliter lintgration des deux modles.
Types utilisateurs
et encapsulation
Rfrence
et identit
Relationnel
Hritage
et rutilisation
Collection
et objets complexes
Le systme de type du SGBD devient donc extensible, et nest plus limit aux types
alphanumriques de base, comme avec le relationnel pur et SQL2. On pourra par
exemple dfinir des types texte, image, point, ligne, etc. Les types de donnes dfinissables par lutilisateur sont appels types abstraits (ADT) en SQL3. La notion de
type abstrait fait rfrence au fait que limplmentation est spcifique de lenvironnement : seule linterface dun type utilisateur est visible.
Notion XIII.5 : Patron de collection (Collection template)
Type de donnes gnrique permettant de supporter des attributs multivalus et de les organiser
selon un type de collection.
Les SGBD objet-relationnels offrent diffrents types de collections, tels que le tableau
dynamique, la liste, lensemble, la table, etc. Le patron LISTE(X) pourra par
exemple tre instanci pour dfinir des lignes sous forme de listes de points : LIGNE
LISTE(POINT).
Notion XIII.6 : Rfrence dobjet (Object Reference)
Type de donnes particulier permettant de mmoriser ladresse invariante dun objet ou dun tuple.
Les rfrences sont les identifiants dobjets (OID) dans le modle objet-relationnel.
Elles sont en thorie des adresses logiques invariantes qui permettent de chaner directement les objets entre eux, sans passer par des valeurs ncessitant des jointures.
Notion XIII.7 : Hritage de type (Type inheritance)
Forme dhritage impliquant la possibilit de dfinir un sous-type dun type existant, celui-ci hritant
alors de la structure et des oprations du type de base.
Lhritage de type permet donc de dfinir un sous-type dun type SQL ou dun type
utilisateur. Une table correspondant un type sans opration, lobjet-relationnel permet aussi lhritage de table.
Notion XIII.8 : Hritage de table (Table inheritance)
Forme dhritage impliquant la possibilit de dfinir une sous-table dune table existante, celle-ci
hritant alors de la structure et des ventuelles oprations de la table de base.
En rsum, le modle objet-relationnel conserve donc les notions de base du relationnel (domaine, table, attribut, cl et contrainte rfrentielle) auxquelles il ajoute les
concepts de type utilisateur avec structure ventuellement prive et oprations encapsulant, de collections supportant des attributs multivalus (structure, liste, tableau,
ensemble, etc.), dhritage sur relations et types, et didentifiants dobjets permettant
les rfrences inter-tables. Les domaines peuvent dornavant tre des types utilisateurs. La figure XIII.4 illustre tous ces concepts. Deux vues sont possibles : la vue
relationnelle dans laquelle les relations sont des relations entre objets (voir
figure XIII.5), chaque colonne tant en fait value par un objet ; la vue objet (voir
figure XIII.6) o une ligne dune table peut correspondre un objet simple (un tuple)
ou complexe (un tuple avec des attributs complexes).
OBJET
Accident
Rapport
Photo
Polymorphisme
Types
utilisateurs
RELATIONNEL
Domaine
Table
Attribut
Cl
Rfrence
Opration
134
Collections
219
Identifiant
037
Hritage
Police
24
Nom
Paul
Adresse
Paris
Conducteurs
Conducteur
ge
Paul
45
Robert
17
Accidents
Accident
Rapport
Photo
134
219
037
Objet Police
laddition), le support automatique de lhritage, le parcours de rfrences, la constitution de tables imbriques en rsultat, etc. Nous tudierons ces diffrentes fonctionnalits laide dexemples.
Partie
Contenu
Titre
Description
le cadre
SQL/Framework
les fondements
SQL/Foundation
linterface client
SQL/CLI
SQL/PSM
Le langage de spcification
de procdures stockes.
lintgration
SQL/Bindings
aux langages classiques
la gestion du temps
SQL/Temporal
abandonn
SQL/MED
10
lintgration
aux langages objet
SQL/OBJ
4.3. LA BASE
Le composant 2 contient lessentiel du langage SQL3, en particulier les fonctionnalits de base pour dfinir les autres composants (Basic SQL/CLI capabilities, Basic
SQL/PSM capabilities), les dclencheurs (Triggers), les types utilisateurs appels
types abstraits (Abstract Data Types) et les fonctionnalits orientes objets que nous
allons tudier en dtail ci-dessous. Un mot sur les dclencheurs : bien que partie intgrante du relationnel tudie en tant que telle au chapitre VIII, les dclencheurs ne
sont normaliss que dans SQL3. Il sagit l de combler une lacune de la normalisation.
Types
simples
Numrique
Caractres
Date
245
Georges
20-Dec-98
Texte
Types
multimdia
Spatial
Image
Vido
Spcialis
Spcifique application
Une instance dun type peut tre un objet ou une valeur. Un objet possde alors un
OID et peut tre rfrenc. Une valeur peut simplement tre copie dans une ligne
dune table. Un type possde en gnral des colonnes, soit directement visibles, soit
caches et accessibles seulement par des fonctions encapsulant le type. Les oprateurs
arithmtiques de SQL (+, *, , /) peuvent tre redfinis au niveau dun type. Par
exemple, on redfinira laddition pour les nombres complexes. Enfin, un type peut
possder des clauses de comparaison (=, <) permettant dordonner les valeurs et peut
tre reprsent sous la forme dun autre type, une chane de caractres par exemple.
5.1.2. Syntaxe
La syntaxe de la commande de dclaration de type est la suivante :
CREATE [DISTINCT] TYPE <NOM ADT> [<OPTION OID>] [<CLAUSE SOUS-TYPE>]
[AS] (<CORPS DE LADT>)
Le mot cl DISTINCT est utilis pour renommer un type de base existant dj, par
exemple dans la commande :
CREATE DISTINCT TYPE EURO AS (DECIMAL(9,2)
La clause :
<OPTION OID> ::= WITH OID VISIBLE
permet de prciser la visibilit de lOID pour chaque instance (objet). Par dfaut, une
instance de type est une valeur sans OID. Cette clause semble plus ou moins avoir disparue de la dernire version de SQL3, le choix tant report sur les implmentations.
La clause :
<CLAUSE SOUS-TYPE> ::= UNDER <SUPERTYPE>[,<SUPERTYPE>]
DE LADT>
La dfinition de colonne permet de spcifier les attributs du type sous la forme <NOM>
<TYPE>. Un type peut bien sr tre un type de base ou un type prcdemment cr par
une commande CREATE TYPE. Un attribut peut tre priv ou public, comme en
C++. La clause gale permet de dfinir lgalit de deux instances du type, alors que
la clause infrieure dfinit le comparateur <, important pour comparer et ordonner les
valeurs du type. La clause CAST permet de convertir le type dans un autre type.
Plusieurs clauses CAST sont possibles.
Une dclaration de fonction permet de dfinir les fonctions publiques qui encapsulent
le type. Il existe diffrents types de fonctions : les constructeurs permettent de
construire des instances du type ; ils portent en gnral le nom du type ; les acteurs
agissent sur une instance en manipulant les colonnes du type ; parmi les acteurs, il est
possible de distinguer les observateurs qui ne font que lire ltat et les mutateurs qui
le modifient ; les destructeurs dtruisent les instances et doivent tre appels explicitement pour rcuprer la place disque (pas de ramasse-miettes). Plus prcisment, la
syntaxe dune dfinition de fonction est la suivante :
<DCLARATION DE FONCTION> ::=
[<FUNCTION TYPE>] FUNCTION <FUNCTION NAME> <PARAMETER LIST>
RETURNS <FUNCTION RESULTS>
{ <SQL PROCEDURE> | <FILE NAME> } END FUNCTION
Les fonctions SQL3 ne sont pas forcment associes un type ; elles peuvent aussi
tre associes une base ou une table. Elles peuvent tre programmes en SQL, en
SQL/PSM (voir ci-dessous) ou dans un langage externe comme COBOL, C, C++ ou
Java. Comme en C++, un oprateur est une fonction portant un nom particulier et
dclare comme oprateur.
3. Sous-type :
CREATE TYPE TUDIANT UNDER PERSONNE (CYCLE VARCHAR, ANNE INT)
4. Type numr :
CREATE TYPE JOUR-OUVR (LUN, MAR, MER, JEU, VEN);
Au-del des types de collections SET, LIST et MULTISET, SQL3 propose des types
additionnels multiples : piles (stack), files (queue), tableaux dynamiques (varray),
tableaux inserables (iarray) pour grer des textes par exemple. Un tableau dynamique
peut grandir par la fin, alors quun tableau insrable peut aussi grandir par insertion
partir dune position intermdiaire (il peut donc grandir par le milieu). Ces types de
collections sont seulement optionnels : ils ne sont pas intgrs dans le langage de base
mais peuvent tre ajouts.
De manire gnrale, il est possible de rfrencer des objets via des OID mmoriss
comme valeurs dattributs. De tels attributs sont dclars rfrences (REF) comme
dans lexemple ci-dessous :
CREATE TYPE VOITURE (NUMRO CHAR(9), COULEUR VARCHAR,
PROPRITAIRE REF(PERSONNE))
en supposant dfinis les types TEXT (texte libre) et IMAGE, qui sont gnralement
fournis avec un SGBD objet-relationnel, comme nous le verrons plus loin.
La table de la figure XIII.6 pourra tre dfinie partir des mmes types avec en plus :
CREATE TYPE CONDUCTEUR (CONDUCTEUR VARCHAR, AGE INT)
CREATE TYPE ACCIDENT (ACCIDENT INT, RAPPORT TEXT, PHOTO IMAGE)
par la commande :
CREATE TABLE POLICE (NPOLICE INT, NOM VARCHAR, ADRESSE ADRESSE,
CONDUCTEURS SET(CONDUCTEUR), ACCIDENTS LIST(ACCIDENT)).
SQL3 donne aussi des facilits pour passer dun type une table de tuples de ce type
et rciproquement, dune table au type correspondant.
Par exemple, en utilisant le type EMPLOY dfini ci-dessus, il est possible de dfinir
simplement une table demploys par la commande :
CREATE TABLE EMPLOYS OF EMPLOY ;
En dfinissant une table VINS, il sera possible de dfinir le type VIN compos des
mmes attributs comme suit :
CREATE TABLE VINS(NV INT, CRU VARCHAR, DEGR FLOAT(5.2))
OF NEW TYPE VIN ;
Comme mentionn, lhritage de table qui recopie la structure est possible par la
clause :
CREATE TABLE <TABLE> UNDER <TABLE> [WITH (LISTE DATTRIBUTS TYPS)].
La liste des attributs typs permet dajouter les attributs spcifiques la sous-table.
Par exemple, une table de vins millsim pourra tre cre par :
CREATE TABLE VINSMILL UNDER VINS WITH (MILLSIME INT, QUALIT VARCHAR).
termes SQL, qui peuvent figurer dans les expressions de valeurs slectionnes ou dans
les prdicats de recherche. Une fonction sapplique laide de la notation parenthse
sur des termes du type des arguments spcifis.
Considrons par exemple la table demploys contenant des instances du type EMPLOY
dfinit ci-dessus. La requte suivante retrouve le nom et lge des employs de moins
de 35 ans :
SELECT E.NOM, AGE(E)
FROM EMPLOYS E
WHERE AGE(E) < 35;
La notation pointe applique au premier argument est aussi utilisable pour invoquer
les fonctions :
SELECT E.NOM, E..AGE()
FROM EMPLOYS E
WHERE E..AGE() < 35;
Il sagit dun artifice syntaxique, la dernire version utilisant dailleurs la double notation pointe (..) pour les fonctions et attributs composs, la notation pointe simple (.)
tant rserve au SQL de base (accs une colonne usuelle de tuple).
Au-del des fonctions, SQL3 permet aussi laccs aux attributs composs par la notation
pointe. Supposons par exemple une table demploys localiss dfinies comme suit :
CREATE TABLE EMPLOYSLOC UNDER EMPLOYS WITH (ADRESS ADRESSE).
La requte suivante permet de retrouver le nom et le jour de repos des employs des
Bouches-du-Rhne habitant Marseille :
SELECT NOM, REPOS
FROM EMPLOYSLOC E
WHERE DEPT(E.ADRESS) = BOUCHES DU RHONE
AND E.ADRESS..VILLE = MARSEILLE;
La requte suivante recherche alors les noms et adresses de tous les employs moins
de 100 units de distance (par exemple le mtre) de lemploy Georges :
La question suivante retrouve les employs dont la position est contenu dans un cercle
de rayon 100 autour de lemploy Georges :
SELECT E.NAME, E.ADRESS
FROM EMPLOYS G, EMPLOYS E
WHERE EMPLOYS.NOM = GEORGES AND
CONTIENT(E.POSITION, CERCLE(G.POSITION,1));
Les deux requtes prcdentes sont de fait quivalents et gnrent les mmes
rponses.
La requte suivante recherche les noms des propritaires de voitures rouges habitant
Paris :
SELECT V.PROPRIETAIRENOM
FROM VOITURES V
WHERE V.COULEUR = ROUGE AND V.PROPRIETAIREADRESSE..VILLE = PARIS.
La requte suivante retrouve les rfrences des personnes ayant pour passe-temps le
vlo :
SELECT REF(P)
FROM PERSONNES P
WHERE VLO IN
SELECT *
FROM TABLE (P.PASSETEMPS).
Plus complexe, la requte suivante recherche les numros des polices dassurance
dont un accident contient un rapport avec le mot cl Pont de lAlma :
SELECT P.NPOLICE
FROM POLICE P, TABLE P.ACCIDENTS A, TABLE A.RAPPORT..KEYWORDS M
WHERE M = PONT DE LALMA.
Cette requte suppose la disponibilit de la fonction KEYWORDS sur le type TEXT du rapport qui dlivre une liste de mots cls. Nous tablons tout dabord la liste des accidents,
puis la liste des mots cls du rapport de chaque accident. Ceci donne donc une sorte
dexpression de chemins multivalus. SQL3 est donc trs puissant !
6. LE LANGAGE DE PROGRAMMATION
PSM
Le composant PSM dfinit un L4G adapt SQL. Il a t adopt tout dabord dans le
cadre SQL2, puis tendu SQL3.
sortie) ou des fonctions (clause RETURN <type>), Ces procdures sont en gnral
invoques depuis des programmes htes par des ordres EXEC SQL plus ou moins
spcifiques du langage hte, ou directement depuis dautres procdures PSM par des
ordres CALL <procdure> ou des appels directs de fonctions.
Une assignation seffectue par une clause SET suivie dune expression de valeur
conforme SQL, ou par lassignation du rsultat dune requte dans une variable. Par
exemple :
DECLARE MOYENNE DECIMAL(7.2)
SELECT AVG(SALAIRE) INTO MOYENNE FROM EMPLOYS
Par exemple :
CASE MOYENNE
WHEN <100 THEN CALL PROC1 ;
WHEN = 100 THEN CALL PROC2 ;
ELSE CALL PROC3 ;
END CASE
Les boucles LOOP, REPEAT et WHILE sont des boucles de calculs en mmoire classiques, qui ne font pas directement appel la base. La boucle FOR permet au contraire
de parcourir le rsultat dune requte par le biais dun curseur. Sa syntaxe simplifie
est la suivante :
<ORDRE FOR> ::=
[<TIQUETTE> :]FOR <NOM DE BOUCLE>
AS [<NOM DE CURSEUR> CURSEUR FOR] <SPECIFICATION DE CURSEUR>
DO
<ORDRE SQL>
END FOR <TIQUETTE> ;
Une procdure pour calculer la variance des quantits commandes dun cru donn en
paramtre peut tre dfinie comme suit :
CREATE PROCEDURE (IN C VARCHAR,
OUT VARIANCE DECIMAL(10.2))
BEGIN
DECLARE MOYENNE DECIMAL(10.2) ;
VARIANCE = 0 ;
SELECT AVG(QUANTITE) INTO MOYENNE
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C ;
BOUCLE1:
FOR M AS SELECT NCO, QUANTIT
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C
DO
SET VARIANCE = VARIANCE+(M.QUANTITE MOYENNE)**2
END FOR BOUCLE1 ;
END
Tout SQL est bien sr intgr PSM. Il serait possible dutiliser un curseur et une
boucle WHILE avec un FETCH dans la boucle la place de la boucle FOR.
Dautres types de boucles peuvent bien sr tre utiliss pour calculer cette fonction
[Melton98].
7. CONCLUSION
SQL3 est un standard en volution. Comme nous lavons vu, les composants ne sont
pas tous au mme niveau davancement. La plupart sont au stade de brouillons internationaux, et vont donc subir encore des modifications. Lensemble devrait tre termin vers lan 2000.
SQL3 se situe, au moins pour la partie objet et les interfaces avec les langages objet,
comme un concurrent de lODMG. Il est support par tous les grands constructeurs,
comme IBM, Oracle et Sybase, et est impliqu dans un processus de standardisation
international. Au contraire, lODMG est un accord entre quelques constructeurs de
SGBD objet autour dun langage pur objet. LODMG traite bien les aspects collections et, dans une moindre mesure, traverse de chemins. Les deux propositions pourraient donc apparatre comme complmentaires, condition de converger. Il existe
dailleurs un accord entre les groupes ANSI X3 H2 responsable de SQL et ODMG
pour explorer la convergence. Souhaitons que cet accord aboutisse.
Dautres, comme Stonebraker [Stonebraker96], pensent plutt que les bases de donnes objet ont un crneau dapplication diffrent de celui des bases de donnes objetrelationnel. Les premires seraient plutt orientes vers les applications crites en
C++ ou Java, naviguant dans les bases mais ne formulant pas de questions complexes
sur de gros volumes de donnes persistantes. Au contraire, les bases de donnes objetrelationnel profiteraient de lorientation disque du relationnel et seraient capables de
supporter des questions complexes sur des donnes complexes. La figure XIII.9
rsume ce point de vue. Il est possible de mesurer la complexit des requtes en
nombre de jointures et agrgats, la complexit des donnes en nombre dassociations.
Cependant, lvolution des systmes objet vers la compatibilit SQL, et donc vers
lobjet-relationnel, pousse par le march, ne plaide gure pour la validit de ce
tableau.
Complexit
des requtes
Relationnel
O
Obbjjeett--rreellaattiioonnn e l
ne l
Relationnel
Objet
Complexit
des donnes
8. BIBLIOGRAPHIE
[Darwen95] Darwen H., Date, Introducing the Third Manifesto , Database
Programming & Design Journal, C-J.vol. 1, n 8, p. 25-35, Jan. 1995.
Cet article plaide pour le modle objet-relationnel vu comme une extension
naturelle du relationnel, tel que propos par Codd (et Date). Pour C. Date,
lapport essentiel utile du modle objet est la possibilit de dfinir des types de
donnes utilisateur. En clair, aucune modification nest ncessaire au modle
relationnel qui avait dj le concept de domaine : il suffit douvrir les domaines
et de les rendre extensibles.
[Gardarin89] Gardarin G., Cheiney J.P., Kiernan J., Pastre D., Managing Complex
Objects in an Extensible DBMS , 15th Very Large Data Bases International
Conference, Morgan Kaufman Pub., Amsterdam, Pays-Bas, aot 1989.
Une prsentation dtaille du support dobjets complexes dans le SGBD extensible Sabrina. Ce systme est driv du SGBD relationnel SABRE et fut lun des
premiers SGBD supportes des types abstraits comme domaines dattributs. Il
a ensuite volu vers un SGBD gographique (GoSabrina) qui fut commercialis par la socit INFOSYS.
[Gardarin92] Gardarin G., Valduriez P., ESQL2: An Object-Oriented SQL with FLogic Semantics , 8th Data Engineering International Conf., Phnix, Arizona,
Feb. 1992.
Cet article dcrit le langage ESQL2, prcurseur de SQL3 compatible avec
SQL2, permettant dinterroger la fois des bases de donnes objets et relationnelles. Le langage supporte des relations rfrenant des objets complexes.
Une notation fonctionnelle est utilise pour les parcours de chemins et les
applications de mthodes. Une version plus labore de ESQL2 avec classes et
relations a t spcifie dans le projet EDS. La smantique base sur la FLogic (une logique pour objets) illustre les rapports entre les modles objets et
logiques.
[Godfrey98] Godfrey M., Mayr T., Seshadri P., von Eicken T., Secure and Portable
Database Extensibility , Proc. of the 1998 ACM SIGMOD Intl. Conf. On
Management of Data, ACM Pub. SIGMOD Record vol. 27, n 2, p. 390-401,
Juin 1998.
Cet article dcrit limplmentation de types abstraits dans le SGBD PREDATOR
en Java. Il montre lintrt de fonctions sres et portables, mais souligne aussi les
difficults de performance par comparaison une implmentation en C++.
[Haas90] Haas L., Chang W., Lohman G.M., McPherson J., Wilms P.F., Lapis G.,
Lindsay B., Pirahesh H., Carey M., Shekita E., Starburst Mid-Flight : As the
Dust Clears , IEEE Transactions on Knowledge and Data Engineering, vol. 2,
n 1, Mars 1990.
Chapitre XIV
OPTIMISATION
DE REQUTES OBJET
1. INTRODUCTION
Une des fonctionnalits essentielles des systmes objet ou objet-relationnel est la possibilit dinterroger la base partir de requtes non procdurales, exprimes en OQL
ou en SQL3 (voir chapitre prcdent). Ces requtes peuvent invoquer des oprations
sur des types de donnes utilisateur. En effet, dans les SGBD objet ou relationnelobjet, lutilisateur, ou plutt un implmenteur systme, peut ajouter ses propres types
de donnes, avec des comparateurs logiques et des mthodes daccs spcifiques.
Loptimiseur doit alors tre extensible, cest--dire capable de supporter une base de
rgles de connaissances pouvant tre tendue par lutilisateur afin dexplorer un
espace de recherche plus riche pour les plans dexcution.
Un premier problme est dtre capable de gnrer tous les plans dexcution possibles pour une requte complexe. Ceci ncessite tout dabord des techniques de
rcriture de requtes en requtes quivalentes. La rcriture peut seffectuer au
niveau de la requte source ; plus souvent, elle sapplique sur des requtes traduites en
format interne, sous forme darbres algbriques. De nombreux travaux ont t effectus sur les techniques de rcriture de requtes objet [Graefe93, Haas89, Cluet92,
Mitchell93, Finance94, Florescu96].
Un deuxime problme est le choix des algorithmes et mthodes daccs les plus performants pour raliser une opration de lalgbre dobjets. Ce choix est plus riche que
dans le cas relationnel pour les jointures qui peuvent maintenant seffectuer directement par traverses de pointeurs. Le support direct de pointeurs sous forme didentifiants invariants est en effet une des fonctionnalits nouvelles des systmes objet, permettant la navigation. Le choix des algorithmes daccs va dpendre du modle de
stockage qui inclut de nouvelles techniques dindexation de chemins et de groupage
dobjets. Dautres problmes difficiles sont la mise en place doprateurs spcifiques
sur collections et des index sur fonctions. Nous examinerons plus particulirement les
nouveaux algorithmes de traverses de chemins.
Comme dans le cas relationnel, le choix du meilleur plan ncessite un modle de cot
permettant destimer le cot dun plan la compilation. Ce modle doit prendre en
compte les groupages dobjets, les parcours de pointeurs, les index de chemins, et
aussi les mthodes utilisateur. Ceci pose des problmes difficiles. Plusieurs modles
ont t proposs [Bertino92, Cluet92]. Nous en proposons un prenant en compte le
groupage des objets.
Si lon est capable de gnrer tous les plans candidats pour calculer la rponse une
requte et destimer le cot de chacun, il faut encore choisir le meilleur plan. Une
stratgie exhaustive nest pas possible compte tenu du grand nombre de plans en
gnral. Des stratgies de recherche sophistiques ont t proposes, depuis loptimisation itrative [Ioannidis90, Lanzelotte91] jusqu la recherche gntique [Tang97].
Nous donnons dans ce chapitre une vue densemble des mthodes alatoire de
recherche de plan optimal.
Ce chapitre prsente une synthse des techniques essentielles de loptimisation des
requtes dans les bases de donnes objet, au-del du relationnel. Il sappuie en partie
sur les travaux de recherche que nous avons mens au laboratoire PRiSM de
Versailles de 1990 1996. Ces techniques commencent aujourdhui tre intgres
dans les SGBD objet-relationnel et objet. Dans la section suivante, nous dtaillons
plus particulirement la problmatique doptimisation spcifique lobjet, en lillustrant par quelques exemples. Dans la section 3, nous introduisons un modle de stockage gnrique pour bases de donnes objet. La section 4 se consacre aux algorithmes
de traverse de chemins. Nous donnons diffrents algorithmes de parcours dassociations et de collections imbriques qui gnralisent les algorithmes de jointures en cascade aux bases de donnes objet. La section 5 discute de la gnration des plans quivalents et des types de rgles de rcriture considrer. Elle conduit dvelopper une
architecture type pour un optimiseur extensible. La section 6 dveloppe un modle de
cot pour SGBD objet. Nous examinons ensuite dans la section 7 les diffrentes stratgies de recherche du meilleur plan proposes par les chercheurs. Nous terminons le
chapitre en proposant une stratgie gntique originale applique au choix dalgorithmes de traverses de chemins.
2. PROBLMATIQUE
DES REQUTES OBJET
Dans cette section, nous examinons plus particulirement les problmes soulevs par
loptimisation de requtes OQL ou SQL3 par rapport aux requtes purement relationnelles, cest--dire exprimes en SQL2.
deviennent alors trs difficiles, les mthodes rellement appliques ntant connues
qu la compilation.
Habite
Pays
Nom
nom
adresse
telephones
Passe
Clients
Fournisseurs
numcli
type
numfou
commentaire
*
Commandes
numco
etat
date
responsable
prix()
Ligne
Quantit
Vendu
*
Produits
numpro
nom
marque
prix
On note que les chemins sont monovalus. Il est aussi possible de parcourir des chemins multivalus, en utilisant par exemple des collections dpendantes en OQL. La
question suivante recherche par exemple les clients qui ont command des produits de
prix suprieur 10 000 :
(Q2) SELECT C.NOM, C.ADRESSE
FROM CLIENTS C, C.PASSE M, M.LIGNE P
WHERE P.PRIX > 10.000
Le problme essentiel pour ce type de requtes est de choisir un algorithme de parcours des chemins de traverse, de sorte rduire au maximum le nombre dobjets
traverss. Des jointures par valeur, comme en relationnel, peuvent parfois tre plus
avantageuses afin de trouver rapidement des rsultats partir dun petit nombre
dobjets en mmoire.
Loptimiseur doit alors tre capable dvoluer en prenant en compte les nouveaux
types et les rgles doptimisation des oprations sur ces types. Par exemple, on pourra
maintenant rechercher tous les fournisseurs localiss dans une zone donne ( :Z) et
moins de 100 km dun client donn ( :N) par la requte :
(Q3) SELECT NUMFOU, NOM, ADRESSE
FROM CLIENTS C, FOURNISSEURS F
WHERE C.NUMCLI = :N AND INCLUS( :Z, F.LOCALISATION)
AND DISTANCE(C.LOCALISATION, F. LOCALISATION) < 100 ;
Supposons maintenant que les types figure et cercle soient connus du SGBD extensible, dfini comme suit :
TYPE
TYPE
Une requte quivalente la requte prcdente consiste chercher tous les fournisseurs inclus dans la figure gomtrique rsultant de lintersection de la zone paramtre
et dun cercle de centre le client et de rayon 100 km, ce qui donne :
(Q4) SELECT NUMFOU, NOM, ADRESSE
FROM CLIENTS C, FOURNISSEURS F
WHERE C.NUMCLI = :N
AND INCLUS(F.LOCALISATION, INTERSECTION(CERCLE(C.LOCALISATION,100),:Z)
Un bon optimiseur doit tre capable de dterminer le meilleur plan dexcution pour
cette requte. Il doit donc sapercevoir de lquivalence des formulations. Voil qui
nest pas chose simple et demande de bonnes notions de gomtrie !
Grce aux proprits des ensembles, plus particulirement de loprateur dunion par
rapport lappartenance, elle doit pouvoir tre transforme en une requte plus simple.
3. MODLE DE STOCKAGE
POUR BD OBJET
Dans cette section, nous introduisons un modle de stockage gnral pour bases de
donnes objet. Ce modle intgre diffrentes variantes didentifiants dobjets, de techniques de groupages dobjets et dindexation. Il est suffisamment gnral pour reprsenter les mthodes de stockage existant dans les SGBD. Lobjectif est dillustrer les
techniques possibles, qui nous servirons plus loin de base aux calculs des cots
daccs.
Objet 1
Objet 2
Objet 3
Fentes
Les identifiants physiques sont rapides dcoder pour atteindre lobjet rfrenc. Par
contre, ils ne permettent pas le dplacement libre des objets dans la base. En cas de
dplacement, une technique de chanage doit tre mise en place : lentre de la page
initiale doit indiquer que lobjet nest plus dans la page et pointe sur son nouvel identifiant physique. Cette technique de suite (forwarder) est trs lourde grer, surtout si
les objets se dplacent souvent. On lui prfrera les identifiants logiques, plus coteux
lors de laccs mais invariants au dplacement dobjet.
Notion XIV.2 : Identifiant logique (Logical OID)
Identifiant dobjet compos dun numro dentre dans une table permettant de retrouver lidentifiant physique de lobjet.
En cas de dplacement de lobjet, seule lentre dans la table est change ; elle est
positionne la nouvelle adresse de lobjet. En gnral, les SGBD grent une table
didentifiant logique par type dobjets. La taille de la table est ainsi limite. Pour la
limiter plus encore et viter les entres inutiles, la table est souvent organise comme
une table hache : chaque identifiant logique est affect une entre dtermine par
une fonction de hachage ; chaque entre contient des couples de correspondance
<identifiant logique-identifiant physique>. La figure XIV.3 illustre le dcodage dun
identifiant logique.
Un bon modle de stockage permet la fois les identifiants physiques (OIDP) et les
identifiants logiques (OIDL). Le choix du type didentifiants affecte directement le
cot de traverse des pointeurs.
OID logique
Objet 1
Objet 2
Objet 3
OID physique
Page
Il existe diffrents types dindex de chemins [Bertino89, Kim89]. Les index de chemin simples [Bertino89] [Kemper90] associent pour chaque valeur figurant la fin
du chemin tous les identifiants dobjets suffixes du chemin. Ils peuvent tre implments comme des relations : chaque colonne dun tuple correspond une collection
du chemin, en remontant depuis la fin du chemin. Le premier attribut contient la
valeur figurant la fin du chemin, les suivants contiennent des identifiants dobjets
dsignant les objets successivement rencontrs en parcourant le chemin lenvers. La
figure XIV.4 illustre un index de chemins simple pour le chemin Produits
Fournisseurs Pays de la base reprsente figure XIV.1.
Produits
vendu
Fournisseurs
habite
Pays
Pays
Fournisseurs
Produits
Allemagne
F1
F1
F2
F2
F3
F4
F4
F5
F6
F6
F7
P1
P2
P1
P3
P4
P5
P1
P1
P1
P6
P7
France
Italie
USA
Une premire variante consiste imbriquer les chemins, en vitant ainsi de rpter plusieurs fois un mme identifiant dobjet pour chacun de ses parents. Par exemple, pour le
fournisseur F1, on indiquera directement la liste des parents, pour F2 de mme, si bien
que lentre Allemagne de lindex prcdent devient (Allemagne(F1(P1, P2) F2 (P1,
P3) ). Un tel index est appel index de chemin imbriqu [Bertino91]. De tels index
sont plus difficiles maintenir et utiliser que des tables lors des mises jour.
Les multi-index [Kim89] sont une alternative aux index de chemin. Pour chaque
couple de collections (Ci, Ci+1) conscutives du chemin, on gre un index de jointure
[Valduriez87] contenant les couples identifiants dobjets lis par le chemin. Le dernier
index est un index classique donnant pour chaque valeur terminale du chemin lidentifiant de lobjet contenant cette valeur. Le parcours du chemin seffectue alors par des
intersections de listes didentifiants. Chaque index est finalement un index classique
qui peut tre implment comme un arbre B. Le problme des multi-index est que
chaque index doit tre lu ou crit indpendamment, ce qui ncessite des entres-sorties supplmentaires par rapport aux index de chemin. Lutilisation de tels index est
par contre plus large, par exemple pour acclrer des jointures de collections intermdiaires sur le chemin ou des slections sur la collection feuille.
plusieurs objets relis par des identifiants logiques ou physiques. On distingue alors la
liaison de lincorporation dobjets.
Notion XIV.4 : Liaison dobjet (Object linking)
Reprsentation dobjets associs par un attribut mono (association 1-1) ou multivalu (association
1-N) contenant un ou plusieurs identifiants dobjet pointant depuis un objet vers lobjet associ.
La liaison peut tre effectue dans les deux sens, lobjet rfrenc pointant lui-mme
son ou ses objets associs. Il existe alors pour chaque objet cible un ou plusieurs liens
inverses vers lobjet source. La liaison est une technique classique pour reprsenter
les associations ncessitant le parcours didentifiants pour retrouver les objets associs. La liaison inverse permet le parcours de lassociation dans les deux sens. La liaison a le mrite de rendre les objets lis quasiment indpendants, ce qui nest pas le cas
avec lincorporation.
Notion XIV.5 : Incorporation dobjet (Object embedding)
Reprsentation dobjets associs par un objet composite contenant un objet englobant avec un attribut complexe mono (association 1-1) ou multivalu (association 1-N) contenant directement la
valeur des objets lis.
Lincorporation rend les objets incorpors dpendants de lobjet englobant : ils sont
dtruits avec lui. Le choix entre liaison ou incorporation est donc aussi un problme
de smantique : un objet incorpor a le mme cycle de vie que lobjet incorporant. Du
point de vue stockage, lincorporation prsente lavantage de rendre les objets incorporant et incorpor accessibles simultanment. En outre, elle permet le placement des
objets dans une mme page, ce qui est aussi possible avec la liaison comme nous le
verrons ci-dessous. Elle prsente par contre linconvnient de ne pas supporter le partage rfrentiel des objets dpendants, qui sont de fait copis sils sont rfrencs
ailleurs. La figure XIV.5 illustre la liaison et lincorporation dans le cas de commandes et de lignes de commandes.
Commandes
Commandes
C1
C1
Ligne
Ligne
Ligne
P1-10
P2-15
P3-7
L1
L2
L3
Ligne
Ligne
Ligne
P1-10
P2-15
P3-7
Le groupage est plus souple que lincorporation car il permet une vie autonome des
objets lis, qui peuvent exister sans objets associs. En cas dobjets sans matre ou
dobjets partags par plusieurs matres, le choix de la page de stockage nest pas vident. Pour capturer une large classe de stratgies de groupage, il est possible de dfinir les groupes par des prdicats de slection ou dassociation. Un prdicat de slection permet par exemple de dfinir le groupe des commandes de prix suprieur
10 000 (Commandes.prix>10.000). Un prdicat dassociation permet par
exemple de dfinir un groupe pour chaque produit (Produits vendu
Fournisseurs). Ces prdicats sont utiliss pour dfinir les ensembles dobjets
stocker ensemble dans une mme page ou au moins dans des pages proximit.
Les prdicats ntant pas forcment disjoints, un objet peut appartenir logiquement
plusieurs groupes. Si lon exclut les duplications dobjets, il faut lors du chargement
choisir un groupe. Une technique possible consiste associer des priorits chaque
prdicat de liens. Si un objet appartient deux groupes ou plus, celui de priorit suprieure est retenu. Pour pouvoir discriminer les groupes, les priorits doivent tre diffrentes, dfinies par exemple par un nombre de 0 10.
Afin de visualiser les informations de spcifications des groupes, il a t propos
[Amsaleg93] dutiliser un graphe de groupage dfini comme suit :
Notion XIV.7 : Graphe de groupage (Clustering graph)
Graphe dont les nuds reprsentent les extensions de classes et les arcs les prdicats de liens servant au groupage, chaque arc ayant une priorit pouvant varier de 0 10.
Un graphe de groupage est correct si tous les arcs pointant vers un mme nud ont
une priorit diffrente. Les objets points par plusieurs liens de groupage sont donc
assigns au groupe de plus forte priorit. La figure XIV.6 prsente diffrents graphes
de groupage possibles pour les fournisseurs, les produits et les commandes. Elle suppose que lassociation directe des fournisseurs aux produits est gre par le SGBD.
droite du graphe de groupage, les groupes de diffrents types possibles sont reprsents, par exemple les groupes de fournisseurs, de produits, ou les groupes mixtes.
Produits
Produits
Commandes
Produits
5
10
Commandes
min par lobjet matre selon larc de poids maximal. Par exemple, figure XIV.6c,
chaque objet commandes sera stock prs de son fournisseur sil existe.
Habite
Pays
Nom
nom
adresse
telephones
Passe
Clients
Fournisseurs
numcli
type
numfou
commentaire
Vendu
10
Ligne
Commandes
numco
etat
date
responsable
prix()
3
Quantit
*
Produits
numpro
nom
marque
prix
4. PARCOURS DE CHEMINS
Optimiser la navigation dans une base de donnes objet est lun des soucis essentiels
dun optimiseur. Ce problme prolonge loptimisation des squences de jointures dans
les bases de donnes relationnelles. Dans cette partie, nous prsentons plusieurs algorithmes pour valuer une expression de chemins avec prdicats. De tels algorithmes
ont t tudis dans [Bertino91, Shekita90, Gardarin96]. Ils correspondent des types
varis de traverse dun graphe dobjets. Un tel graphe est reprsent figure XIV.8.
Chaque famille verticale dobjets correspond une collection Ci (par exemple, une
extension de classes). Chaque objet de la collection Ci pointe sur 0 N objets de la
collection Ci+1, selon les cardinalits des associations traverses. Nous crivons
lexpression de chemin C1(P1).C2(P2)Cn(Pn) en dsignant par Pi le prdicat de
slection de la collection Ci. Il sagit donc dassembler les squences c1.c2cn
dobjets lis par des pointeurs et vrifiant respectivement (c1 C1 et P1), (c2 C2 et
P2) (cn Cn et Pn).
Lavantage de DFF est quil sagit dun oprateur n-aire qui ne gnre pas de rsultats
intermdiaires. Lalgorithme assemble les objets en accdant via les OID, ce qui est
efficace dans la plupart des SGBD. Les rsultats sont obtenus lun aprs lautre en
pipeline. Lalgorithme est dailleurs trs analogue celui de jointures n-aire en pipeline vu dans le cadre relationnel, ceci prs quil navigue en suivant les pointeurs.
Ainsi le SGBD peut-il retourner une rponse avant davoir travers tous les objets.
Intuitivement, cet oprateur est trs efficace lorsque la taille mmoire est suffisante
pour contenir tous les objets sur un chemin de la racine aux feuilles, cest--dire au
moins une page par collection. Cependant, si les objets ne sont pas groups selon le
chemin et si la taille mmoire est insuffisante, le systme peut tre conduit relire de
nombreuses fois une mme page.
FJ
C1
C2
(a)
C1
C2
a1
a2
a3
a4
a5
a6
a7
b5
b2
b1
b3
b2
b4
b1
T13
FJ
T12
C3
(b)
C1
C3
a1
a1
a3
a4
a5
a6
a6
c5
c7
c1
c2
c8
c4
c2
Lavantage de lalgorithme en largeur dabord est dtre bas sur des jointures binaires
par rfrence, donc pr-calcules. Le cot de calcul est donc rduit. Cependant, pour
accomplir la jointure entre les collections Ci et Ci+1, les tats des objets de la premire
collection Ci doivent tre chargs en mmoire pour trouver les pointeurs vers les objets
de Ci+1 (contenus dans lattribut Ai) ; les tats de la seconde Ci+1 doivent aussi tre
chargs en mmoire pour tester le prdicat Pi+1. Si aucun groupage selon lassociation
nest ralis, des accs multiples alatoires aux pages peuvent tre ncessaires. Un tri
des identifiants des objets de la deuxime collection sera alors souvent avantageux.
Contrairement lalgorithme DFF, lalgorithme BFF ncessite de conserver si possible
en mmoire des rsultats intermdiaires. Si lon veut dlivrer tous les objets sur les chemins qualifiants, la table support doit tre tendue avec un attribut contenant les identifiants dobjets par collection traverse. Lalgorithme ne permet gure de dlivrer des
rsultats avant la traverse totale au moins des n-1 premires collections. Soulignons
que dans le cas rduit de deux collections, les algorithmes DFF et BFF sont similaires.
RJ
C3
C2
(a)
C3
C2
c1
c2
c2
c4
c4
c7
c6
b2
b5
b4
b7
b4
b2
b1
T31
RJ
T32
C1
(b)
C3
C1
c1
c1
c2
c4
c6
c6
c6
a2
a4
a5
a7
a4
a1
a6
La traverse lenvers est avantageuse lorsquune slection directe est possible sur la
dernire collection (par exemple par un index) et que cette slection retrouve un
nombre faible dobjets (forte slectivit). Pour mmoriser le parcours, une table sup-
port est gnre (voir figure XIV.11). Un avantage de la mthode est qu chaque pas
la jointure est faite entre cette table support et la collection prcdente sur le chemin.
Lalgorithme est bon si la table support est petite (expression de chemin slective).
Soulignons quune expression de chemins peut toujours tre divise en plusieurs sousexpressions, chacune pouvant tre traite avec un algorithme diffrent, DFF, BFF ou
RBFF. Si un prdicat trs slectif est rapidement valuable sur une collection du chemin, on aura avantage considrer RBFF pour la partie prfixant cette collection, puis
BFF ou DFF pour la partie suffixe. Le choix dun algorithme ou dun autre nest pas
vident et ncessite un modle de cot, comme nous le verrons plus loin.
Cette notion doptimiseur extensible a t bien formalise pour la premire fois dans
[Grafe93]. Un optimiseur extensible est construit autour dune base de connaissance
mmorisant les dfinitions de types et oprateurs associs, de mthodes daccs, de
fonctions de cot et de rgles de transformation de plans dexcution. Toutes les transformations de plans peuvent tre exprimes sous la forme de rgles. Comme en relationnel, les rgles permettent de transformer les arbres doprateurs de lalgbre reprsentant les requtes en arbres quivalents. Au-del du relationnel, pour supporter les
types de donnes utilisateurs, lalgbre relationnelle doit tre tendue en une algbre
dobjets complexes, avec en particulier les fonctions dans les expressions de qualification et de projection, et le support doprations sur collections imbriques telles que
Nest, Unnest et Flatten. Une telle algbre a t prsente au chapitre XI.
Nous reprsentons figures XIV.12 et XIV.13 les questions Q1 et Q3 du paragraphe 2.2
sous la forme darbres algbriques. Larbre de la figure XIV.12 contient trois restrictions sur attributs ou mthodes, suivies de deux jointures par rfrences qui traduisent
le parcours de chemin. Ces deux jointures peuvent par exemple tre remplaces par un
oprateur de parcours du graphe en profondeur dabord (DFF) vu ci-dessus, ou par
des jointures en arrire (RBFF). Une projection finale gagnerait tre descendue par
les rgles classiques vues en relationnel.
Rsultats
P.nom,
F. adresse
habite
P.nom =
vendu
" France"
Pays P
F.age() >
50
Produits P
Fournisseurs F
tion de telles requtes est difficile et ncessite des connaissances spcifiques sur les
fonctions utilisateurs [Hellerstein93], ici des fonctions gomtriques.
Rsultats
F.numfou,
F.nom, F.adresse
Distance(C.localisation,
C.numcli
:N
Clients C
Inclus(:Z,
F.localisation)
Fournisseurs F
Dautres rgles ne sont applicables que dans un sens et peuvent ncessiter des conditions. titre dexemple, nous les crirons sous la forme suivante :
<SOUS-ARBRE> [<CONDITION>] <SOUS-ARBRE>.
Une telle rgle signifie que lorsquun sous arbre est rencontr, si la condition optionnelle est satisfaite, il peut tre rcrit dans le sous-arbre figurant aprs limplication.
En pratique, il faut en plus appliquer quelques procdures par exemple pour changer
des variables ou des annotations ; celles-ci sont supposes attaches la rgle ; elles
ne sont pas mentionnes pour des raisons de simplicit.
Toutes les rgles classiques de lalgbre relationnelle peuvent ainsi tre codes, avec
plus ou moins de difficults. Il est possible aussi dajouter des rgles prenant en
compte les oprations sur collections, NEST,UNNEST et FLATTEN. Par exemple, la
rgle permettant de pousser une restriction avant une opration dimbrication NEST
peut scrire :
RESTRICT(NEST(X, G, N), Q) [ ATTRIBUT(Q) G ]
RESTRICT(NEST(RESTRICT(X, Q1), G, N), Q2) ;
Cette rgle exprime le fait que si une restriction est applique sur certains attributs de
groupement, alors la partie de la restriction concernant ces attributs peut tre applique avant le groupement.
Au-del, des rgles de simplification peuvent aussi tre introduites pour isoler des
sous-arbres identiques et les remplacer par une relation intermdiaire utilisable en plusieurs points. Ce genre de rgles est important car il permet dviter de calculer deux
fois la mme sous-question. Son expression gnrale ncessite un langage de rgles
un peu plus puissant, permettant de tester si deux sous-arbre sont quivalents.
Les expressions sont des termes fonctionnels du langage OQL, cest--dire des
expressions de chemins, des prdicats avec expressions de chemins ou des requtes.
De telles rgles permettent dexprimer divers types de contraintes, comme lexistence
de liens inverses et la redondance de donnes. Considrons par exemple la dfinition
en ODL de la base dcrivant pays et clients, en supposant ces classes lies par une
association 1N :
INTERFACE CLIENTS {
ATTRIBUT
INT NUMCLI KEY, STRING NOM,
ADRESSE CADRESSE, REF(PAYS) CPAYS, INT TELEPHONE,
INT SEGMENT, STRING COMMENTAIRE }
INTERFACE PAYS {
ATTRIBUT
INT NUMPAYS KEY, STRING NOM, INT NUMCONT,
STRING COMMENTAIRE, RESIDENTS SET <CLIENTS>}
La rgle de lien inverse spcifiant quun client rfrence un pays sil est rsident de ce
pays scrit :
FOR ALL C OF TYPE CLIENTS, P OF TYPE PAYS
C.CPAYS = P C IN P.RESIDENTS.
INTERFACE IMAGE {
ATTRIBUT NUMCLI INT, CONTENT ARRAY[1024,1024] INT,
OPERATION
ARRAY[10] SUMMARY(IMAGE),
IMAGE ROTATE (IMAGE, ANGLE),
IMAGE CLIP (REGION) }
Considrons la requte suivante qui recherche les images des clients du segment 5, les
intersecte avec une fentre prdfinie $zone, et les fait tourner de 90 avant de les
afficher :
SELECT CLIP(ROTATE(I,90),$ZONE)
FROM CLIENTS C, IMAGES I
WHERE C.NUMCLI = I.NUMCLI
AND C.SEGMENT = 5 ;
Il apparat que plutt de faire tourner les images, on aurait intrt faire lintersection
(le clip) avec la zone tourne de 90, et faire tourner seulement la partie intressante. Lquivalence de termes est aussi trs approprie la dfinition daxiomes sur
des types abstraits. Par exemple, la transformation ncessaire pour rcrire la question
prcdente de manire plus optimise est :
FOR ALL I OF IMAGE, F OF FENETRE
CLIP(ROTATE(I,$A), F) ROTATE(CLIP(I,ROTATE(F,-$A),$A).
Pour les systmes objet, il est possible de les tendre [Gardarin96] par quelques rgles
permettant de prendre en compte les traverses de chemin, avec les algorithmes prsents dans la section 4. Ces nouvelles rgles concernent lutilisation de loprateur DFF
de parcours en profondeur dabord, des jointures par rfrences et des index de chemins. JOINFJ dsigne la jointure par rfrence en avant non considre ci-dessus et
JOINRJ la jointure par rfrence en arrire. JOINPATH-INDEX dsigne lalgorithme de
jointure exploitant lexistence dun index de chemin. On obtient les nouvelles rgles :
1. Jointure en avant ou en arrire :
A JOINFJ B A JOINRJ B
Pour simplifier, supposons labsence dindex de chemins. Chaque collection est relie
chacune de ses voisines par une association multivalue (le cas monovalu est un
cas dgnr).
C1
AC2
C2
AC3
........
Cn1
ACn
Cn
teur n-aire de jointure par rfrence parcourant le graphe en profondeur dabord. Dans
le cas o DFF nest pas utilis, le problme revient calculer le nombre dordres de
jointures possibles avec deux oprateurs de jointures en vitant les produits cartsiens
[Tan91], [Lanzelotte93]. On obtient pour lespace de recherche de jointures binaires
de n collections :
(2n 2)!
n1
BJ_SS(n) =
*2
n!(n 1)!
Si lon introduit loprateur DFF, la taille de lespace de recherche devient bien sr
plus grande. Soit SS(n-1) lespace de recherche pour traverser (n-1) collections. On a :
SS(n) = BJ_SS(n) + PC_SS(n)
BJ_SS(n) est lespace de recherche pour les jointures binaires et PC_SS(n) est le
nombre darbres annots avec au moins un nud DFF. Pour dterminer la valeur de
PC_SS(n), supposons tout dabord un seul DFF avec trois collections : celles-ci sont
traites ensemble par cet oprateur DFF et peuvent tre vues comme une unique collection ; pour le reste, la longueur du chemin est rduite de 2, ce qui signifie que SS(n
2) plans peuvent tre gnrs. Il existe n 2 positions parmi les n collections o il
est possible dappliquer loprateur DFF sur trois collections. Pour la mme raison, il
existe n 3 positions o appliquer DFF sur quatre collections ; et ainsi de suite ; finalement, il existe 2 positions o appliquer DFF sur n 1 collections et 1 position pour
appliquer DFF sur les n collections. En sommant tous les cas analyss, on obtient une
borne suprieure de PC_SS(n). Ainsi, une bonne approximation du nombre de plans
est :
(2n 2)!
n1
BJ_SS(n) =
*2
n!(n 1)!
avec SS(1) = 1, SS(2) = 2, SS(3) = 9.
Ainsi, la table prsente figure XIV.15 donne une approximation du nombre de plans
pour des chemins de longueur 1 8. On constate quau-del de 8, lespace devient
rapidement important. Il est donc trs coteux pour un optimiseur de considrer toutes
les solutions, surtout dans les cas de requtes plus complexes que les requtes chanes.
Nombre de
collections
Espace de
recherche
Nombre de
collections
256
1544
9910
45
65462
Espace de
recherche
Schma de
stockage
Plans dexcution
Gnrateur
de plans
Stratgie
de recherche
action :
cot :
but :
{ }
rel
boolen
Rgles
de transformation
Modle de cot
Plan quasioptimal
respond au temps pass excuter des instructions de lunit centrale, par exemple
pour valuer un prdicat ou excuter une boucle. Le deuxime correspond au temps
de lecture et criture sur disques. Le troisime intervient surtout dans les bases rparties o des changes de messages sont ncessaires sur le rseau.
Dans cette section, nous prsentons un modle de cot pour bases de donnes objet,
publi dans [Gardarin95]. Considrant une base centralise, nous valuons seulement
les cots dentres-sorties et de calcul. Pour simplifier, nous supposons que les objets
ont une taille infrieure une page et que les valeurs dattributs sont uniformment
distribues lintrieur de leurs domaines de variation.
Dans le cas de plusieurs collections groupes, certaines pages peuvent tre homognes, dautres contenir des objets de diffrentes collections. Une mthode pour estimer le nombre total de pages dune collection groupe avec dautres a t propose
dans [Tang96]. Supposons que la collection B soit groupe avec la collection A (voir
figure XIV.17). Rappelons que nous notons respectivement SA et S B les tailles
moyennes des objets des collections A et B, et que SA et SB sont supposes infrieures la taille de la page. Estimons tout dabord la taille de la collection A qui est
la racine de larbre de groupage. Il existe deux partitions physiques pour A aprs le
placement des deux collections, lune contenant des objets groups avec des objets de
B note ClAB, lautre ne contenant que des objets de A note ClA.
ClA
ClAB
A
ClB
B
X A, B
Sp
SA
Pour ClAB, le nombre dobjets de A dans cette partition est AXA,B. La taille
dun groupe autour dun objet A est SClAB = SA+(ZA,B*SB), do lon dduit :
A C l
A XA, B
Sp
AB
si S C l
AB
< Sp
A X A, B si S C l
AB
Sp
SC l
AB
Pour ClAB, la taille et le nombre dobjets par groupe reste le mme que celui calcul ci-dessus, mais le nombre de groupes auxquels accder est maintenant
XClAB= Min(ZA,B*XA,B, XA,B). Nous obtenons donc :
A C l
B C l
si S C l
AB
AB
< Sp
sinon
AB
A X A, B
si Z A, B * S B S p
(A X A, B) *
Z A, B * S B
Sp
si Z A, B * S B > S p
i=1
nd i + 1
ni+1
avec d = 1 1m
Dans le cas dune collection C groupe avec dautres, il nest pas possible dappliquer
simplement la formule de Yao pour estimer le nombre de pages auxquelles accdes
lors dune slection par un prdicat P par Yao(C,C,Sel(P)*C). Le problme est
quune collection groupe est compose de plusieurs partitions. Certains objets sont
groups avec des objets de collections diffrentes. Ainsi, la distribution des objets
dans les pages nest pas uniforme, bien que les collections soient supposes indpendantes dun point de vue probabiliste. Il est possible dappliquer la formule de Yao
chaque partition, aprs avoir dtermin la taille de chaque partition comme vu ci-dessus, soit ||C||i objets et |C|i pages pour la partition i. Nous obtenons alors la formule de
Tang pour le calcul des entre-sorties [Tang96].
Notion XIV.10 : Formule de Tang (Tang Formula)
tant donn une collection C divise en p partitions, chacune ayant Ci objets et Ci pages, la
slection alatoire de k objets de C ncessite laccs :
Tan g(C,k) =
i=1
Si les objets slectionner sont placs uniformment dans les partitions, on slectionne ki = (Ci/C)*k dans la partition i. Quand les objets qui satisfont le prdicat
de recherche ne sont pas placs uniformment, il faut calculer la slectivit du prdicat dans chaque partition pour calculer ki. Bien que drive de la formule de Yao, la
formule de Tang est plus gnrale que celle de Yao, qui en est un cas particulier pour
une collection avec une seule partition.
Par exemple, si une classe Gomtrie publie une fonction distance(gomtrie), elle
pourra aussi publier une fonction cot_distance(gomtrie). Le cot pourra tre trs diffrent selon les gomtries sur lesquelles sapplique la fonction : il est par exemple beaucoup plus simple de calculer la distance de deux points que celle de deux polygones.
Notion XIV.12 : Moyennage de cot (Cost averaging)
Technique consistant mmoriser le cot moyen dapplication dune mthode au fur et mesure de
son utilisation.
Au dpart, le cot de la mthode est inconnu, et estim par exemple comme une projection sur attribut. Puis, suite aux requtes ou des demandes destimation de
ladministrateur (par une requte spcifique ANALYZE <mthode>), la mthode
est excute sur un chantillon de N objets. Une table est gre dans la mta-base
pour maintenir le cot moyen observ, de schma simplifi COSTMETHOD (cot
real, nombre int), cot tant le cot moyen et nombre le nombre dexcutions observes. La table peut aussi mmoriser le type des paramtres, les heures
dappels, etc., afin dobtenir des statistiques plus fines.
Page min =
i=2
Page m ax =
i=2
+ CPU_Comp_Cost) * fan C , C * S j 1)
j1
J
i = 2i = 2
7. STRATGIES DE RECHERCHE
DU MEILLEUR PLAN
La recherche du meilleur plan dexcution dans une base de donnes objet ou objetrelationnel est encore plus complexe que dans une base relationnelle. En effet,
lespace des plans est plus large du fait de la prsence de rfrences, dindex de chemins, de collections imbriques, etc. Au-del de la programmation dynamique classique limite des espaces de recherche de faible taille [Swami88, Swami89,
Vance96] vue dans le cadre relationnel, des mthodes doptimisation pour la
recherche de plans optimaux base sur des algorithmes alatoires ont t proposes.
Aprs les avoir prsents, nous proposons une mthode plus avance base sur des
algorithmes gntiques.
Procedure II(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
while not(condition_arrt) do { // Boucle doptimisation globale
while not (condition_locale) do { // Boucle doptimisation locale
p = dplacer(p); // Appliquer une transformation valide p
if (Cot(p)<Cot(p)) then p = p; // Garder si moins coteux
}
// Slectionner le plan optimal
if cot(p)<cot(PlanOptimal) then PlanOptimal = p;
p = Random(p) ; // Se dplacer au hasard vers un autre plan
}
Return(PlanOptimal);
}
Procdure SA(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
T = T0; // Initialiser la temperature
while not(condition_arrt) do { // Boucle doptimisation globale
while not(equilibrium) do { // Boucle doptimisation locale
p = dplacer(p); // Appliquer une transformation valide p
delta = cost(p)-cost(p); // Calculer la diffrence de cot
if (delta<0) then p = p; // Si cot rduit prendre le nouveau plan
// Si cot accru, accept si chaud
if (delta>0) then p = p with probability e delta/T;
// Maintenir le plan optimal
if cost(p)<cost(PlanOptimal) then PlanOptimal = p;
}
T = reduce(T); // Reduire la temprature
}
Return(PlanOptimal); }
Procedure TS(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
T = ; // initialiser la liste taboue
while not(condition_arrt) do { // boucle globale
// accepter tous les mouvements non tabous
gnrer V*N(p)-T en appliquant dplacer(p);
choisir le meilleur plan p V*; // Prendre le meilleur plan
T= (T-(plus vieux)){p}; // Mettre jour la taboue liste
// maintenir le plan optimal
if cot(p)<cot(PlanOptimal) then PlanOptimal = p;
}
return(PlanOptimal);
}
tive (II) et loptimisation deux phases (TP) utilisent une transformation alatoire pour
explorer cet espace. Pour amliorer les performances de ces algorithmes, des
mthodes de transformation darbres introduisant une meilleure couverture de
lespace de recherche ont t mises au point. Ce sont par exemple lchange de jointures et le swap [Swami89, Lanzelotte93]. Lchange de jointure permute alatoirement des relations alors que le swap change des parties darbres. De telles mthodes
ont t introduites seulement pour les jointures relationnelles. Il est possible de les
tendre au cas objet.
Suite aux mouvements ascendants, SA est gnralement plus lent que les autres
mthodes mais trouve souvent de meilleurs plans que II quand le temps de recherche
est suffisant. TP combine les avantages de SA et II. Il a t montr [Ioannidis90] que
TP trouve en gnral de meilleurs plans que SA et II. TS est rapide mais accomplit
une recherche agressive. En consquence, lalgorithme peut rester bloqu sur un minimum local. Ceci peut tre vit avec une longue liste taboue, mais la recherche ralentit alors lalgorithme.
II, SA, TP et TS utilisent tous une fonction appele dplacer. Celle-ci applique
lune des rgles de transformation pour trouver un plan quivalent. Comme vu ci-dessus, dans une base de donnes objet ou objet-relationnel avec beaucoup de types, le
nombre de rgles peut tre important. Certaines ne provoquent que de petits dplacements dans lespace des plans, dautres de beaucoup plus larges. Il faudrait donc pouvoir introduire des transformations permettant dappliquer des squences de rgles, et
donc de faire de grands sauts dans lespace des plans. Nous allons tudier une
mthode permettant de telles transformations dans la section suivante.
8. UN ALGORITHME DOPTIMISATION
GNTIQUE
Dans cette section, nous tudions lapproche gntique et son application possible
loptimisation de requtes [Bennett91]. Pour lillustrer concrtement, nous tudions le
cas de longues expressions de chemins avec prdicats. Les expressions de chemins
sont importantes dans les BD objets ; certains SGBD se concentrent dailleurs sur leur
optimisation et ne proposent gure dautres optimisations.
Initialisation
Mutation
Croisement
valuation
Tri
Slection
Non
Fin ?
DFF/PI
(0,4)
DFF/PI
(0,3)
DFF/PI
(0,2)
FJ/PI/RJ
(0,1)
DFF/PI
(1,4)
DFF/PI
(1,3)
FJ/PI/RJ
(1,2)
FJ/PI/RJ
(1,0)
DFF/PI
(2,4)
FJ/PI/RJ
(2,3)
FJ/PI/RJ
(2,1)
DFF/PI
(2,0
FJ/PI/RJ
(3,4)
FJ/PI/RJ
(3,2)
DFF/PI
(3,1)
DFF/PI
(3,0)
FJ/PI/RJ
(4,3)
DFF/PI
(4,2)
DFF/PI
(4,1)
DFF/PI
(4,0)
DFF
A
RJ
C
DFF
B
Si liens inverses
FJ
A
RJ
C
FJ
B
FJ
C
DFF
A
FJ
RJ
PI
C
RJ
FJ
A
DFF
DFF
crossover
RJ
FJ
RJ
FJ
RJ
D
FJ
E
F
Des expriences effectues avec cet algorithme ont montr quil pouvait tre amlior
en ajoutant des plans alatoirement gnrs chaque gnration, ceci afin de garantir
la diversit des plans explors [Tang96]. Les limites de tels algorithmes doptimisation appliqus aux bases de donnes, notamment dans le cas dun trs grand nombre
de rgles, restent encore dcouvrir.
9. CONCLUSION
Dans ce chapitre, nous avons tudi diffrentes techniques doptimisation pour les
SGBD objet. Tout dabord, les techniques de groupage des objets sur disques permettent de placer proximit les objets souvent accds ensemble, par exemple via des
parcours de chemins. Elles prolongent les techniques de groupage des relations par
jointures pr-calcules de certains SGBD relationnels. Au-del, les index de chemins
constituent aussi une spcificit des BD objet ; ils peuvent tre perus comme une
extension des index de jointure des BD relationnelles.
Ensuite, nous avons tudi diffrents algorithmes de parcours de chemins. Ces algorithmes permettent la navigation ensembliste dans les BD objet. Ils sont des extensions naturelles des algorithmes de jointures [Valduriez87], quils tendent en utilisant
des identifiants dobjets.
La gnration de plans quivalents est plus complexe que dans le cas relationnel, surtout
par la ncessit de prendre en compte les types de donnes utilisateurs et les rcritures
dexpressions de mthodes associes. Ceci ncessite le dveloppement doptimiseurs
extensibles, supportant lajout de rgles de rcriture. Ce sont de vritables systmes
experts en optimisation, qui sont maintenant au cur des SGBD objet-relationnel.
Le dveloppement dun modle de cot pour bases de donnes objet est un problme
des plus difficiles. Il faut prendre en compte de nombreuses statistiques, les groupes,
les rfrences, les index de chemins, les mthodes et les diffrentes formes de collections. Nous avons prsent un modle de cot simple labor par extension des
modles classiques des BD relationnels. Peu doptimiseurs prennent en compte un
modle de cot intgrant les spcificits de lobjet, par exemple les mthodes.
Beaucoup reste faire.
Nous avons enfin dvelopp des stratgies de recherche sophistiques pour trouver le
meilleur plan dexcution. Beaucoup ont t proposes et paraissent suffisantes pour
des questions mettant en jeu une dizaine de collections. Au-del, les stratgies gntiques semblent prometteuses. Peu de SGBD utilisent aujourdhui ces stratgies, la
plupart restant bass sur la programmation dynamique. Lintgration dans des systmes pratiques reste donc faire.
10. BIBLIOGRAPHIE
[Amsaleg93] Amsaleg L., Gruber O., Object Grouping in EOS , Distributed Object
Management, Morgan Kaufman Pub., San Mateo, CA, p. 117-131, 1993.
EOS est un grant dobjets un seul niveau de mmoire ralis lINRIA de
1990 1995. Une technique originale de groupement dobjets avec priorit a
t propose, ainsi que des techniques de ramassage de miettes.
[Bertino89] Bertino E., Kim W., Indexing Techniques for Queries on Nested
Objects , IEEE Transactions on Knowledge and Data Engineering, vol. 1(2),
June 1989, p. 196-214.
Cet article compare diffrentes techniques dindexation pour les bases de donnes objet, en particulier plusieurs techniques dindex de chemins et dindex
spars ou groups (multi-index) dans le cas de hirarchie de gnralisation.
[Bertino91] Bertino E., An Indexing Technique for Object-Oriented Databases ,
Proceedings of Int. Conf. Data Engineering, Kobe, Japan, p. 160-170, April
1991.
Cet article dveloppe le prcdent et propose des techniques de recherche et
mise jour avec index de chemin.
[Bertino92] Bertino E., Foscoli P., An Analytical Model of Object-Oriented Query
Costs , Persistent Object Systems, Workshop in Computing Series, SpringerVerlag, 1992.
Les auteurs dveloppent un modle de cot analytique pour BD objet. Celui-ci
prend notamment en compte les index de chemin.
[Bennett91] Bennett K., Ferris M.C., Ioannidis Y.E., A Genetic Algorithm for
Database Query Optimization , Proc. 4th International Conference on Genetic
Algorithms, San Diego, CA, p. 400-407, June 1991.
Cet article a propos pour la premire fois lutilisation dun algorithme gntique dans les bases de donnes objet.
[Christophides96] Christophides V., Cluet S., Moerkotte G., Evaluating Queries
with Generalized Path Expressions , Proceedings of the 1996 ACM SIGMOD
International Conference on Management of Data, ACM Ed., 1996.
Cet article propose dtendre OQL avec des expressions de chemin gnralises, par exemple traversant de multiples associations. Des techniques dvaluation de telles expressions de chemin sont discutes. Il est montr comment
ces techniques peuvent tre intgres dans le processus doptimisation.
[Cluet92] Cluet S., Delobel C., A General framework for the Optimization of ObjectOriented Queries , Proceedings of the 1992 ACM SIGMOD International
Conference on Management of Data, ACM Ed., p. 383-392, 1992.
peut lui mme contenir une question imbrique. Cet article dcrit la stratgie
doptimisation de questions implmente.
[Ozsu95] Ozsu T., Blakeley J.A., Query Processing in Object-oriented Database
Systems , Modern database systems, edited by W. Kim, p. 146-174, 1995.
Cet article prsente une vue densemble des techniques doptimisation dans les
BD objet : architecture, techniques de rcriture algbriques, expressions de
chemins, excution des requtes. Cest un bon tutorial sur le sujet.
[Shekita89] Shekita E. J., Carey M. J., A Performance Evaluation of Pointer-Based
Joins , Proceddings of the 1990 ACM SIGMOD Intl. Conference on
Management of Data, New Jersey, p. 300-311, May 1990.
Cet article dcrit trois algorithmes de jointures bass sur des pointeurs. Ce sont
des variantes des boucles imbriques, du tri-fusion et du hachage hybride. Une
analyse permet de comparer ces algorithmes aux algorithmes correspondants
qui ne sont pas bass sur des pointeurs. Il est montr que lalgorithme naturel
de traverse en profondeur est peu efficace.
[Steinbrunn97] Steinbrunn M., Moerkotte G., Kemper A., Heuristic and
Randomized Optimization for the Join Ordering Problem , VLDB Journal,
p. 191-208, 1997.
Les auteurs prsentent une description assez complte et une valuation compare de tous les algorithmes doptimisation combinatoire proposs pour les
bases de donnes.
[Swami88] Swami A. N., Gupta A., Optimization of Large Join Queries ,
Proceedings of the 1988 ACM SIGMOD Intl. Conference on Management of
Data, Chicago, Illinois, p. 8-17,1988.
Il sagit du premier article ayant introduit les techniques doptimisation alatoire pour chercher le meilleur plan dexcution. Les auteurs montrent que le
problme de recherche du meilleur plan est NP complet. Les mthodes combinatoires doptimisation telles que litration itrative et le recuit simul sont
alors proposes. Des comparaisons montrent lintrt de lamlioration itrative.
[Swami89] Swami A. N., Optimization of Large Join Queries : Combining
Heuristics and Combinatorial Techniques , Proceedings of the 1989 ACM SIGMOD Conference, Portland, Oregon, 1989, p. 367-376.
Les auteurs discutent la combinaison dalgorithmes combinatoires tels que
lamlioration itrative et le recuit simul avec des heuristiques doptimisation
comme laugmentation, lamlioration locale et KBZ. Laugmentation consiste
choisir les relations dans un certain ordre croissant selon une mesure simple
la taille, la taille du rsultat attendu, la slectivit, le nombre de relations joignant, etc. Lheuristique KBZ consiste tudier tous les arbres drivant dun
Partie 4
AU-DEL DU SGBD
Chapitre XV
BASES DE DONNES
DDUCTIVES
1. INTRODUCTION
Depuis que la notion de base de donnes dductive est bien comprise [Gallaire84],
sous la pression des applications potentielles, les concepteurs de systmes sefforcent
de proposer des algorithmes et mthodes efficaces pour raliser des SGBD dductifs
traitant de grands volumes de faits (les bases de donnes classiques) et de rgles.
Lobjectif est de fournir un outil performant pour aider la rsolution de problmes,
exprims sous forme de requtes, dont la solution ncessite des volumes importants
de donnes et de rgles. Les applications potentielles sont nombreuses. Outre la gestion classique ou prvisionnelle, nous citerons par exemple laide la dcision, la
mdecine, la robotique, la productique et plus gnralement toutes les applications de
type systmes experts ncessitant de grands volumes de donnes. Il a mme t possible de penser que lcriture de rgles rfrenant de grandes bases de donnes remplacerait la programmation classique, au moins pour les applications de gestion. Ces
espoirs ont t quelque peu dus, au moins jusqu aujourdhui.
Ce chapitre introduit la problmatique des SGBD dductifs, puis prsente le langage
standard dexpression de rgles portant sur de grandes bases de donnes, appel
DATALOG. Celui-ci permet les requtes rcursives. Nous tudions les extensions de
ce langage, telles que le support des fonctions, de la ngation, des ensembles. Ensuite,
nous abordons les problmes de lvaluation de questions sur des relations dduites.
Aprs une brve vue densemble, nous introduisons quelques techniques de reprsentation des rgles par les graphes, puis nous nous concentrons sur la rcursion. Les
mthodes gnrales QoSaQ et Magic sont prsentes. Quelques mthodes plus spcifiques sont rsumes. Avant un bilan en conclusion, nous abordons, travers des
exemples, les langages de rgles pour BD objet.
Le langage de rgle est donc utilis afin de spcifier les parties conditions et actions
des rgles de dduction. Plus prcisment, partir des prdicats B1, B2... Bn dfinis
dans la base implante (extensionnelle), le langage de rgles permet de spcifier comment construire des prdicats drivs R1,R2... interrogeables par les utilisateurs. Un
langage de rgles peut donc tre peru comme une extension des langages de dfinition de vues et de triggers des SGBD relationnels classiques.
Lextension est de taille car le langage de dfinition et de manipulation de connaissances va intgrer les fonctionnalits suivantes :
1. la possibilit deffectuer les oprations classiques du calcul relationnel (union, restriction, projection, jointure, diffrence) ;
2. le support des ensembles incluant les fonctions dagrgats traditionnelles des langages relationnels classiques ainsi que les attributs multivalus ;
3. la rcursivit, qui permet de dfinir une relation dduite en fonction delle-mme ;
4. la ngation, qui permet de rfrencer des faits non existants dans la base ;
5. les fonctions arithmtiques et plus gnralement celles dfinies par les utilisateurs ;
6. les mises jour des faits au travers des rgles ;
7. la modularit avec la gestion de niveaux dabstraction successifs et de mta-rgles.
En bref, toutes les facilits qui existent dans les langages de dveloppement de bases
de donnes vont chercher figurer dans les langages de rgles. Lobjectif vis est
dailleurs de remplacer ces langages.
lg. rgles
MOTEUR RGLES
MOTEUR RGLES
SGBD
SGBD
Couplage fort
Couplage faible
lg. intgr
MOTEUR RGLES
SGBD
Intgration
Une base de donnes est manipule par des programmes logiques constitus dune
suite de clauses de Horn qui dfinissent des prdicats intentionnels. Un prdicat
intentionnel est donc dfini par un programme de rgles logiques ; il correspond une
vue du modle relationnel.
Notion XV.3 : Prdicat intentionnel (Intensional predicate)
Prdicat calcul par un programme constitu de rgles logiques dont les instances ne sont pas stockes dans la base de donnes.
Une base de donnes logique est constitue dun ensemble de prdicats extensionnels
constituant la base de donnes extensionnelle et dun ensemble de prdicats intentionnels constituant la base de donnes intentionnelle. Les rgles permettant de calculer
les instances des prdicats intentionnels sont donc partie intgrante de la base de donnes logique. Elles sont crites dans le langage DATALOG bas sur les clauses de
Horn. La figure XV.2 illustre les notions de bases de donnes extensionnelle et intentionnelle, la seconde tant drive de la premire par des rgles stockes dans la mtabase du SGBD.
INFORMATIONS
QUESTIONS
MISES JOUR
BD intentionnelle
RGLES
Mta-donnes
BD extentionnelle
BD
Donnes
Mise jour
Dfinition de
connaissances
Infrence
Tables
Rgles
3. LE LANGAGE DATALOG
Le langage DATALOG est driv de la logique du premier ordre. Cest la fois un
langage de description et de manipulation de donnes. Le modle de description de
donnes support par DATALOG est essentiellement relationnel, une relation tant
vue comme un prdicat de la logique. Le langage de manipulation est un langage de
rgles bti partir des clauses de Horn. Le nom DATALOG signifie logique pour
les donnes . Il a t invent pour suggrer une version de PROLOG (le langage de
programmation logique) utilisable pour les donnes. Dans cette section, nous tudions
tout dabord la syntaxe de DATALOG, puis sa smantique.
Q est appel tte de rgle ou conclusion ; P1, P2 Pn est appel corps de rgle ou
prmisse ou encore condition. Chaque Pi est appel sous-but. En appliquant lquivalence Q P P Q, une rgle scrit aussi (P1, P2Pn) Q ; puis en
appliquant (P1, P2) P1 P2, on obtient P1 P2 Pn Q. Donc,
une rgle est une clause de Horn avec au plus un littral positif (la tte de rgle Q).
La figure XV.4 donne un exemple de programme DATALOG dfinissant une base de
donnes extensionnelle dcrivant les employs (prdicat extensionnel EMPLOYE) et
les services (prdicat extensionnel SERVICE) dune grande entreprise. La base de
donnes intentionnelle spcifie le chef immdiat de chaque employ (prdicat
DIRIGE1), puis le chef du chef immdiat (prdicat DIRIGE2).
{
/* Dclaration des prdicats extensionnels */
EMPLOYE(NomService : String, NomEmploye : String) ;
SERVICE(NomService : String, NomChef : String) ;
/* Dfinition des prdicats intensionnels */
DIRIGE1(x,y) SERVICE(z,x), EMPLOYE(z,y)
DIRIGE2(x,y) DIRIGE1(x,z), DIRIGE1(z,y)
}
Un autre exemple de programme DATALOG est prsent figure XV.5. Il dfinit une
base de donnes extensionnelle compose de pays et de vols ariens reliant les capitales des pays. La base de donnes intentionnelle permet de calculer les capitales
proches (prdicat CPROCHE) comme tant les capitales atteignables lune depuis
lautre en moins de cinq heures dans les deux sens. Les pays proches (prdicat
PPROCHE) sont ceux ayant des capitales proches.
{
/* Dclaration des prdicats extensionnels */
PAYS(Nom : String, Capitale : String, Pop : Int) ;
VOLS(Num : Int, Depart : String, Arrivee : String, Duree : Int) ;
/* Dfinition des prdicats intensionnels */
CPROCHE(x,y) VOLS(z,x,y,t), t5, VOLS(w,y,x,u), u5 ;
PPROCHE(x,y) PAYS(x,u,p), PAYS(y,v,q), CPROCHE(u,v) ;
}
Parmi les rgles, il en existe une classe particulirement importante par la puissance
quelle apporte au langage : il sagit des rgles rcursives qui permettent de dfinir
un prdicat intentionnel en fonction de lui-mme.
Notion XV.6 : Rgle rcursive (Recursive rule)
Rgle dont le prdicat de tte apparat aussi dans le corps.
Une rgle rcursive dont le prdicat de tte apparat une seule fois dans le corps est
dite linaire. Une rgle non linaire est quadratique si le prdicat de tte apparat
deux fois dans le corps. Au-del, une rgle rcursive dont le prdicat de tte apparat n
(n 3) fois dans le corps devient difficilement comprhensible.
La figure XV.6 illustre quelques exemples de rgles rcursives.
{
/* Dirige tout niveau spcifi par une rgle rcursive linaire */
DIRIGE(x,y) DIRIGE1(x,y) ;
DIRIGE(x,y) DIRIGE1(x,z), DIRIGE(z,y) ;
/* Dirige tout niveau spcifi par une rgle rcursive quadratique */
DIRIGE(x,y) DIRIGE1(x,y) ;
DIRIGE(x,y) DIRIGE(x,z), DIRIGE(z,y) ;
/* Liaisons effectuables par tapes de moins de 5 heures */
LIAISON(x,y) VOLS(z,x,y,t), t 5 ;
LIAISON(x,y) LIAISON(x,z), LIAISON(z,y) ;
}
Chaque relation rcursive ncessite une rgle dinitialisation non rcursive, puis une
rgle de calcul rcursive. Le premier couple de rgles dfinit qui dirige qui et ce,
tout niveau. Le deuxime dfinit la mme relation, mais en utilisant une rgle non
linaire. Le dernier couple spcifie les liaisons ariennes possibles entre capitales par
des suites de liaisons simples effectues en moins de cinq heures.
La figure XV.7 spcifie en DATALOG la clbre base de donnes des familles partir
des prdicats extensionnels PERE et MERE indiquant qui est pre ou mre de qui. La
relation rcursive ANCETRE a souvent t utilise pour tudier les problmes de la
rcursion. Nous avons ajout la dfinition des grand-parents comme tant les parents
des parents et celle des cousins comme tant deux personnes ayant un anctre commun. Les amis de la famille (AMIF) sont les amis (prdicat extensionnel AMI) ou les
amis de la famille des parents. Les cousins de mme gnration (prdicat MG) se
dduisent partir des frres ou surs. Notez que cette dfinition est large : elle donne
non seulement les cousins, mais aussi soi-mme avec soi-mme (vous tes votre
propre cousin de niveau 0 !), les frres et surs, puis vraiment les cousins de mme
gnration.
{
/* Prdicats extensionnels Pre, Mre et Ami */
PERE(Pre String, Enfant String)
MERE(Mre String, Enfant String)
AMI(Personne String, Personne String)
/* Parent comme union de pre et mre */
PARENT(x,y) PERE(x,y) ;
PARENT(x,y) MERE(x,y) ;
/* Grand-parent par auto-jointure de parents */
GRAND-PARENT(x,z) PARENT(x,y), PARENT(y,z) ;
/* Anctre dfini par une rgle linaire */
ANCETRE(x,y) PARENT(x,y) ;
ANCETRE(x,z) ANCETRE(x,y), PARENT(y,z) ;
/* Cousin partir danctres */
COUSIN(x,y) ANCETRE(z,x), ANCETRE(z,y) ;
/* Ami de la familles comme ami des anctres */
AMIF(x,y) AMI(x,y) ;
AMIF(x,y) PARENT(x,z), AMIF(z,y) ;
/* Cousins de mme gnration partir des parents */
MG(x,y) PARENT(z,x), PARENT(z,y) ;
MG(x,y) PARENT(z,x),MG(z,u),PARENT(u,y) ;
}
Plus gnralement, une relation rcursive est une relation dfinie en fonction dellemme. Une relation rcursive nest pas forcment dfinie par une rgle rcursive. En
effet, des rgles mutuellement rcursives permettent de dfinir une relation rcursive.
Plus prcisment, il est possible de reprsenter la manire dont les prdicats dpendent lun de lautre par un graphe de dpendance. Les sommets du graphe sont les
prdicats et un arc relie un prdicat P un prdicat Q sil existe une rgle de tte Q
dans laquelle P apparat comme un sous-but. Un prdicat intentionnel est rcursif sil
apparat dans un circuit. La figure XV.8 illustre un programme DATALOG avec
rcursion mutuelle. Le prdicat R est rcursif.
{
R(x,y) B(x,y) ;
R(x,y) P(x,z), B(z,y) ;
P(x,y) R(x,z), C(z,y) ;
}
EMPLOYE(informatique,y) DIRIGE1(Pierrre,y)
EMPLOYE(informatique,Julie)
DIRIGE(Pierre, Julie)
En rsum, la mthode de rsolution permet de donner une smantique un programme DATALOG : un fait appartient un prdicat intentionnel sil peut tre prouv
comme un thorme par rsolution. En cas dchec de la mthode, le fait est suppos
faux : il nappartient pas au prdicat intentionnel. Cette interprtation de labsence de
preuve est appele ngation par chec. La mthode ainsi complte est appele
mthode de rsolution avec ngation par chec (ou encore mthode SLDNF). Il sagit
dune mthode qui permet de dterminer si un tuple appartient ou non un prdicat
intentionnel. Cest donc une mthode essentiellement procdurale qui fonctionne
tuple tuple. Elle est proche des mthodes de calcul appliques par les interprteurs
PROLOG.
et de la rgle
DIRIGE1 (x,y) SERVICE (z,x), EMPLOYE (z,y)
a en particulier pour modles :
1. { EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie), SERVICE
(informatique,Pierre), DIRIGE1 (Pierre,Julie), DIRIGE1 (Pierre,Pierre) } ;
2. { EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie),
SERVICE (informatique,Pierre), DIRIGE1 (Pierre,Julie), DIRIGE1 (Pierre,Pierre),
DIRIGE1 (Julie,Julie)} ;
Le plus petit modle est :
{ EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie),
SERVICE
(informatique,Pierre),
DIRIGE1
(Pierre,Julie),
DIRIGE1 (Pierre,Pierre) }.
Il dfinit donc la smantique du programme DATALOG.
PARENT(x,y) PERE(x,y);
PARENT(x,y) MERE(x,y) ;
ANCETRE(x,y) PARENT(x,y);
ANCETRE(x,y) PARENT(x,z), ANCETRE(z,y); }
on calcule :
TP = {
ANCETRE); }
Ainsi, si la relation PERE (Pre, Enfant) contient les faits PERE (Julie,Pierre) et
PERE (Jean,Paul), on en dduit :
PERE (Julie,Paul), PERE (Julie,Jean), PERE (Julie,Julie),
PERE (Pierre,Julie), PERE (Pierre,Jean), PERE (Pierre,Paul), etc.
Lhypothse du monde ferm est une rgle puissante pour infrer des faits ngatifs.
Elle suppose quun domaine peut prendre toutes les valeurs qui apparaissent dans la
base (domaine actif) et que tous les faits correspondant ces valeurs non connus sont
faux [Reiter78]. Pour tre valide, cette hypothse ncessite des axiomes additionnels
tels que lunicit des noms et la fermeture des domaines [Reiter84].
Par exemple, en prsence de valeurs nulles dans les bases de donnes, lhypothse du
monde ferm est trop forte car elle conduit affirmer comme faux des faits inconnus.
Les thoriciens se sont penchs sur des hypothses plus fines, tolrant les valeurs
nulles [Reiter84]. Une variante de lhypothse du monde ferme consiste modifier la
mthode de rsolution permettant de rpondre une question en supposant faux tout
fait qui ne peut tre prouv comme vrai. Cette approche est connue comme la ngation par chec.
En fait, le plus petit modle dune strate est calcul partir du plus petit modle de la
strate prcdente, la ngation tant remplace par un test de non-appartenance. Si M
est le plus petit modle de la strate Si-1, P(x) est interprt comme P(x) nappartient pas M dans la strate Si.
Tout programme DATALOG nest pas stratifiable ; il doit tre possible de calculer
compltement toute lextension dun prdicat avant dutiliser sa ngation pour pouvoir stratifier un programme. Cela nest pas vrai si la rcursion traverse la ngation.
Les programmes stratifiables ont un plus petit modle unique qui est caractris en
dfinissant un ordre partiel entre les prdicats. Lordre correspond un calcul de plus
petit modle strate par strate en utilisant lhypothse du monde ferm.
Par exemple, les programmes :
{P(x) P(x)} et
{ PAIRE(0); IMPAIRE(x) PAIRE(x) ; PAIRE(x) IMPAIRE(x) }
ne sont pas stratifiables car la ngation se rencontre sur un cycle de rcursion (cest-dire traverse la rcursion). Le programme
{ R(1) ; P(1) ; P(2) ; Q(x) R(x); T(x) P(x),Q(x)}
est stratifiable; deux strates possibles sont :
S1 = {R(1) ; Q(x) R(x)} puis
S2 = { P(1) ; P(2) ; T(x) P(x), Q(x)};
S1 calcule Q sans utiliser Q, puis S2 calcule T en utilisant Q et P. Le plus petit
modle de S1 est {R(1); Q(1)}. Celui de S2 est {R(1); Q(1); T(2)}. Notez que lordre
de calcul des prdicats est fondamental : si on commenait calculer T avant Q, on
obtiendrait T(1) et un rsultat qui ne serait pas un modle.
La ngation en corps de rgle est importante car elle permet de raliser la diffrence relationnelle. La stratification correspond la smantique couramment admise en relationnelle : avant dappliquer une diffrence une relation, il faut calculer compltement cette
relation (autrement dit, le pipe-line est impossible avec loprateur de diffrence).
La ngation en tte de rgle est donc interprte comme une suppression. Cest elle
qui confre rellement la non monotonie des programmes DATALOG. Au-del, il
est possible de placer plusieurs prdicats en tte dune rgle DATALOG. Supporter
la fois les rgles ttes multiples et des prdicats ngatifs en tte de rgle conduit
permettre les mises jour dans le langage de rgles. On parle alors du langage DATALOG avec mise jour, not DATALOG*.
Par exemple, la rgle suivante, dfinie sur la base de donnes intentionnelle
{ PARENT(Ascendant, Descendant), ANCETRE(Ascendant, Descendant) } est une
rgle DATALOG* :
ANCETRE(x,z), ANCETRE(z,x) PARENT(x,y), ANCETRE(y,z)
Cette rgle gnre de nouveaux anctres et supprime des cycles qui pourraient apparatre dans la relation anctre (si x est le parent de y et y lanctre de z, alors x est
lanctre de z mais z nest pas lanctre de x).
Une interprtation de DATALOG* est possible partir des rgles de production, trs
populaires dans les systmes experts. Une rgle de production est une expression de
la forme :
<condition> <expression dactions>.
Une expression dactions est une squence dactions dont chacune peut tre soit une
mise jour, soit un effet de bord (par exemple, lappel une fonction externe ou ldition dun message). Une condition est une formule bien forme de logique. Quand
lordre dvaluation des rgles est important, celles-ci sont values selon des priorits dfinies par des mta-rgles (des rgles sur les rgles) ; par exemple, une mtargle peut simplement consister excuter les rgles dans lordre squentiel. Ainsi, un
langage de rgles de production nest pas compltement dclaratif mais peut contenir
une certaine procduralit. Il en va de mme pour les programmes DATALOG avec
mises jour.
CIRCUIT(x,f1,o,e1,i1), CIRCUIT(x,f2,e1,e,i2),
CIRCUIT(x,new(f1,f2),o,e,i1+i2)
CIRCUIT(x,f1,o,e1,i1),CIRCUIT(x,f2,e1,e,i2), CIRCUIT(x,f3,e1,e2,i3)
Ces deux rgles rduisent les circuits par remplacement des fils en parallle et en srie
appartenant un mme circuit par un fil rsultat de la transformation effectue. Notez
quelles ne sont pas stratifiables. Cependant, le programme de rgles est confluent, au
moins pour des circuits lectriques connexes.
Dautres smantiques que la smantique oprationnelle des rgles de production introduite ci-dessus ont t proposes pour Datalog* [Abiteboul95], comme la smantique
inflationiste et la smantique bien fonde. La smantique inflationiste est simple :
elle calcule les conditions, puis tous les faits dduits de toutes les rgles la fois. Elle
applique donc un oprateur de point fixe global modifi. Malheureusement, le rsultat
ne correspond gure la signification courante. La smantique bien fonde est plus
gnrale : elle est base sur une rvision de lhypothse du monde ferme, en autorisant des rponses inconnues des questions. Pour Datalogneg, elle concide avec la
smantique stratifie lorsque les programmes sont stratifiables. Les problmes de
smantique de Datalog* sont en rsum trs difficiles et ont donn lieu de nombreux
travaux thoriques de faible intrt.
Ainsi, des prdicats tels que P(a,x,f(x),f(g(x,a))) o f est une fonction unaire et g une
fonction binaire sont accepts. La smantique de DATALOG doit alors tre complte
pour intgrer les fonctions. Cela seffectue comme en logique, en faisant correspondre
chaque fonction n-aire une application de Dn dans D, D tant le domaine dinterprtation.
Les fonctions sont trs utiles en pratique pour effectuer des calculs. Par exemple, un
problme de cheminement avec calcul de distance sur un graphe pourra tre exprim
comme suit :
{ CHEMIN(x,y,d) ARC(x,y,d) ;
CHEMIN(x,y,d+e) CHEMIN(x,z,e), ARC(z,y,d)
}
La recherche des longueurs de tous les chemins allant de Paris Marseille seffectuera
par la requte ? CHEMIN(Paris,Marseille,x).
Un problme qui devient important avec DATALOGfonc est celui de la finitude des
rponses aux questions (ou des relations dduites). Une question est saine (en anglais
safe) si elle a une rponse finie indpendamment des domaines de la base (qui peuvent tre finis ou infinis). Le problme de dterminer si une question est saine existe
dj en DATALOG pur. Si les domaines sont infinis, un programme DATALOG peut
gnrer des rponses infinies. Par exemple, le programme:
{ SALAIRE(100) ;
SUPERIEUR(x,y) SALAIRE(x), x < y ;
? SUPERIEUR(x,y)
}
gnre une rponse infinie. Pour viter des programmes a modle infini, une caractrisation syntaxique des programmes sain a t propose [Zaniolo86]. Cette caractrisation est base sur la notion de rgle champ restreint. Une rgle est champ restreint si toutes les variables figurant en tte de rgle apparaissent dans un prdicat
relationnel dans le corps de la rgle. Par exemple, la rgle
SUPERIEUR(x,y) SALAIRE(x), x < y nest pas champ restreint car y
napparat pas dans un prdicat relationnel dans le corps de la rgle. Si toutes les
rgles dun programme DATALOG sans fonction sont champ restreint, alors le programme est sain et ne peut gnrer des rponses infinies.
Avec des fonctions, le problme de savoir si un programme est sain est plus difficile.
Par exemple, le programme :
{ ENTIER(0);
ENTIER(x+1) ENTIER(x) }
nest pas sain car il gnre un prdicat infini (les entiers positifs sont gnrs dans
ENTIER). Cependant, ce programme est champ restreint. Notez cependant que la
question ? ENTIER(10) a une rponse finie unique (vrai). Vous trouverez une
mthode gnrale pour dterminer si un programme avec fonctions est sain dans
[Zaniolo86].
En conclusion, il est intressant de remarquer quil est possible dtendre lalgbre
relationnelle avec des fonctions [Zaniolo85], comme vu dans le chapitre XI sur le
modle objet. En fait, il est ncessaire dinclure des fonctions dans les qualifications
de jointures et restrictions (les qualifications sont alors des expressions de logique du
premier ordre avec fonctions). Il est aussi ncessaire dinclure des fonctions dans les
critres de projection. On projette alors sur des termes fonctionnels calculs partir
dattributs. Le plus petit modle dun programme DATALOGfonc peut alors tre calcul par un programme utilisant des boucles dexpressions dalgbre relationnelle
sans diffrence. Ainsi, DATALOGfonc a la puissance de lalgbre relationnelle avec
fonction sans diffrence, mais avec la rcursion. Pour avoir la diffrence, il faut passer
DATALOGfonc,neg et pour avoir les mises jour DATALOGfonc,*.
PICE
composant
compos
qt
locomotive
locomotive
roue
roue
moteur
roue
moteur
rayon
jante
bielle
4
1
20
1
1
NEST
PICE
UNEST
composant
{compos,qt}
locomotive
roue
moteur
Remarquons que le groupage ne donne pas plus de puissance au langage que les fonctions interprtes et la ngation. En fait, si lon dfinit la fonction unaire interprte
qui un lment fait correspondre un ensemble compos de cet lment {}: x {x}
et la fonction binaire interprte sur ensemble : X,Y X Y (cest--dire lunion
classique), il est possible deffectuer le groupage par les rgles suivantes :
SOUS-PIECE (x,Y) PIECE (x,y), Y = {y}
SOUS-PIECE (x,Y) SOUS-PIECE (x,Z), SOUS-PIECE (x,T), Y = Z T
COMPOSE (x,Y) SOUS-PIECE (x,Y), SOUS-PIECE (x,Z), Z Y
En clair, la deuxime rgle fait lunion de tous les lments composant chaque pice x
et la dernire garde le plus grand ensemble de sous-pices Y ainsi gnr. Il va de soi
quutiliser loprateur de groupage est plus simple ; aussi, si le systme ralise efficacement cet oprateur, il sera probablement plus performant pour effectuer le groupage
quen excutant les trois rgles ci-dessus.
Pour conclure sur les ensembles, notons que lintroduction densembles en DATALOG ncessite la stratification pour dfinir la smantique dun programme sans ambigut. Cela provient du fait que les ensembles intgrent un cas particulier de ngation.
La smantique de la stratification ncessaire peut tre exprime comme suit : calculer tout ensemble avant dutiliser son contenu . Ainsi, les rgles doivent tre partiellement ordonnes en strates dans lesquelles les oprations de groupage sont effectues
ds que possible. Si des groupages sont effectus dans des cycles de calculs de prdicats rcursifs, le programme nest pas stratifiable et a une smantique ambigu : il
doit tre rejet.
sont instancies avec des faits connus. Cela ncessite dvaluer la condition composant le corps de rgle sur les faits connus ; pour chaque instance des variables satisfaisant la condition, laction (ou les actions) dfinie par le prdicat de tte est excute.
La procdure de gnration est applique jusqu saturation, cest--dire jusquau
point o aucune rgle ne peut produire de nouveau fait. Une telle procdure est
connue en intelligence artificielle comme la gnration en chanage avant
[Nilsson80]. Elle est rsume figure XV.12.
{ Tant que Il existe une relation drive R non sature faire{
slectionner une rgle r, dont laction sapplique sur R ;
pour chaque tuple de la base satisfaisant la condition de r faire
excuter les actions de r ;
}
} ;
Lapproche propose part des donnes pour laborer la rponse lusager. Pour cette
raison, elle est souvent appele mthode dvaluation bottom-up.
Notion XV.16 : Evaluation Bottom-up (Bottom-up evaluation)
Technique dvaluation partant des tuples de la base de donnes, consistant appliquer les rgles
en avant jusqu saturation pour gnrer la rponse la question finalement obtenue par filtrage
des donnes gnres.
ASC
DESC
Marie
Julie
Julie
Jean
Marie
Jack
APPLICATION DE r1
PARENT
ASC
DESC
Marie
Julie
Julie
Jean
Marie
Jack
APPLICATION DE r3
PRE
ASC
DESC
Pierre
Ted
Ted
Jef
Chris
Marie
Jack
Pierre
APPLICATION DE r2
PARENT
ASC
DESC
Marie
Julie
Julie
Pierre
Ted
Ted
Jef
Jean
Marie
Jack
Chris
Marie
Jack
Pierre
APPLICATION DE q
GRANDPARENT ASC
DESC
GRANDPARENT ASC
DESC
Julie
Ted
Jef
Jean
Jean
Chris
Julie
Ted
Jean
Jean
Les faits relevants peuvent tre utiliss afin de gnrer toutes les rponses la question si ncessaire, en appliquant une procdure de chanage avant partir de ces faits.
Cependant, la technique est trs diffrente de lvaluation bottom-up puisquelle profite des constantes de la question pour rduire les espaces de recherche. La mthode
part de la question de lusager pour remonter aux faits de la base. En consquence,
elle est appele mthode top-down.
Notion XV.18 : valuation top-down (Top-Down Evaluation)
Technique dvaluation partant de la question et appliquant les rgles en arrire pour driver la
rponse la question partir des faits relevants.
demande de comprendre les connexions entre les rgles dans un programme de rgles,
cest--dire les unifications possibles entre prdicats. Dans ce but, plusieurs reprsentations par des graphes dun programme DATALOG ont t proposes.
PROGRAMME DATALOG AVEC QUESTION
(r1) PARENT(x,z) MERE(x,z)
(r2) PARENT(x,z) PERE(x,z)
(q) ? PARENT(x,Jean)
BASE EXTENSIONNELLE
MRE
ASC
DESC
Marie
Julie
Julie
Jean
Marie
Jack
PRE
ASC
DESC
Pierre
Ted
Ted
Jef
Chris
Marie
Jack
Pierre
MRE
ASC
DESC
Marie
Jean
6. LA MODLISATION DE RGLES
PAR DES GRAPHES
Il est important de comprendre les connections entre les rgles dun programme. Un
modle bas sur un graphe est gnralement utilis pour visualiser les liens entre
rgles. Un tel modle capture les unifications possibles entre les prdicats en tte de
rgles et ceux figurant dans les conditions. Il permet souvent dillustrer le mcanisme
doptimisation-excution ou de vrifier la cohrence des rgles. Par exemple, des
rgles peuvent tre contradictoires ou organises de telle manire que certaines relations restent vides. Dans cette section, nous allons prsenter les modles graphiques
les plus connus.
Union
Diffrence
Addition
Duplication
Restriction
Projection
Jointure
REPONSE
DESC = toto
ANCETRE
D
PARENT
t > 16
MERE
t > 16
PERE
Notez quen gnral, la possibilit de complter le graphe par un oprateur de duplication permet dviter de dupliquer des branches similaires de larbre et doptimiser
lexcution correspondante. Par exemple, si lon ajoute la rgle :
(r0)
AIME(x,z) MERE(x,t,z), t >16
il nest pas ncessaire de dupliquer toute la branche de restriction sur mre, mais seulement dintroduire un oprateur de duplication au niveau du rsultat de cette branche.
Celui-ci gnre les tuples de AIME. Soulignons aussi que le nom dun prdicat intermdiaire peut tre omis lorsque ce dernier ne doit pas tre gard. Finalement, un
graphe doprateurs relationnels donne un moyen de gnrer par simple traduction un
programme bottom-up calculant la rponse une question dductive. Tout le problme doptimisation de questions dductives peut tre vu comme un problme
doptimisation de graphes relationnels. Pour rsumer, nous dfinirons informellement
la notion de graphe relationnel de rgles comme suit :
de rgles sont ajoutes pour dvelopper les nuds qui correspondent des relations
rcursives. Nous dvelopperons la rcursion dans la section suivante. Cependant, il
apparat dj que des graphes plus sophistiqus sont ncessaires pour reprsenter les
rgles rcursives.
GRANDPARENT (x,Jean)
z /Jean
r3
PARENT (x,y)
PARENT (y,z)
z/y
z/y
x/y
x/y
r1
r2
r1
r2
MERE (x,t,z)
PERE (x,t,z)
MERE (x,t,z)
PERE (x,t,z)
Une extension de larbre ET/OU pour viter les branches infinies en cas de prdicats
rcursifs est le graphe rgle/but. Un graphe rgle/but est aussi associ une question
qui spcifie un prdicat valuer. Il contient en outre des nuds circulaires reprsentant les prdicats et des nuds rectangulaires reprsentant les rgles. Les seuls arcs
dun graphe rgle/but sont dfinis par la rgle suivante : sil existe une rgle r de la
forme P P1, P2 Pn dans le programme de rgles, alors il existe un nud allant
du nud r au nud P et, pour chaque Pi, il existe un arc allant du nud Pi au nud r.
Dans sa forme la plus simple, un graphe rgle/but peut tre dfini comme une variation dun graphe ET/OU :
Notion XV.21 : Graphe rgle/but (Rule/goal graph)
Graphe reprsentant un ensemble de rgles driv dun arbre ET/OU en remplaant lexpansion de
tout prdicat driv dj dvelopp dans larbre par un arc cyclique vers la rgle correspondant
ce dveloppement.
ANCETRE
r1
r4
PARENT
r1
MERE
PARENT
ANCETRE
r2
PERE
PARENT(x,z)
MERE(x,t,z)
x/x,
z/z
x/x,
z/z
x/x,
z/z
ANCETRE(x,z)
PARENT(x,z)
x/x,
z/z
PARENT(x,z)
x/x,
z/y
x/x,
y/z
ANCETRE(x,z)
PERE(x,t,z)
ANCETRE(x,y)
x/y,
z/z
x/y,
z/z
y/x,
z/z
y/x,
z/z
ANCETRE(y,z)
x/x,
y/z
x/x, z/y
Un rseau de Petri prdicats (PrTN) modlise directement une valuation bottomup (en chanage avant) dun programme de rgles. Chaque relation (prdicat intentionnel ou extentionnel) est modlise par une place ; les jetons de marquage correspondent aux tuples des relations. Chaque rgle est modlise par une transition ; le
prdicat correspond la condition de la rgle. Les rgles gnrent en sortie de nouveaux jetons (tuples) ; pour reprer quels jetons sont gnrs, on tiquette en gnral
les arcs sortant des transitions avec des variables qui reprsentent les attributs des
tuples gnrs. Les arcs entrants sont aussi tiquets afin de faciliter lcriture des
conditions. Une excution du PrTN modlise un calcul de point fixe en chanage
avant. Afin dviter la destruction des tuples dans les places lors dun dclenchement
dune transition, il faut ajouter un arc qui remet le jeton aprs excution de la transition. Pour allger, nous notons par un point le fait que le jeton doit tre conserv dans
sa place lors de lexcution dune transition. Labsence de point permet de modliser
les mises jour par les rgles. La figure XV.20 illustre le PrTN correspondant au programme de rgles dj modlis figure XV.18 et XV.19.
La figure XV.21 prsente une synthse des principales caractristiques des diffrents
modles graphiques introduits ci-dessus. Notez que llment dterminant apparat
finalement tre lorientation top-down (dirige par les questions) ou bottom-up (dirige par les donnes) du modle. Diffrentes variantes de ces modles ont aussi t
proposes ; elles permettent en gnral de mieux prendre en compte une fonctionnalit du langage de rgles modlis.
PERE
MERE
x,t,z
x,z
x,z
x,t,z
x,z
PARENT
yp,z
x,z
ANCETRE
ya = yp
x,z
Caract.
Modle
Graphe
Relationnel
Graphe
Rgle/but
PCG
Actif
PrTN
Etendu
Fonction
oui
non
non
oui
Negation
oui
non
non
oui
Mise jour
oui
non
non
oui
oui
non
non
oui
Bottom up
oui
non
non
oui
Top Down
non
oui
oui
non
Recursion
oui
oui
oui
oui
z1
x
MC
z2
z3
CHEF
z4
y
Il est aussi possible dutiliser DATALOGfonc afin de dfinir des prdicats rcursifs
avec calculs de fonctions. Des exemples typiques sont drivs des problmes de parcours de graphes. Un graphe valu peut tre reprsent par une relation :
ARC (SOURCE, CIBLE, VALUATION).
Chaque tuple de la relation reprsente un arc. Les rgles suivantes dduisent une relation CHEMIN reprsentant tout les chemins du graphe, avec une valuation compose
calcule par une fonction f :
CHEMIN(x,y,z) ARC(x,y,z)
CHEMIN(x,y,f(z1,z2)) ARC(x,z,z1), CHEMIN(z,y,z2)
Par exemple, si f(z1,z2) = z1 + z2 et si les valuations reprsentent des distances, les
rgles prcdentes dfinissent tous les chemins du graphe avec leur longueur associe.
Une autre application possible des fonctions dans les rgles rcursives est la manipulation dobjets structurs. Par exemple, des listes peuvent tre manipules avec la
fonction concatnation de deux listes X et Y, note X|Y. La base de donnes peut tre
compose dun prdicat dfinissant lensemble des listes constructibles partir de n
lments. On spcifie lajout (par la fin) dune liste X une liste Y comme tant une
liste Z dfinie par le prdicat AJOUT(X,Y,Z), puis linversion des lments dune
liste X comme tant une liste Y dfinie par le prdicat INVERSE(X,Y). Les rgles
suivantes dfinissent ces prdicats drivs ([] dsigne la liste vide) :
(r1)
AJOUT(X,[],X|[]) LISTE(X)
(r2)
AJOUT(X,W|Y,W|Z) AJOUT(X,Y,Z),LISTE(W)
(r3)
INVERSE([],[])
(r4)
INVERSE(W|X,Y) INVERSE(X,Z),AJOUT(W,Z,Y)
AJOUT et INVERSE sont ainsi deux prdicats rcursifs linaires.
Le problme qui se pose est bien sr dvaluer des questions portant sur des prdicats
rcursifs. Ces questions spcifient en gnral des constantes pour certaines variables,
ou des ensembles de constantes (question avec , <, ,>). Voici quelques questions
typiques sur les prdicats dfinis prcdemment :
(1) Qui sont les anctres de Jean ?
? ANC(x,Jean)
(2) Pierre est-il un anctre de Jean ?
? ANC(Pierre,Jean)
(3) Qui sont les cousins de mme gnration de Jean ?
? MG(Jean,x)
(4) Qui sont les chefs au mme niveau que Jean ?
? MC(Jean,x)
(5) Quel est linverse de la liste [1,2,3,4,5] :
? INVERSE([1,2,3,4,5], x)
Il est bien sr possible de remplacer par des constantes tout sous-ensemble de paramtres afin de retrouver les autres (cependant, selon les instanciations, DATALOGfonc
peut conduire des rponses infinies comme vu ci-dessus), ou encore dinstancier
tous les paramtres afin dobtenir une rponse boolenne du type VRAI/FAUX.
Dans la suite, nous allons tudier les principales solutions proposes, en commenant par les solutions simples, en gnral peu performantes ou incompltes. Nous
tudierons ensuite les solutions interprtes qui transforment progressivement la
requte en sous-requtes adresses au SGBD, puis les solutions compiles qui, dans
un premier temps, gnrent un programme dalgbre relationnelle et dans un
deuxime temps demandent lexcution de ce programme. Bien que dcrivant les
principales approches, notre tude est loin dtre complte. En particulier, nous
ignorons des approches importantes bases sur des rgles de rcriture [Chang81],
des automates [Marque-Pucheu84] ou une mthode de rsolution adapte
[Henschen84].
Cette mthode de calcul de point fixe part donc des faits de la base et calcule les instances des prdicats drivs par application des rgles afin de rpondre la question.
En gnral, une valeur R0 est calcule pour le prdicat rcursif partir des rgles
dinitialisation. Puis, par un programme de lalgbre relationnelle qui rsulte dune
compilation lmentaire de la rgle rcursive, on effectue un calcul itratif
R = R E(R), o E est lexpression de lalgbre relationnelle traduisant la rgle
rcursive. Le processus sarrte quand lapplication de E R ne permet pas de gnrer
de nouveau tuple : on a alors le point fixe du prdicat rcursif dfini par R = E(R). Ce
point fixe existe en DATALOG [Aho-Ullman79]. Un programme de calcul naf dune
relation rcursive R scrit donc comme reprsent figure XV.23, E tant une expression de lalgbre relationnelle drive de la rgle rcursive.
Procedure Nave (R) {
R:= R0 ;
Tant que R change Faire
R := R E(R) ;
}
Par exemple, dans le cas des anctres, on initialisera ANC par la rgle r1 avec les
parents, puis on appliquera la rgle r2 en effectuant une boucle de jointures de la relation ANC avec la relation PAR, et ce jusqu ce que lon ne gnre plus de nouvel
anctre. Le calcul est illustr figure XV.24. Le processus sera similaire pour gnrer la
relation MC : les rgles r1 et r2 permettent de lui attribuer une valeur initiale MC0, puis
les jointures des relations CHEF,MC0,MSER,MC0,CHEF permettront de calculer MC1.
De manire itrative, les jointures de CHEF,MCi,MSER,MCi,CHEF permettront de calculer MCi+1. Le calcul sarrtera quand aucun nouveau tuple sera gnr : on aura
obtenu le point fixe de la relation MC qui dcrit toutes les personnes de la base un
mme niveau hirarchique.
RGLES
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y)
PROGRAMME NAF
ANC := ;
while "ANC changes" do
ANC := ANC PAR
AN
CALCULS SUCCESSIFS
PARENT
ANCETRE
ASC
DESC
Jack
Jack
Ted
Pierre
Jean
Marie
Jack
Ted
ASC
DESC
Jack
Jack
Ted
Pierre
Ted
Ted
Pierre
Jean
Marie
Jack
Ted
Jean
Marie
Jack
ANCETRE(x,Jean) ASC
DESC
Jack
Ted
Pierre
Jean
Jean
Jean
ANCETRE
ANCETRE
ASC
DE
Jack
Jack
Ted
Pierre
Je
Ma
Ja
T
ASC
DE
Jack
Jack
Ted
Pierre
Ted
Ted
Pierre
Pierre
Pierre
Je
Ma
Ja
T
Je
Ma
Ja
Je
Ma
Si les programmes de rgles sont en DATALOG pur, comme pour ANC et MC, il
nexiste pas de fonction pour gnrer des valeurs qui ne sont pas dans la base : ceci
garantit la finitude du processus de gnration [Aho-Ullman79]. Dans le cas des listes,
la stratgie bottom-up ne peut tre applique telle quelle ; en effet, par ajout de listes,
on gnre des listes sans fin. Le processus de gnration ne se termine pas.
Une tude plus dtaille du processus de gnration naf dmontre plusieurs faiblesses
de la mthode, outre le fait quune terminaison nest garantie quen cas dabsence de
fonction :
1. chaque itration, un travail redondant est effectu, qui consiste refaire les infrences de litration prcdente ; cela provient du fait que lon cumule les rsultats
avec les anciens et que lon applique nouveau la jointure tous les rsultats sans
distinction.
2. Dans le cas o des constantes figurent dans la question, un travail inutile est effectu car la gnration produit des rsultats qui ne figurent pas dans la rponse ; ils
sont limins par la slection finale. Par exemple, pour calculer les seuls anctres de
Jean, le processus conduit gnrer les anctres de toutes les personnes de la base.
Voici maintenant les principales mthodes qui rpondent ces critiques.
Dans le cas de rgles linaires, lapproche consiste remplacer litration i la relation rcursive Ri produite jusque-l par Ri = Ri Ri1. Si E(R) est lexpression de
lalgbre relationnelle reprsentant le corps de la rgle rcursive, on calcule alors
Ri+1 = E(Ri) Ri, puis Ri+1 = Ri Ri+1. Dans le cas de rgles non linaires (par
exemples quadratiques), le problme est plus complexe car il faut aussi considrer les
infrences possibles entre les anciens tuples de Ri et les nouveaux de Ri. tant donn
lexpression Ri+1 = E(Ri) o E est une expression de lalgbre relationnelle, il est toujours possible de calculer Ri+1 = E(Ri) par drivation de E. On peut ainsi transformer un programme dalgbre relationnelle effectuant un chanage avant naf en un
programme effectuant un chanage avant semi-naf, ce qui permet dviter le travail
redondant.
Par exemple, dans le cas des anctres, il suffira deffectuer chaque itration la jointure de la relation parent avec les nouveaux tuples anctres gnrs ltape prcdente. Dans le cas de la relation MC, il faudra effectuer litration i les jointures :
CHEF
CHEF
CHEF
MCi
MCi
MCi
MSER
MSER
MSER
MCi
MCi
MCi
CHEF
CHEF
CHEF
afin de considrer toutes les infrences nouvelles possibles, puis lunion des rsultats
et la diffrence avec les rsultats dj connus pour obtenir Ri+1. Le processus diffrentiel apparat donc ici comme assez lourd, mais il vite la jointure CHEF MCi
MSER MCi CHEF.
Fond sur les principes prcdents, lalgorithme semi-naf [Bancilhon86b] effectue
donc un calcul diffrentiel de la relation rcursive R comme reprsent figure XV.25.
Quand les mmes tuples ne peuvent tre produits deux fois par deux itrations diffrentes, la diffrence R = R R nest pas ncessaire. Ce cas ncessite lacyclicit
des rgles et des donnes [Gardarin87], comme dans le cas du calcul des anctres de
Jean illustr figure XV.26 (page suivante).
Procedure SemiNave (R) {
R := R0
R := R ;
Tant que R faire {
R = E(R,R) ;
R = R R ;
R = R R ;
};
} ;
RGLES
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y)
PROGRAM SEMI-NAF
PARENT
ASC
DESC
Jack
Jack
Ted
Pierre
Jean
Marie
Jack
Ted
ANC := PARENT ;
ANC := ANC;
Tantque " ANC changes" faire
ANC := PARENT
ANC
ANC := ANC ANC ;
CALCULS SUCCESSIFS
ANC
ASC
DESC
Jack
Jack
Ted
Pierre
Jean
Marie
Jack
Ted
ASC
DESC
Ted
Ted
Pierre
Jean
Marie
Jack
ASC
DESC
Pierre
Pierre
Jean
Marie
DESC
Jack
Ted
Pierre
Jean
Jean
Jean
ANC
ANC
ANC
ANC
ANC
ASC
DESC
Jack
Jack
Ted
Pierre
Jean
Marie
Jack
Ted
ASC
DESC
Jack
Jack
Ted
Pierre
Ted
Ted
Pierre
Jean
Marie
Jack
Ted
Jean
Marie
Jack
ASC
DESC
Jack
Jack
Ted
Pierre
Ted
Ted
Pierre
Pierre
Pierre
Jean
Marie
Jack
Ted
Jean
Marie
Jack
Jean
Marie
de la question pour remonter aux faits via les rgles. En consquence, elle est qualifie de stratgie top-down comme vu ci-dessus. Malheureusement, dans le cas de
rgles rcursives la mthode top-down peut conduire boucler.
Nous allons tout dabord montrer une application de la mthode dans le cas favorable.
Par exemple, avec la rgle :
ANC(x,y) PAR(x,z), ANC(z,y)
la question ANC(Jean,y) gnre la sous-question PAR(Jean,z),ANC(z,y). Tenter de
rsoudre directement ANC(z,y) en chanage arrire conduit boucler. Par contre, si
lon value PAR(Jean,z) sur la relation de base PARENT, on obtient des constantes
c0, c1... pour z. Il devient alors possible de rsoudre en chanage arrire
ANC(c0,y),ANC(c1,y)...
qui gnrent les sous-questions
PAR(c0,z),ANC(z,y),PAR(c1,z),ANC(z,y), etc. Le processus sarrte
quand il nexiste plus de sous-question gnrable du type PAR(ci,z) ayant une
rponse non vide.
La mthode nest cependant applicable que dans le cas particulier o la constante de
la question se propage pour regnrer la mme sous-question. Par exemple, dans le
cas de la rgle :
ANC(x,y) ANC(x,z), PAR(z,y)
la question ANC(Jean,y) conduit gnrer la sous-question ANC(Jean,z).
Changer y en z ne fait pas progresser le problme et le processus boucle totalement.
Nous verrons dans la suite des extensions de cette approche la Prolog qui permettent dviter le bouclage en utilisant les autres rgles et en mlant chanage
arrire-chanage avant. Auparavant, nous allons tudier plus en dtail la propagation
des constantes dans les rgles.
Les propagations dinformations dans les rgles se reprsentent donc par des graphes.
Un graphe de propagation pour une rgle est un graphe tiquet qui dcrit comment
les constantes obtenues par la tte de la rgle se propagent aux autres prdicats de la
rgle. Il existe plusieurs graphes de propagation possibles pour une rgle, suivant les
choix de propagation effectus. Pour faciliter la comprhension et viter de rpter
des morceaux de rgles, une reprsentation simplifie avec des bulles reprsentant les
sommets du graphe est propose. Les prdicats de la rgle sont crits de gauche
droite, depuis la tte jusquau dernier prdicat de la condition. Un sommet du graphe
(donc reprsent par une bulle) est, soit un groupe de prdicats, soit un prdicat rcursif. Un arc N p relie un groupe de prdicats N une occurrence dun prdicat
rcursif p. Larc N p est tiquet par des variables dont chacune apparat dans un
prdicat de N et dans p. Un graphe de propagation est valide sil existe un ordre des
sommets (appel ici ordre de validit) tel que, pour chaque arc, tout membre de sa
source apparaisse avant sa cible. Pour faciliter la visualisation dun graphe de propagation valide, il est souhaitable dcrire les occurrences de prdicats selon lordre de
validit. Les figures XV.27 et XV.28 prsentent deux graphes de propagation valides
pour les rgles rcursives des exemples Anctres et Chefs.
z
ANC (z,y)
z1
z3
MC (z1,z2)
MSER (z2,z3)
MC (z3,z4)
CHEF (y,z4)
La signification intuitive dun graphe de propagation valide est la suivante : en supposant instancie la jointure des prdicats entours par une bulle source dun arc, il
serait possible de propager les valeurs des variables tiquettes vers le prdicat cible de
larc. Si la bulle source contient le prdicat de tte de la rgle, un arc modlise la pro-
pagation de constantes vers un prdicat rcursif en chanage arrire suite une instantiation dune variable de la tte. Une telle propagation est donc une propagation par
effet de bord.
Un graphe de propagation valide est linaire si pour tout arc N p, N contient tous
les nuds qui prcdent p selon lordre de validit. Suivant [Beeri87], nous dirons
quun graphe de propagation valide linaire est total si toute variable dun prdicat
rcursif r cible dun arc apparaissant dans un prdicat qui prcde r tiquette un arc
entrant dans r. Nous utiliserons les graphes de propagation de constantes dans la suite,
notamment pour la mthode des ensembles magiques gnraliss [Beeri87].
La tte de la rgle est tout dabord signe selon lunification ralise avec la question.
La signature est ensuite propage aux autres prdicats rcursifs en suivant les arcs du
graphe de propagation et en marquant 1 les variables correspondant aux tiquettes
dans les prdicats cibles [Beeri87]. Lutilisation de rgles signes permet de distinguer
des prdicats de mmes noms ayant des variables instancies diffrentes. Cela est trs
utile dans le cas de rgles non stables, o les constantes changent de position dans les
occurrences dun mme prdicat [Henschen-Naqvi84]. Voici les rgles rcursives
signes pour les Anctres et les Chefs, selon les graphes de propagation reprsents respectivement figure XV.27 et XV.28, pour les questions ? ANC(Jean,x)
et ? MC(Jean,y) :
ANC10(x,y) PAR(x,z), ANC10(z,y)
MC10(x,y) CHEF(x,z1),MC10(z1,z2),MSER(z2,z3),
MC10(z3,z4),CHEF(y,z4)
Dans la suite, nous utiliserons les rgles signes pour tous les algorithmes bass sur la
rcriture de rgles.
(1)
quune instance de relation dfinit en fait des fonctions ; chaque fonction transforme
un ensemble de valeurs dune colonne dans lensemble de valeurs correspondant dans
une autre colonne. Ainsi toute question ? R(a,y) est interprte comme une fonction r
appliquant lensemble des parties du domaine de a dans lensemble des parties du
domaine de y, cest--dire avec des notations classiques, r : 2dom(a) 2dom(y). valuer
la question ? R(a,y) revient alors valuer la fonction r({a}).
Etant donns une question et un ensemble de rgles, un algorithme permet de gnrer
une quation fonctionnelle au point fixe du type r = F(r), o F est une expression
fonctionnelle. Pour ce faire, des oprations monotones entre fonctions ont t introduites :
1. la composition de deux fonctions f o g (X) = f(g(X)) modlise en fait une jointure
suivie dune projection ;
2. laddition (f+g) (X) = f(X) g(X) modlise lunion ;
3. lintersection (f g) (X) = f(X) g(X) permet de modliser des jointures
cycliques.
Dans le cas de rgles prdicats binaires sans fonction, lalgorithme est simple et
repose sur un graphe de connexion des variables dans la rgle. Ce graphe reprsente
simplement par un nud chaque variable et par un arc les prdicats (ou un hyper arc
dans le cas de prdicats non binaires). Il est orient pour visualiser les passages
dinformation en chanage arrire. Ce graphe peut tre peru comme une simplification du graphe de propagation dinformation vu ci-dessus.
La gnration dquation fonctionnelle seffectue par un algorithme de cheminement
dans le graphe, chaque arc tant interprt comme une fonction de calcul du nud
cible en fonction du nud source. Cet algorithme dcrit dans [Gardarin86] est appliqu ci-dessous aux cas des anctres et des chefs. Pour simplifier les notations, pour
toute relation binaire R(x,y), R(X) dnote la fonction qui applique {x} sur {y} et
R(Y) celle qui applique {y} sur {x}. Aprs obtention, lquation fonctionnelle au
point fixe est simplement rsolue par application du thorme de Tarski [Tarski55].
Nous illustrons tout dabord la mthode avec le problme des anctres. La
figure XV.30 reprsente les graphes de connexion des variables des rgles :
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y).
PAR
x
PAR
y
ANC
ANC
y
ANC
De manire plus gnrale, la mthode sapplique trs simplement aux rgles fortement linaires de la forme :
R(X,Y) B1(X,Y)
R(X,Y) B2(X,X1),R(X1,Y1),B3(Y1,Y)
o B1, B2 et B3 sont des relations de base ou simplement des jointures/restrictions de
relations de base et o X, Y, X1, Y1 reprsentent des variables ou des n-uplets de
variables. Le graphe de connexion des variables de ce type de rgles est reprsent
figure XV.32.
B1
x
B2
y
x1
y1
B3
y
Lquation fonctionnelle au point fixe est, pour des questions du type ? R(a,Y) :
r(X) = b1(X) + b3(r(b2(X))).
Le thorme de Tarski permet dobtenir la forme gnrale de la solution :
r(X) = b1(X) + b3(b1(b2(X))) +... + b3n(b1(b2n(X))).
Figure XV.33 : Calcul des rponses des requtes sur rgles fortement linaires
8. RGLES ET OBJETS
De nombreuses tentatives pour combiner les bases de donnes objet et les rgles ont
t effectues. Citons notamment IQL [Abiteboul90], Logres [Ceri90], Coral
Les rgles en ROL sont organises en modules. Chaque module commence par des
dfinitions de variables valables pour tout le module, de la forme :
VAR <nom> IN <collection>.
Le nom dune variable est gnralement une lettre, alors quune collection est une
extension de classe ou une collection dpendantes, comme en OQL. Il est aussi possible dutiliser des variables symboliques (chanes de caractres), afin damliorer la
clart des programmes. Nous dfinissons simplement les variables :
VAR X IN Film, VAR Y IN X.Categories ;
VAR Z IN Calcul ;
La condition est analogue une qualification de requtes OQL. Cest une combinaison logique de conditions lmentaires. Une condition lmentaire permet de comparer deux termes. Un terme est une constante, un attribut, une expression de chemin ou
de mthode. Les actions sont :
Des insertion de valeurs. Une valeur ventuellement complexe (tuple par exemple)
est insre dans une collection temporaire ou persistante par la construction +<collection>(<valeurs>).
Des crations dobjets. Un objet est cr dans une collection temporaire ou persistante par la construction +<classe>(<paramtres>). La classe doit tre dfinie auparavant. Laction provoque simplement lappel au constructeur dobjet avec les paramtres indiqus.
Des destruction de valeurs. Une valeur dune collection est dtruite par la
construction <collection>(<valeurs>).
Des destructions dobjets. Un objet est dtruit dans une collection temporaire ou
persistante par la construction <classe>(). La classe doit tre dfinie auparavant.
Laction provoque simplement lappel au destructeur de lobjet avec les paramtres
indiqus sur les objets de la classe slectionns par la condition.
Des appels de mthodes. Toute mthode dfinie au niveau du schma est valide en
partie action prcde de + pour faciliter la lecture des expressions.
Un bloc dactions lmentaires (cration et destruction dobjets et/ou valeurs,
appels de mthodes). Une rgle peut avoir en consquence une suite dactions spares par des + et des . Elle peut donc accomplir des mises jour, des impressions,
etc.
Une smantique ensembliste type point fixe est donne au langage par traduction en
algbre dobjet complexe [Gardarin94]. Les difficults des langages objets est quils
intgrent la fois la cration de nouveaux objets (linvention dobjets daprs
[Abiteboul90]) et les fonctions. De ce fait, il est facile dcrire des programmes infinis
ds quon utilise des rgles rcursives. notre connaissance, aucun compilateur nest
capable de dtecter les programmes non sains.
titre dillustration, nous dfinissons figure XV.35 deux rgles en ROL. La premire
ralise une suite dactions pour tous les films daventure dans lesquels joue Quinn
avec un salaire suprieur 1 000 $ de lheure. La seconde calcule la fermeture transitive de la relation Domine, puis imprime qui fut (transitivement) meilleur que
Marilyn. Il ny a pas de boucle infinie car MEILLEUR est dfini comme un ensemble.
Il nen serait rien avec une liste. Notons aussi que la structure de blocs imbriqus permet de dfinir des ordres de calcul, donc une certaine stratification. De tels langages
sont complexes, mais puissants. Les perspectives dapplications sont importantes
daprs [Nicolas97].
Au-del des corps de rgles, les conditions permettent dexprimer des contraintes
dintgrit et peuvent tre utilises dans les ordres impratifs conditionnels (if et
while). DEL supporte aussi de nombreux prdicats prdfinis appelables depuis les
conditions ou les ordres impratifs. Le temps est galement support sous diffrentes
formes. DEL apparat donc comme un langage trs puissant, capable damliorer la
productivit des dveloppeurs dapplications intelligentes. Limplmentation du systme dductif a t ralise Bull, partir des travaux effectus la fin des annes 80
lECRC Munich. Un grant dobjets spcifique avec des mthodes de reprise et de
gestion des accs concurrents efficaces sert de support au moteur dinfrence qui
applique un driv de la mthode QoSaQ vue ci-dessus.
9. CONCLUSION
Ce chapitre a propos une synthse des recherches et dveloppements en matire de
bases de donnes dductives. Parmi les multiples approches, nous avons surtout
insist sur lintgration dun langage de rgles au sein dun SGBD relationnel tendu.
Cette approche est probablement valable long terme, bien que quelques produits
commencent apparatre. Une approche plus immdiate consiste coupler un interprteur de rgles un SGBD relationnel. De nombreux produits offrent de tels couplages. Ils constituent une approche trs primitive aux bases de donnes dductives.
Plusieurs caractristiques souhaitables dun langage de rgles pour bases de donnes
ont t tudies. La plupart ont t intgres un langage de programmation logique
appel DATALOG, qui a une smantique de type point fixe. Les extensions essentielles de DATALOG ncessaires la programmation sont finalement les fonctions et
les attributs multivalus (ensembles). Lapproche DATALOG est utile pour la comprhension des problmes, mais sans doute difficile utiliser vu sa syntaxe plutt formelle. Un langage plus pratique que DATALOG peut tre driv de SQL, partir des
qualifications de questions et des actions dinsertion et de mise jour. Il sagit essentiellement dun choix de syntaxe. De mme, avec les objets il est possible de driver
un langage de rgles du langage OQL, comme le montre le langage ROL bauch cidessus. DEL est une autre variante plus proche de DATALOG. La puissance de tous
ces langages est rsume figure XV.36.
Le problme de loptimisation des requtes dans un contexte de rgles rcursives est
complexe. Vous pouvez consulter [Ceri91] pour un approfondissement. Loptimisation
en prsence de fonctions et dobjets complexes est encore mal connue. De plus, les
techniques de maintenance de la cohrence des rgles et des donnes sont peine tudies. Finalement, il nexiste encore gure de SGBD dductif fonctionnant avec des
applications en vraie grandeur, sans doute lexception de Validity. Cependant, les
techniques essentielles pour tendre un SGBD relationnel ou objet avec des rgles
sont connues. Elles ont t prsentes dans ce chapitre.
IQL
ROL
DEL
Invention d'objet
Mise jour
DATALOGFonc, Neg
Algbre relationnelle
avec fonctions
Rcursion
10. BIBLIOGRAPHIE
[Abiteboul89] Abiteboul S., Kanellakis P., Object Identity as a Query Language
Primitive , ACM SIGMOD Intl. Conf. on Management of Data, p. 159-173,
1989.
Une prsentation des fondements du langage IQL, un langage de rgles
capable de crer de nouveaux objets. IQL utilise des identifiants dobjets pour
reprsenter des structures de donnes partages avec de possibles cycles, pour
manipuler les ensembles et pour exprimer toute question calculable. IQL est un
langage typ capable dtre tendu pour supporter des hirarchies de types.
[Abiteboul90] Abiteboul S., Towards a Deductive Object-Oriented Database
Language , Data and Knowledge Engineering, vol. 5, n 2, p. 263-287, 1990.
Une extension dIQL vers un langage plus praticable. Un langage de rgles
pour objets complexes est prsent, incluant toutes les extensions de Datalog,
linvention dobjets, lappel de mthodes et la construction de fonctions drives.
[Abiteboul91] Abiteboul S., Simon E., Fundamental Properties of Deterministic and
Nondeterministic Extensions of Datalog , Theoretical Computer Science,
n 78, p. 137-158, 1991.
Une tude des diffrentes extensions de Datalog avec ngations et mises jour.
La puissance des diffrents langages obtenus est caractrise en termes de
complexit.
[Abiteboul95] Abiteboul S., Hull R., Vianu V., Foundations of Databases, AddisonWesley Pub. Comp., Reading, Mass, USA, 1995.
Ce livre prsente les fondements thoriques des bases de donnes. Une large
place est donne Datalog et ses extensions, ainsi qu la smantique de tels
langages.
[Aho79] Aho A.V., Ullman J.D., Universality of data retrieval languages , Conf.
POPL, San-Antonio, Texas, 1979.
Cet article est lun des premiers souligner lincapacit des langages dinterrogation de bases de donnes supporter la rcursion. La notion de plus petit
point fixe dune quation de lalgbre est notamment introduite.
[Aiken92] Aiken A., Widom J., Hellerstein J., Behavior of Database Production
Rules: Termination, Confluence, and Observable Determinism , ACM SIGMOD Int. Conf. on Management of Data, San Diego, Calif., 1992.
Des mthodes danalyse statiques dun programme de rgles sont prsentes
pour dterminer si un ensemble de rgles de production rfrenant une base
de donnes : (1) se terminent ; (2) produisent un tat base de donnes unique ;
(3) produisent une chane dactions observables unique.
[Apt86] Apt C., Blair H., Walker A., Towards a theory of declarative knowledge ,
Foundations of Deductive Databases and Logic Programming, Minker J. Ed.,
Morgan Kaufmann, Los Altos, 1987, aussi IBM Research Report RC 11681,
avril 1986.
Une tude sur les points fixes minimaux et la stratification. Il est montr quun
programme avec ngation plusieurs points fixes minimaux et que la stratification consiste choisir le plus naturel.
[Bancilhon86a] Bancilhon F., Maier D., Sagiv Y., Ullman J.D., Magic sets and other
strange ways to implement logic programs , 5 th ACM Symposium on
Principles of Database Systems, Cambridge, USA, 1986.
Cet article expose la mthode des ensembles magiques pour effectuer les restrictions avant la rcursion lors de lvaluation de questions dductives.
Comme la mthode dAlexandre, les ensembles magiques rcrivent les rgles
en simulant un chanage arrire partir de la question. Une valuation en
chanage avant permet alors de ne sintresser quaux seuls faits capables de
gnrer des rponses (les faits relevants).
[Bancilhon86b] Bancilhon F., Ramakrishnan R., An Amateurs Introduction to
Recursive Query Processing Strategies , ACM SIGMOD Intl. Conf. on
Management of Data, Washington D.C., mai 1986.
mises jour en ttes de rgles avec lexemple du circuit lectrique et la modlisation du processus dvaluation de questions par les rseaux de Petri prdicats. Les principales techniques doptimisation de rseaux par remonte des
slections sont dcrites.
[Gardarin86] Gardarin G., de Maindreville C., Evaluation of Database Recursive
Logic Programs as Recurrent Function Series , ACM SIGMOD Intl. Conf. on
Management of Data, Washington D.C., May 1986.
Cet article introduit lapproche fonctionnelle dcrite ci-dessus. La rcriture est
base sur des graphes de connexion de variables.
[Gardarin87] Gardarin G., Magic functions : A technique for Optimization of
Extended Datalog Recursive Programs , Intl. Conf. on Very Large Data Bases,
Brighton, England, septembre 1987.
Cet article propose une deuxime version de lapproche fonctionnelle plus
gnrale. Une question et les rgles associes sont rcrites en systmes
dquations fonctionnelles. Le systme est alors optimis puis valu sur la
base de donnes. La technique est particulirement adapte aux rgles rcursives.
[Gardarin94] Gardarin G., Object-Oriented Rule Language and Optimization
Techniques , Advances in Object-Oriented Systems, Springer Verlag,
Computer and Systems Sciences Series, vol. 130, p. 225-249, 1994.
Cet article compare les diffrents langage de rgles et introduit le langage ROL
pour BD objet de type C++ persistant.
[Hanson92] Hanson E., Rule Condition Testing and Action Execution in Ariel ,
ACM SIGMOD Int. Conf. on Management of Data, San Diego, Calif., 1992.
Cet article dcrit les tests des conditions des rgles et lexcution des actions
dans le SGBD actif Ariel. Pour tester les conditions, Ariel utilise un rseau de
discrimination maintenu en mmoire proche du rseau Rete, bien connu dans
les systmes de production en intelligence artificielle. Ce rseau est une version
modifie du rseau Treat qui vite de maintenir les donnes correspondant
certaines jointures.
[Hayes-Roth85] Hayes-Roth F., Rule Based systems , Communications of the
ACM, vol. 28, n 9, septembre 1985.
Une introduction aux systmes de rgles de production et leurs applications.
[Kiernan90] Kiernan J., de Maindreville C., Simon E., Making Deductive Database
a Practical Technology: A Step Forward , ACM SIGMOD Intl. Conf. on
Management of Data, Atlantic City, juin 1990.
Une prsentation du langage RDL1 et de son implmentation. Le langage
RDL1 supporte toutes les extensions de Datalog vues dans ce chapitre avec une
syntaxe plus proche du calcul relationnel de tuples. De plus, il possde une par-
tie contrle permettant de spcifier les priorits dexcution des rgles. RDL1 a
t implant lINRIA laide de rseaux de Petri prdicats tendus rsultant de la compilation des rgles. Ces rseaux sont interprts sur la couche
basse du systme SABRINA qui offre une interface proche dune algbre relationnelle tendue avec des types abstraits.
[Kifer87] Kifer M., Lozinskii E., Implementing Logic Programs as a Database
System , IEEE Intl. Conf. on Data Engineering, Los Angeles, 1987.
Une prsentation dun prototype supportant Datalog. Lide essentielle de cet
article est de compiler un programme logique en un rseau de transitions (le
system graph ) reprsentant les rgles. Le rseau peut alors tre optimis
par des techniques de gnration de sous-questions.
[Kifer89] Kifer M., Lausen G., F-Logic : A Higher-Order Language for Reasoning
about Objects, Inheritance and Schema , ACM SIGMOD Intl. Conf. on
Management of Data, Portland, 1989.
Une logique pour objets complexes. Cet article dfinit un langage de rgles
supportant hritage, mthodes et objets complexes. Une mthode de rsolution
tendue est propose pour dmontrer un thorme dans un tel contexte.
[Kuper86] Kuper G., Logic programming with sets , Proc. ACM PODS, 1987.
Cet article discute du support des ensembles en programmation logique.
[Lloyd87] Lloyd J., Foundations of logic programming, 2e dition, Springer Verlag, 1987.
Le livre de base sur les fondements de la programmation logique. Les diffrentes smantiques dun programme logique sont introduites. Les techniques de
preuve de type rsolution avec ngation par chec sont dveloppes.
[McKay81] MacKay D., Shapiro S., Using active connection graphs for reasoning
with recursive rules , Proc. Intl. Conf. on Artificial Intelligence IJCAI, 1981.
Cet article introduit les PCG comme support danalyses de rgles et mthodes
de preuves.
[Minker82] Minker J., Nicolas J.M., On Recursive Axioms in Deductive
Databases , Information Systems Journal Vol.8, n 1, p. 1-13, Jan. 1982.
Un des premiers articles sur le problme des rgles rcursives.
[Naqvi89] Naqvi S., Tsur S., A Logical Language for Data and Knowledge Bases ,
Principles of Computer Science, Computer Science Press, New York, 1989.
Ce livre dcrit le langage LDL. LDL est un langage driv de Prolog pour
manipuler les bases de donnes relationnelles supportant des objets complexes
(ensembles). Il est assez proche de Datalog tendu avec la ngation, des mises
jour et des ensembles. Une version oprationnelle a t dveloppe MCC et
distribue dans les universits amricaines. Le livre est illustr de nombreux
exemples.
[Next98] Next Century Media, Validity Database System, DEL Language Reference
Manual, Next Century Media Inc., Versailles, France
Ce document prsente le langage DEL du SGBD dductif (DOOD) Validity,
commercialis par Next Century Media, une start-up issue du groupe Bull.
[Nicolas97] Nicolas J-M., Deductive Object Oriented Databases Technology,
Products and Applications : Where are we ? , Intl. Symp. On Digital Media
Information Base DBIM97, Nara, Japan, Nov. 1997.
Cet article donne une vue quelque peu optimiste du pass, du prsent et du
futur des bases de donnes dductives. Il est crit par le prsident de Next century Media.
[Nilsson80] Nilsson N., Principles of Artificial Intelligence, Tioga Publication, 1980.
Un des livres de base sur lintelligence artificielle. Les systmes de rgles de
production pertinents aux bases de donnes dductives sont particulirement
dvelopps.
[Przymusinski88] Przymusinski T., On the declarative semantics of stratified deductive databases and logic programs , in Foundations of Deductive Databases
and Logic Programming, Morgan & Kaufmann, Los Altos, 1988.
Une discussion de la smantique des programmes de rgles stratifis. La
smantique inflationniste o toutes les rgles sont dclenches en parallle est
notamment introduite.
[Ramakrishnan95] Ramakrishnan R., Ullman J.D., A Survey of Deductive Database
Systems , Journal of Logic Programming, vol. 23, n 2, Elsevier Science Pub.
Comp., New York, 1995.
Une vue densemble rcente des bases de donnes dductives et de leurs
apports et perspectives thoriques.
[Reiter78] Reiter R., On closed world data bases , in Logic and databases, dit
par Gallaire et Minker, Plenum Press, New York, 1978.
Larticle de base sur lhypothse du monde ferm.
[Reiter84] Reiter R., Towards a Logical Reconstruction of Relational Database
Theory , in On Conceptual Modelling, p. 191-234, Springer Verlag, 1984.
Une redfinition des bases de donnes relationnelles en logique. Les diffrents
axiomes ncessaires linterprtation dune base de donnes comme une thorie en logique sont prsents : fermeture des domaines, unicit des noms,
axiomes dgalit, etc. Les calculs relationnels sont unifis et gnraliss.
[Rohmer86] Rohmer J., Lescur R., Kerisit J.M., The Alexander Method A
Technique for the Processing of Recursive Axioms in Deductive Databases ,
New Generation Computing, n 4, p. 273-285, Springer-Verlag, 1986.
Les auteurs introduisent la mthode dAlexandre, premire mthode propose
ds 1985 lors du stage de J.M. Kerisit pour transformer les rgles rcursives en
rgles de production appliques aux seuls faits relevants. Cette mthode est trs
proche de la mthode des ensembles magiques propose un peu plus tard par
Bancilhon et Ullman.
[Sacca86] Sacca D., Zaniolo C., Magic Counting Methods , MCC Technical Report
DB-401-86, Dec. 1986.
Cet article dcrit la mthode de comptage tudie ci-dessus pour optimiser les
rgles rcursives.
[Simon92] Simon E., Kiernan J., de Maindreville C., Implementing High Level
Active Rules on top of Relational DBMS , Proc. of the 18th Very Large Data
Bases Int. Conf., Morgan Kaufman, Vancouver, Canada, 1992.
Cet article prsente le langage de dfinition de dclancheurs driv du langage
de rgle RDL1. Les rgles deviennent actives du fait quelles sont dclenches
suite des vnements (par exemple des mises jour). Elles sont dfinies dans
un langage de haut niveau avec une smantique de point fixe. Un grant dvnements implment au-dessus du SGBD SABRINA dclenche lvaluation des
rgles.
[Srivastava93] Srivastava D., Ramakrishnan, Seshadri P., Sudarshan S., Coral++ :
Adding Object-Orientation to a Logic Database Language , Proc. of the
19th Very Large Data Bases Int. Conf., Morgan Kaufman, p. 158-170, Dublin,
Ireland, 1993.
Cet article prsente le langage de rgles CORAL, extension de Datalog avec
des concepts objet. Le modle objet de CORAL est inspir de C++. Les
mthodes sont crites en C++. CORAL est compil en C++. Ce langage a t
ralis luniversit du Maddisson aux USA.
[Stonebraker86] Stonebraker M., Rowe A.L., The Postgres Papers , UC Berkeley,
ERL M86/85, BERKELEY, novembre 1986.
Une collection darticles sur POSTGRES. Ce systme supporte la dfinition de
rgles exploites lors des mises jour. Les rgles sont donc utilises pour dfinir des dclencheurs. Elles permettent de rfrencer des objets complexes dfinis sous forme de types abstraits de donnes. Elles se comportent comme des
rgles de production de syntaxe if <opration> on <relation> then <oprations>. Les oprations incluent bien sr des mises jour. Un systme de priorit est propos pour rgler les conflits en cas de rgles simultanment dclenchables. Ce mcanisme de rgles est aujourdhui commercialis au sein du
SGBD INGRES.
[Tarski55] Tarski A., A lattice theoretical fixpoint theorem and its applications ,
Pacific journal of mathematics, n 5, p. 285-309, 1955.
Larticle de base sur la thorie du point fixe. Il est notamment dmontr que
toute quation au point fixe construite avec des oprations monotones sur un
treillis a une plus petite solution unique. Ce thorme peut tre appliqu pour
dmontrer que lquation au point fixe R = F(R) sur le treillis des relations, o
F est une expression de lalgbre relationnelle sans diffrence, a un plus petit
point fixe.
[Tsur86] Tsur D., Zaniolo C., LDL: a Logic-Based Data Language , Very Large
Databases Int. Conf., Kyoto, Japon, septembre 1986.
Une prsentation synthtique du langage LDL1 implment MCC. Cet article
insiste notamment sur le support de la ngation, des ensembles et des fonctions
externes.
[Ullman85] Ullman J.D., Implementation of logical query languages for
Databases , ACM SIGMOD Intl. Conf. on Management of Data, aussi dans
ACM TODS, vol. 10, N. 3, p. 289-321, 1986.
Une description des premires techniques doptimisation de programmes
Datalog. Le passage dinformations de ct est notamment introduit pour
remonter les constantes dans les programmes Datalog, y compris les programmes rcursifs.
[VanEmden76] Van Emden M., Kowalski R., The semantics of predicate logic as a
programming language , Journal of the ACM Vol.23, n 4, octobre 1976.
Une premire tude sur la smantique du point fixe, dveloppe dans le
contexte de la programmation logique. Plus tard, cette approche a t retenue
pour dfinir la smantique de Datalog.
[Vieille86] Vieille L., Recursive axioms in deductive databases : the query subquery approach , Proc. First Intl. Conference on Expert Database Systems,
Charleston, 1986.
Cet article dcrit la mthode QSQ, dont lextension QoSaQ a t implment
dans le prototype EKS lECRC entre 1986 et 1990. Ce prototype a t ensuite
repris pour donner naissance au produit Validity, un des rares DOOD.
[Zaniolo85] Zaniolo C., The representation and deductive retrieval of complex
objects , 11th Int Conf. on Very Large Data Bases, aot 1985.
Une extension de lalgbre relationnelle au support de fonctions. Cet article
prsente une extension de lalgbre relationnelle permettant de rfrencer des
fonctions symboliques dans les critres de projection et de slection, afin de
manipuler des objets complexes. Des oprateurs dductifs de type fermeture
transitive tendue sont aussi intgrs.
[Zaniolo86] Zaniolo C., Safety and compilation of non recursive horn clauses ,
MCC Tech. Report DB-088-85, 1986.
Une discussion des conditions assurant la finitude des prdicats gnrs par
des clauses de Horn et des questions poses sur ces prdicats.
Chapitre XVI
GESTION DE TRANSACTIONS
1. INTRODUCTION
En bases de donnes, le concept de transaction a t introduit depuis prs de trente ans
[Bjork72]. Ce concept est aussi dactualit dans les systmes dexploitation. Dans ce
chapitre, nous tudions les problmes lis la gestion de transactions dans les systmes de bases de donnes. Le concept de transaction est fondamental pour maintenir
la cohrence des donnes. Une transaction est une unit de mise jour compose de
plusieurs oprations successives qui doivent tre toutes excutes ou pas du tout. En
gestion, les transactions sont courtes (quelques secondes). En conception, elles peuvent tre beaucoup plus longues (quelques minutes voire quelques heures). Le SGBD
doit garantir les fameuses proprits ACID des transactions. Outre latomicit mentionne, les transactions effectuent des accs concurrents aux donnes qui doivent tre
contrls afin dviter les conflits entre lecteurs et crivains. Cela ncessite disoler
les mises jour dont les effets doivent par ailleurs tre durables. En consquence, la
gestion de transactions mlange intimement les problmes de fiabilit et de reprise
aprs panne avec les problmes de concurrence daccs. Les problmes de scurit
qui recouvrent la confidentialit sont aussi connexes.
Ce chapitre essaie de faire le point sur tous les aspects de la gestion de transactions
dans les SGBD centraliss. Aprs quelques rappels de base, nous traitons dabord les
problmes de concurrence. Nous introduisons la thorie de la concurrence, qui
sappuie sur le concept de srialisation, conduisant naccepter que les excutions
simultanes de transactions produisant les mmes rsultats quune excution squen-
tielle des transactions, cest--dire lune aprs lautre. Nous exposons la technique de
verrouillage qui est une mthode prventive de conflits plutt pessimiste. Bien
quentranant des difficults telles que le verrou mortel, cette mthode est de loin la
plus applique. Cependant, nous analysons aussi les mthodes optimistes qui laissent
les conflits se produire et les corrigent aprs, telles que lordonnancement par estampille, la certification et les contrles avec versions multiples.
Nous tudions ensuite les principes de la gestion de transactions. Tout repose sur les
algorithmes de validation et de reprise aprs panne. Nous approfondissons les outils
ncessaires ces algorithmes puis les diffrents algorithmes de validation et de
reprise, en incluant la validation en deux tapes, gnralement applique mme dans
les systmes centraliss. Comme exemple de mthode de reprise intgre, nous dcrivons la mthode ARIES implmente IBM, la rfrence en matire de reprise. Nous
terminons la partie sur les transactions proprement dites en prsentant les principaux
modles de transactions tendus introduits dans la littrature. Ces modles sont destins permettre un meilleur support des transactions longues, en particulier pour les
applications de conception qui ncessitent de longs travaux sur des objets complexes.
Ces modles sophistiqus commencent tre introduits dans les SGBD, notamment
dans les SGBD objet ou objet-relationnel.
Pour terminer ce chapitre, nous traitons du problme un peu orthogonal de confidentialit. Beaucoup peut tre dit sur la confidentialit. Nous rsumons lessentiel des
mthodes DAC (Discretionary Access Control) et MAC (Mandatory Access Control).
La premire permet dattribuer des autorisations aux utilisateurs et de les contrler, la
seconde fonctionne avec des niveaux de confidentialit. Nous concluons par quelques
mots sur le cryptage des donnes.
2. NOTION DE TRANSACTION
Un modle simplifi de SGBD se compose de programmes utilisateurs, dun systme
et de mmoires secondaires. Les programmes accdent aux donnes au moyen doprations du SGBD (Select, Insert, Update, Delete), gnralement en SQL. Ces oprations dclenchent des actions de lecture et criture sur disques (Read, Write), qui sont
excutes par le systme, et qui conduisent des entres-sorties sur les mmoires
secondaires. Afin de pouvoir dterminer les parties de programmes correctement excutes, le concept de transaction a t propos depuis longtemps.
Elles sappliquent toujours sur les donnes les plus rcentes. Un exemple typique de
transaction est fourni par le banc dessais TPC A [Gray91]. Il sagit de raliser le
dbit/crdit sur une base de donnes bancaire. Le benchmark a pour objectif la mesure
des performances du SGBD en nombre de transactions excutes par seconde.
La base se compose des tables Agences, Comptes, Caissiers et Historique (voir
figure XVI.1). Une agence gre 100 000 comptes, possde 100 caissiers et comporte
un systme avec 10 terminaux.
1
100000
Agences
Comptes
Caissiers
Historique
100
Taille pour 10 terminaux, avec rgle d'chelle (scaling rule)
Ces vingt dernires annes, lobjectif de tous les SGBD a t dexcuter un maximum
de telles transactions par seconde.
En pratique, les transactions doivent souvent cohabiter avec des requtes dcisionnelles, traitant un grand nombre de tuples en lecture, souvent pour calculer des agrgats. Par exemple, une requte dcisionnelle pourra calculer la moyenne des avoir des
comptes par agence comme suit :
SELECT B.BRANCHID, AVG(C.BALANCE)
FROM BRANCH B, ACCOUNT C
WHERE B.BRACHID = C.BRANCHID
GROUP BY B.BRANCHID ;
Une telle requte parcourt tous les comptes et peut en consquence empcher les transactions dbit/crdit de sexcuter. Elle peut aussi tre bloque par les transactions
dbit/crdit. Nous allons tudier les solutions aux problmes des transactions ci-dessous.
2.2.1. Atomicit
Une transaction doit effectuer toutes ses mises jour ou ne rien faire du tout. En cas
dchec, le systme doit annuler toutes les modifications quelle a engages. Latomicit est menace par les pannes de programme, du systme ou du matriel, et plus
gnralement par tout vnement susceptible dinterrompre une transaction en cours.
2.2.2. Cohrence
La transaction doit faire passer la base de donnes dun tat cohrent un autre. En
cas dchec, ltat cohrent initial doit tre restaur. La cohrence de la base peut tre
viole par un programme erron ou un conflit daccs concurrent entre transactions.
2.2.3. Isolation
Les rsultats dune transaction ne doivent tre visibles aux autres transactions quune
fois la transaction valide, afin dviter les interfrences avec les autres transactions.
Les accs concurrents peuvent mettre en question lisolation.
2.2.4. Durabilit
Ds quune transaction valide ses modifications, le systme doit garantir quelles
seront conserves en cas de panne. Le problme essentiel survient en cas de panne,
notamment lors des pannes disques.
Ces proprits doivent tre garanties dans le cadre dun systme SGBD centralis,
mais aussi dans les systmes rpartis. Elles ncessitent deux types de contrle, qui
sont intgrs dans un SGBD : contrle de concurrence, rsistance aux pannes avec
validation et reprise. Nous allons les tudier successivement, puis nous tudierons la
mthode intgre ARIES qui est une des plus efficaces parmi celles implmentes
dans les SGBD.
3. THORIE DE LA CONCURRENCE
Cette section aborde les problmes de gestion des accs concurrents. Les solutions
proposes permettent de garantir la cohrence et lisolation des mises jour des transactions (le C et le I de ACID). Elles sont bases sur la thorie de la srialisabilit des
transactions, que nous examinons maintenant.
3.1. OBJECTIFS
Lobjectif gnral est de rendre invisible aux clients le partage simultan des donnes.
Cette transparence ncessite des contrles des accs concurrents au sein du SGBD.
Ceux-ci seffectuent au moyen de protocoles spciaux permettant de synchroniser les
mises jour afin dviter les pertes de mises jour et lapparitions dincohrences.
Une perte de mise jour survient lorsquune transaction T1 excute une mise jour
calcule partir dune valeur prime de donne, cest--dire dune valeur modifie
par une autre transaction T2 depuis la lecture par la transaction T1. La mise jour de
T2 est donc crase par celle de T1. Une perte de mise jour est illustre
figure XVI.3. La mise jour de la transaction T2 est perdue.
T1 : Read A->a;
T2 : Read A->b;
T2 : b+1 -> b;
T2 : Write b->A;
T1: a*2 ->a;
T1: Write a -> A;
temps
Une incohrence apparat lorsque des donnes lies par une contrainte dintgrit
sont mises jour par deux transactions dans des ordres diffrents, de sorte
enfreindre la contrainte. Par exemple, soient deux donnes A et B devant rester
gales. Lexcution de la squence doprations {T1 : A = A+1 ; T2 : B = B*2 ; T2 :
A = A*2; T1: B=B+1} rend en gnral A diffrent de B, du fait de la non-commutativit de laddition et de la multiplication. Elle provoque donc lapparition dune incohrence. Cette situation est illustre figure XVI.4.
A=B
T1 : A*2->A;
T2 : A+1->A;
T2 : B+1 -> B;
T1 : B*2 -> B;
temps
Un autre problme li aux accs concurrents est la non-reproductibilit des lectures : deux lectures dune mme donne dans une mme transaction peuvent
conduire des valeurs diffrentes si la donne est modifie par une autre transaction
entre les deux lectures (voir figure XVI.5). Le problme ne survient pas si les mises
jour sont isoles, cest--dire non visibles par une autre transaction avant la fin de la
transaction. Il en va de mme de lapparition dincohrences. Pour les pertes de mise
jour, lisolation des mises jour nest pas suffisante : il faut aussi ne pas laisser deux
transactions modifier simultanment une mme donne.
T1 : Read A->a;
T2 : Read A->b;
T2 : b+1 -> b;
T2 : Write b->A;
T1: Read A -> a
temps
Un granule au sens de la concurrence peut tre une ligne, une page ou une table dans
un systme relationnel. Ce peut tre un objet ou une page dans un SGBD objet. Nous
discuterons de la taille du granule de concurrence plus loin.
Les granules de concurrence sont lus et crits par les utilisateurs, ventuellement par
parties. On appelle action un accs lmentaire un granule.
Notion XVI.3 : Action (Action)
Unit indivisible excute par le SGBD sur un granule pour un utilisateur, constitue gnralement
par une lecture ou une criture.
Un systme de bases de donnes excute donc une suite dactions rsultant de transactions concurrentes. Aprs compltude dun ensemble de transactions (T1, T2Tn),
une histoire du systme peut tre reprsente par la suite des actions excutes. Plus
gnralement, toute suite dactions pouvant reprsenter une histoire possible sera
appele simplement excution.
Notion XVI.4 : Excution de transactions (Schedule, ou Log, ou History)
Squence dactions obtenues en intercalant les diverses actions des transactions T1, T2 Tn tout en
respectant lordre interne des actions de chaque transaction.
Une excution respecte donc lordre des actions de chaque transaction participante et
est, par dfinition, squentielle. Par exemple, considrons les transactions T1 et T2
figure XVI.6, modifiant les donnes A et B relies par la contrainte dintgrit A = B ;
A et B appartiennent deux granules distincts, maximisant ainsi les possibilits de
concurrence. Une excution correcte de ces deux transactions est reprsente
figure XVI.7 (a). Une autre excution est reprsente figure XVI.7 (b), mais celle-l
est inacceptable car elle conduit une perte doprations.
T1
Read A a1
a1+1 a1
Write a1 A
Read B b1
b1+1 b1
Write b1 B
T2
Read A a2
a2*2 a2
Write a2 A
Read B b2
b2*2 b2
Write b2 B
T1 :
T1 :
T1 :
T2 :
T2 :
T2 :
T1 :
T1 :
T1 :
T2 :
T2 :
T2 :
(a)
Read A a1
a1+1 a1
Write a1 A
Read A a2
a2*2 a2
Write a2 A
Read B b1
b1+1 b1
Write b1 B
Read B b2
b2*2 b2
Write b2 B
T2 :
T2 :
T1 :
T1 :
T2 :
T2 :
T2 :
T1 :
T1 :
T1 :
T1 :
T2 :
(b)
Read A a2
a2*2 a2
Read A a1
a1+1 a1
Write a2 A
Read B b2
b2*2 b2
Write a1 A
Read B b1
b1+1 b1
Write b1 B
Write b2 B
Par exemple, si le granule est la page, les oprations de base sont souvent LIRE
(page) et ECRIRE (page), qui sont galement dans bien des systmes des actions indivisibles. Si le granule est larticle, des oprations plus globales ncessitant plusieurs
actions indivisibles sont LIRE (article) et ECRIRE (article), mais aussi MODIFIER
(article) et INSERER (article). Avec ces oprations de base, il est possible den
construire dautres plus globales encore. Sur un objet typ, tel un compte en banque,
on peut distinguer des oprations, crer, crditer, dbiter, dtruire, etc.
Lapplication doprations des granules conduit des rsultats. Le rsultat dune
opration est constitu par ltat du granule concern aprs lapplication de lopration considre et par les effets de bords quelle provoque. Par exemple, le rsultat
dune opration LIRE est reprsent par la valeur du tampon rcepteur aprs excution, alors que le rsultat dune transaction modifiant une base de donnes est ltat
des granules modifis aprs excution ainsi que la valeur des messages dits.
Les oprations sont enchevtres au niveau des actions lors de lexcution simultane
de transactions. Deux oprations qui ne modifient aucun granule et qui appartiennent
deux transactions diffrentes peuvent tre enchevtres de manire quelconque sans
modifier les rsultats de leur excution. Autrement dit, toute intercalation doprations
neffectuant que des lectures conduit des rsultats identiques une excution successive de ces oprations. Plus gnralement, il est possible de dfinir la notion
doprations compatibles.
Notion XVI.6 : Oprations compatibles (Compatible operations)
Oprations 0i et 0j dont toute excution simultane donne le mme rsultat quune excution
squentielle 0i suivie de 0j ou de 0j suivie de 0i ( noter que les rsultats 0i puis 0j, et 0j puis 0i
peuvent tre diffrents).
Considrons par exemple les oprations reprsentes figure XVI.8. Les oprations
O11 et O21 sont compatibles ; O11 et O12 ne le sont pas.
Il est important de remarquer que deux oprations travaillent sur deux granules diffrents sont toujours compatibles. En effet, dans ce cas aucune perte doprations ne
peut survenir si lon intercale les oprations. Or il est simple de voir que deux oprations sont incompatibles lorsque quil existe une possibilit dintercalation gnrant
une perte doprations.
O11
{ Read A a1
a1+1 a1
Write a1 A
O21
{ Read B b1
b1+1 b1
Write b1 B
O31
{ Read A a1
a1+10 a1
Write a1 A }
O12
{ Read A a2
a2*2 a2
}
Write a2 A
O22
{ Read B b2
b2*2 b2
}
Write b2 B }
Par exemple, les oprations O11 et O31 reprsentes figure XVI.8 sont permutables
alors que les oprations O11 et O12 ne le sont pas. Soulignons que deux oprations
travaillant sur des granules diffrents sont toujours permutables. En effet, dans ce cas,
lexcution de la premire ne peut modifier le rsultat de la seconde et rciproquement. Par exemple, O11 et O12 sont permutables. Plus gnralement, deux oprations
compatibles sont permutables, mais la rciproque nest pas vraie.
laisser sexcuter que des excutions sans pertes doprations ou inconsistances. Il est
bien connu que lexcution successive de transactions (sans simultanit entre transactions) est un cas particulier dexcution sans perte doprations ni inconsistances.
Une telle excution est appele succession et peut tre dfinie plus formellement
comme suit :
Notion XVI.8 : Succession (Serial Schedule)
Excution E dun ensemble de transactions {T1, T2Tn} telle quil existe une permutation de
(1,2n) telle que :
E = < T (1) ; T(2) ; T (n) >
Afin dassurer labsence de conflit, il est simple de ne tolrer que les excutions qui
donnent le mme rsultat quune succession pour chaque transaction. De telles excutions sont dites srialisables.
Notion XVI.9 : Excution srialisable (Serialisable Schedule)
Excution E dun ensemble de transactions {T1, T2Tn} donnant globalement et pour chaque transaction participante le mme rsultat quune succession de (T1, T2Tn).
titre dexemple, considrons lexcution reprsente figure XVI.7(a). En reprsentant seulement globalement les oprations, cette excution scrit :
T1 : A + 1 A
T2 : A * 2 A
T1 : B + 1 B
T2 : B * 2 B
Les oprations A *2 A et B + 1 B sont permutables car elles agissent sur des
granules diffrents. Par suite, cette excution peut tre transforme en :
T1 : A + 1 A
T1 : B + 1 B
T2 : A * 2 A
T2 : B * 2 B
qui est une succession de T1 puis T2. Par suite, lexcution figure XVI.7(a) est srialisable.
La notion de prcdence est gnrale et sapplique tout type dopration. En pratique, les systmes ne considrent dordinaire que les oprations de lecture et dcriture. Les prcdences sont alors cres par les squences dactions de base lecture et
criture. Les squences non commutatives lecture puis criture, criture puis lecture,
criture puis criture, dune mme donne introduisent des prcdences. Plus prcisment, lune des squences :
Ti : lire(D) Tj : crire(D) ;
Ti : crire(D) Tj : crire(D) ;
Ti : crire(D) Tj : lire(D) ;
implique que Ti prcde Tj.
Considrons une excution simultane de transactions. La relation de prcdence
entre transactions peut tre reprsente par un graphe :
Notion XV.11 : Graphe de prcdence (Precendency graph)
Graphe dont les nuds reprsentent les transactions et dans lequel il existe un arc de Ti vers Tj si Ti
prcde Tj dans lexcution analyse.
T1
A
B
T2
A
T3
4. CONTRLE DE CONCURRENCE
PESSIMISTE
Deux types de techniques ont t dveloppes pour garantir la srialisabilit des transactions : les techniques de prvention des conflits qui empchent leur apparition et
les techniques de dtection qui laissent les conflits se produire mais les dtectent et
annulent leurs effets. Les premires sont dites pessimistes car elles prviennent des
conflits qui ne surviennent en gnral pas. Elles sont bases sur le verrouillage. Les
secondes sont dites optimistes. Dans cette partie, nous tudions le verrouillage qui est
de loin la technique la plus applique.
Une transaction comporte donc deux phases (voir figure XVI.10) : une phase dacquisition de verrous et une phase de relchement. Cette condition garantit un ordre identique des transactions sur les objets accds en mode incompatible. Cet ordre est celui
dexcution des points de verrouillage maximal . En pratique, afin de garantir lisolation des mises jour, les verrous sont seulement relchs en fin de transaction, lors
de la validation.
Nombre
de verrous
temps
T1
T2
T1
attend
T2
attend
temps
Deux classes de solutions sont possibles dans les SGBD afin de rsoudre le problme
du verrou mortel : la premire, appele prvention, empche les situations de verrous
mortels de survenir ; la seconde, appele dtection, est une solution curative qui
consiste supprimer les verrous mortels par reprise de transactions.
simple. En effet, si le graphe des attentes possde un circuit, cest quil existe un
groupe de transactions tel que : T1 attend T2, T2 attend T3,Tk attend T1. Chaque
transaction du groupe est donc bloque en attente dun objet du fait de lutilisation de
cet objet par une autre transaction du groupe. La fin dexcution de toutes les transactions nappartenant pas au groupe ne permet donc pas de dbloquer une transaction du
groupe.
T1
T2
T4
T2
T3
T5
Il est intressant dtablir le rapport entre graphes des attentes et graphe de prcdence. Par dfinition, si une transaction Ti attend une transaction Tj, alors Tj a verrouill un objet O dont le verrouillage est demand par Ti dans un mode incompatible.
Ainsi, lopration pour laquelle Tj a verrouill O sera excute avant celle demande
par Tj car les deux oprations sont incompatibles et donc non permutables. Donc Tj
prcde Ti. Toutefois, la relation de prcdence nimplique gnralement pas la
relation dattente. Donc, en changeant lorientation des arcs du graphe des attentes, on
obtient un sous-graphe du graphe de prcdence. Cela implique que si le graphe des
attentes a un circuit, il en sera de mme pour le graphe de prcdence. En consquence, une situation de verrou mortel ne peut pas donner lieu une excution srialisable mme sil tait possible de terminer les transactions interbloques.
T2
G1
G2
celle dun circuit dans le graphe des attentes. Sous cette condition, la prsence dun
circuit dans le graphe des allocations entrane ainsi celle dun circuit dans le graphe de
prcdence.
Lalgorithme WOUND-WAIT est un peu plus subtil. Tout type dattente est permis.
Mais si une transaction plus ancienne attend une plus rcente, la rcente est blesse
(wounded), ce qui signifie quelle ne peut plus attendre : si elle rclame un verrou
tenu par une autre transaction, elle est automatiquement dfaite et reprise. Le contrle
des attentes impos par lalgorithme est reprsent figure XVI.18 ; une transaction
blesse ne peut donc attendre.
// Algorithm WOUND-WAIT
Procdure Attendre (Ti,Tj) {
// Ti rclame un verrou tenu par Tj
si ts(Ti) < ts(Tj) alors Tj is wounded sinon Ti waits ; }
Les deux algorithmes empchent les situations de verrous mortels en donnant priorit
aux transactions les plus anciennes. Lalgorithme WOUND-WAIT provoque en principe moins de reprises de transactions et sera en gnral prfr.
sinon. Le code de cette procdure est analogue celui de lalgorithme LOCK vu cidessus, ceci prs que seule les transactions de T sont prises en compte (les autres
sont supposes excutes et termines) et que ltat de verrouillage nest pas modifi.
La figure XVI.19 prsente une procdure DETECTER rpondant VRAI sil y a situation de verrou mortel et FAUX sinon. Cette procdure limine donc progressivement
les transactions pendantes du graphe des attentes.
Bool Procedure Detecter {
T = {Liste des transactions telles que N(k) 0 }
G = {liste des granules alloues aux transactions dans T}
Pour chaque entre g de G faire
Pour chaque demande non marque M de Tk en attente de g faire {
Si SLOCK(k, g, Q) = VRAI alors {
Marquer Q ;
N(k) = N(k) 1 ;
Si N(k) = 0 alors {
Eliminer Tk de T ;
Ajouter les granules verrouills par Tk G ;
} ;
} ;
} ;
Si T = alors DETECTER = FAUX
Sinon DETECTER = VRAI ;
} ;
Quand une situation dinterblocage est dtecte, le problme qui se pose est de choisir
une transaction recycler de faon briser les circuits du graphe des attentes. Lalgorithme de dtection prsent ci-dessus fournit la liste des transactions en situation
dinterblocage. Il faut donc choisir une transaction de cette liste. Cependant, tous les
choix ne sont pas judicieux, comme le montre la figure XVI.20. Une solution ce
problme peut tre de recycler la transaction qui bloque le plus grand nombre dautres
transactions, cest--dire qui correspond au sommet de demi-degr intrieur le plus
lev sur le graphe des attentes. Le choix de la transaction reprendre doit aussi chercher minimiser le cot de reprise.
T1
T2
T3
Le cot dune solution de type dtection avec reprise peut tre rduit. En effet, il est
possible de dclencher un algorithme dtection seulement quand une transaction
attend un verrouillage depuis un temps important (par exemple, quelques secondes),
plutt qu chaque dbut dattente.
Dautres algorithmes de dtection sont possibles. Le graphe dallocation est souvent
utilis dans les systmes rpartis. Lors dune attente qui dure, un algorithme envoie
une enqute le long des arcs du graphe des allocations. Cette enqute est transmise au
granule attendu, puis aux transactions bloquant ce granule, puis aux granules attendus
sil en existe, etc. Si lenqute revient la transaction initiale, cest quil y a un verrou
mortel. Cet algorithme est moins efficace en centralis.
valide puisque T2 accde un granule non verrouill qui nexiste mme pas lorsque
T1 excute sa 1re partie : le tuple Fantomas . Toutefois, le rsultat de T1 est une
liste de 4 noms alors que le nombre de passagers est 5. Fantomas est ici un fantme pour T1.
Passagers
Nom
NVol
NSige
Dubois
100
Durand
100
Dupont
100
10
Martin
100
15
Occupation
NVol
NbrePass
100
Ce problme, ainsi que la difficult de citer les granules verrouiller, peuvent tre
rsolus par la dfinition de granules logiques (dans lexemple, les passagers du
vol 100) au moyen de prdicats [Eswaran76]. Le verrouillage par prdicat permet galement de dfinir des granules de tailles variables, ajustes aux besoins des transactions. Malheureusement, il ncessite des algorithmes pour dterminer si deux prdicats sont disjoints et ce problme de logique na pas de solution suffisamment efficace
pour tre appliqu dynamiquement lors du verrouillage des objets. De plus, les prdicats sont dfinis sur des domaines dont les extensions ne sont pas consultables dans la
base pour des raisons videntes de performance. Donc, il est trs difficile de dterminer si deux prdicats sont disjoints ; par exemple, PROFESSION = Ingnieur et
SALAIRE < 7000 seront dtermins logiquement non disjoints, alors quils le sont
dans la plupart des bases de donnes. Le verrouillage par prdicat est donc en pratique
source dattentes inutiles et finalement inapplicable.
IL
IE
IL
IE
Une telle mthode peut tre applique dans les bases relationnelles, mais aussi objet.
Le graphe dinclusion pour une base de donnes objet peut tre base, extension de
classe, page ou groupe (cluster) et objet. Il est reprsent figure XVI.23.
base
classe
cluster
page
objet
Objets
d
c
b
T1
w = write
T2
w
T3 w
w
Commit
T4 w
Abort
a
Commit
Abort
Temps
transactions non encore termines. Il faut donc grer la porte des transactions, par
exemple sous forme de listes de transactions dpendantes. Leffet domino introduit cidessus survient : lors de la reprise dune transaction, toutes les transactions dpendantes doivent tre reprises.
[Ins,ok]
[Del,ok]
[In,true]
[In,False]
[Ins,ok]
[Del,ok]
[In,true]
[In,False]
Certains auteurs [Weihl88] ont aussi considr la commutativit en avant et la commutativit en arrire. Par exemple [In,true] et [Insert,ok] commutent en
avant mais pas en arrire : si lon excute ces deux oprations partir dun tat s sur
lequel elles sont dfinies, on obtient bien le mme rsultat quel que soit lordre. Mais
si lon a lexcution [Insert, ok] [In, true], on nest pas sur que
[In,true] soit dfinie sur ltat initial (lobjet insr peut tre celui qui a permis le
succs de lopration In). Donc, on ne peut pas commuter lorsquon dfait et refait
une excution. Tout cela complique les procdures de reprises et lexploitation de la
commutativit des oprations.
5. CONTRLES DE CONCURRENCE
OPTIMISTE
Le verrouillage est une solution pessimiste : il empche les conflits de se produire, ou
plutt les transforme en verrou mortel. Analysons maintenant une autre gamme de
solutions qualifies doptimistes qui laissent se produire les conflits et les rsout
ensuite.
Vrifier labsence de conflits pourrait seffectuer en testant la non-introduction de circuits dans le graphe de prcdence. Lalgorithme commun [Kung81] de certification
est plus simple. Il consiste mmoriser les ensembles dobjets lus (Read Set RS) et
crits (Write Set WS) par une transaction. La certification de la transaction Ti consiste
tester que RS(Ti) nintersecte pas avec WS(Tj) et que WS(Ti) nintersecte pas avec
WS(Tj) ou RS(Tj) pour toutes les transactions Tj lances aprs Ti. On vrifie donc
que les transactions nagissent pas en modes incompatibles avec les transactions
concurrentes avant de les valider. Lalgorithme est reprsent figure XVI.27.
En rsum, cette mthode optimiste est analogue au verrouillage, mais tous les verrous sont laisss passants et les conflits ne sont dtects que lors de la validation des
transactions. Lavantage est la simplicit du contrleur de concurrence qui se rsume
mmoriser les objets accds et un test simple dintersection densembles de rfrences lors de la validation. Linconvnient majeur est la tendance reprendre beaucoup de transactions en cas de conflits frquents. La mthode optimiste est donc seulement valable pour les cas o les conflits sont rares.
Il est en gnral trs difficile de refaire le pass. Cependant, il est parfois possible de
forcer lordonnancement des critures de Ti en insrant une nouvelle version cre par
Ti juste aprs celle destampille immdiatement infrieure, soit Oj. Malheureusement,
si une transaction Tk (k >i) a lu la version Oj, alors cette lecture doit aussi tre resquence. Ce nest possible que si la transaction Tk pouvait tre reprise. Afin dviter
la reprise de transactions termines, on prfrera reprendre lcrivain Tj avec une nouvelle estampille i suprieure k.
Lalgorithme de contrle de lopration WRITE correspondant est reprsent
figure XVI.29. Les notations sont identiques celles utilises ci-dessus, les indices
dsignant les numros de versions dobjets.
// Rordonnancement des critures dans le pass
Fonction Ecrire(Ti, O) { // la transaction Ti demande lcriture de O;
j = index de la dernire version de O ;
Tant que ts(Ti) < W(Oj) faire j = j-1 ; // chercher la version avant Ti
Si ts(Ti) < R(Oj) alors abort(Ti) // abort si lecture non dans lordre
sinon executer_ecrire(Ti,Oj) } ; // crire en bonne place
}
10
Version 1
Version 5
Version 7
(a) Lecture de T3
La version 1 est dlivre
(b) criture de T3 : cration d une version 3 non lue
Version 3
(c) criture de T6
Impossible : T7 et T10 devraient tre rexcutes
T6 est annule et reprise plus tard comme T12
Les transactions entrent en conflit sur un objet O unique dont les versions successives
sont reprsentes par des rectangles. La situation originale est reprsente en haut de
la figure. Trois versions de lobjet existent, successivement cres par les transactions
1, 5 et 7. La version 1 a t lue par la transaction 1, la version 5 par la transaction 7 et
la version 7 par la transaction 10. Nous supposons que T3 accomplit une criture sur
lobjet O aprs lavoir lu. La nouvelle version 3 cre est insre en bonne place.
Nous supposons ensuite que T6 procde une criture sur O. Lobjet ayant t lu par
T7, il faudrait refaire le pass. On prfrera annuler T6 et la relancer plus tard.
En rsum, beaucoup dalgorithmes bass sur des estampilles peuvent tre invents
pour contrler les accs concurrents. Il est mme possible de mixer estampilles et verrouillage, comme dj vu au niveau des algorithmes DIE-WAIT et WOUND-WAIT.
Cependant, les performances de ces algorithmes restent faibles car ils provoquent tous
des reprises qui deviennent de plus en plus frquentes lorsquil y a un plus grand
nombre de conflits, donc lorsque le systme est charg. Voil sans doute pourquoi la
plupart des SGBD utilisent le verrouillage deux phases.
unit d'uvre
Non-perte du contexte
savepoint
update
update
unit d'uvre
End_Trans
Les objectifs premiers de la rsistance aux pannes sont de fournir un protocole aux
applications permettant dassurer latomicit. Pour ce faire, une application doit pouvoir commencer lexcution dune transaction et la terminer avec succs ou par un
chec. Des actions atomiques sont ainsi fournies par le systme de gestion de transactions aux applications. En plus de la cration dune transaction, ces actions correspondent aux trois notions de validation (encore appele commitment, consolidation ou
confirmation), dannulation (encore appele abort ou abandon ou retour arrire) et de
reprise (encore appele restauration ou redo). Nous dfinissons ci-dessous ces trois
notions.
Notion XVI.17 : Validation de transaction (Transaction commitment)
Action atomique spciale (appele Commettre ou Commit), excute en fin de transaction, provoquant lintgration dfinitive de toutes les mises jour non encore commise de la transaction excutante dans la base de donnes.
La validation est donc la terminaison avec succs dune transaction. Dans le cas de
transactions composes de plusieurs units duvre, une validation est effectue la
fin de chaque unit duvre. Loppos de la validation est lannulation.
Notion XVI.18 : Annulation de transaction (Transaction abort)
Action atomique spciale (appele Annuler ou Dfaire ou Abort ou Undo), gnralement excute
aprs une dfaillance, provoquant lannulation de toutes les mises jour de la base effectues par
la transaction et non encore commises.
Notez que seules les transactions non valides peuvent tre annules. Dfaire une
transaction valide est une opration impossible sauf utiliser des versions antrieures de la base. Par contre, une transaction dfaite peut tre refaite (on dit aussi
rejoue) : cest lobjet de la reprise.
Notion XVI.19 : Reprise de transaction (Transaction redo)
Excution dune action spciale (appele Refaire ou Redo) qui refait les mises jour dune transaction prcdemment annule dans la base de donnes.
La reprise peut seffectuer partir de journaux des mises jour, comme nous le verrons ci-dessous. Elle peut aussi ncessiter une nouvelle excution de la transaction.
elle ne peut tre dtruite que par une panne catastrophique explicite ou par une rcriture.
Notion XVI.20 : Mmoire stable (Stable store)
Mmoire dcoupe en pages dans laquelle une criture de page est soit correctement excute, soit
non excute, garantissant la mmorisation de la page jusqu rcriture, donc sa non perte suite
des pannes simples.
Dans les SGBD, la mmoire stable est le disque ; il permet de mmoriser les donnes
persistantes. La ralisation dune mmoire sre garantissant latomicit des critures nest
pas triviale. Les techniques utilises sont en gnral les codes de redondances, ainsi que
les doubles critures. Dans la suite, nous considrons les mmoires stables comme sres.
Les transactions actives excutent des mises jour dont leffet apparat dans le cache
et nest pas instantanment report sur disque. En thorie, leffet dune transaction
devrait tre report de manire atomique lors de la validation. La figure XVI.32
illustre les mouvements entre mmoire volatile (le cache) et mmoire stable souhaitables lors de la validation ou de lannulation.
Cache volatile
Update
Update
Commit
Abort
Bases de donnes
Nant
Ceci est la vue logique donne lutilisateur. En pratique, les mcanismes pour assurer un tel fonctionnement logique sont plus complexes.
Le journal des images avant est utilis pour dfaire les mises jour dune transaction
(undo). Pour cela, il doit tre organis pour permettre daccder rapidement aux enregistrements correspondant une transaction. Un fichier hach sur lidentifiant de transaction (TrId) sera donc opportun.
Notion XVI.23 : Journal des images aprs (After image log)
Fichier systme contenant dune part les valeurs (images) aprs modifications des pages mises
jour, dans lordre des modifications avec les identifiants des transactions modifiantes, ainsi que des
enregistrements indiquant les dbuts, validation et annulation de transactions.
Le journal des images aprs est utilis pour refaire les mises jour dune transaction
(redo). Comme le journal des images aprs, il doit tre organis pour permettre
daccder rapidement aux enregistrements correspondant une transaction. Un fichier
hach sur lidentifiant de transaction (TrId) sera donc opportun.
En guise dillustration, la figure XVI.33 reprsente un enregistrement dun journal
contenant la fois les images avant et aprs. Les enregistrements sont prcds dune
lettre R (Redo) pour les images aprs, U (Undo) pour les images avant, et T
(Transaction) pour les changements dtats des transactions.
Undo
Redo
<Trid-T-{D, C, A}>
<Trid-U-TID-[Ai=valeur]*>
<Trid-R-TID-[Ai=valeur]*>
Comme indiqu ci-dessus, les modifications sont tout dabord excutes dans des
caches en mmoire. Ces caches sont volatils, cest--dire perdus lors dune panne. Ce
nest bien souvent que lors de la validation que les mises jour sont enregistres dans
le journal et dans la base. Afin dtre capable dannuler une transaction dans tous les
cas, il faut crire les enregistrements dans le journal avant de reporter le cache dans la
base, comme illustr figure XVI.34.
Journal
2.Log
Page lue
4.Log
3.Update
1.Read
Page modifie
5.Write
Base persistante
Lordre dans lequel les oprations doivent tre accomplies est indiqu sur la figure.
Les rgles suivantes sont souvent conseilles [Bernstein87] :
1. Avant dcrire une page modifie en mmoire stable, il faut enregistrer son image
avant dans le journal (pour pouvoir dfaire) ainsi que son image aprs (pour pou-
voir refaire). Cette rgle est connue sous le nom de journalisation avant criture
(log ahead rule).
2. Toutes les pages modifies en mmoire volatile par une transaction doivent tre
crites en mmoire stable, donc sur disque, avant la validation de la transaction.
Cette dernire rgle est connue sous le nom de validation aprs criture (commit
after rule).
Lapplication de ces deux rgles conduit naturellement enregistrer journal puis page
modifie sur disques soit chaque mise jour, soit en fin de transaction avant le commit effectif. Elles sont donc trs limitatives. En consquence, la premire est gnralement suivie pour viter de ne pouvoir dfaire des transactions non valides ou refaire
des valides. La seconde peut tre relaxe avec quelques prcautions. Dans certains
cas, par exemple si les journaux sont doubls ou si la base est double par une base
miroir, ces deux rgles peuvent tre remplaces par des rgles plus souples.
Lutilisation dun journal cote trs cher : chaque mise jour ncessite a priori trois
entres-sorties. Afin damliorer les performances, les enregistrements du journal sont
gnralement gards dans un tampon en mmoire et vids sur disques lorsque le tampon est plein. Malheureusement, il faut crire le journal avant dcrire dans la base
pour pouvoir dfaire ou refaire les mises jour de la mmoire stable. La technique
utilise pour rsoudre ce problme consiste bloquer ensemble plusieurs validations
de transactions.
Notion XVI.24 : Validation bloque (Blocked commit)
Technique consistant valider plusieurs transactions ensemble pour pouvoir crire ensemble les
enregistrements dans le journal.
Ainsi, le systme peut attendre quun tampon du journal soit plein avant de le vider.
Lorsquune transaction commet, si le tampon nest pas plein, elle attend que dautres
transactions effectuent des mises jour pour remplir le tampon. Si le systme est peu
actif, un dlai maximal (time out) permet de forcer le vidage du tampon journal.
Soulignons que le journal est en gnral compress, pour rduire sa taille au maximum et aussi maximiser le nombre de transactions commises simultanment.
Un dernier problme concernant le journal est celui de sa purge. En effet, on ne peut
enregistrer indfiniment les enregistrements tudis sur un disque dans un fichier
hach. Mme avec du hachage extensible, le fichier risque de devenir important et difficile grer. En consquence, les systmes changent priodiquement de fichier journal. Il est possible par exemple de tourner sur N fichiers hachs, en passant au suivant
chaque fois que lun est plein ou au bout dune priode donne. Un fichier journal qui
nest plus actif est vid dans une archive. Il sera rutilis plus tard pour une nouvelle
priode de journalisation.
Une sauvegarde peut par exemple tre effectue en dbut de chaque semaine, de
chaque journe, de chaque heure. La prise de sauvegarde pendant le fonctionnement
normal du systme est un problme difficile. Pour cela, un mcanisme de verrouillage
spcifique ou mieux, un mcanisme de multi-versions [Reed79] peut tre utilis.
7. VALIDATION DE TRANSACTION
Comme indiqu ci-dessus, la validation de transaction doit permettre dintgrer toutes
les mises jour dune transaction dans une base de donnes de manire atomique,
cest--dire que toutes les mises jour doivent tre intgres ou quaucune ne doit
ltre. Latomicit de la validation de transaction rend les procdures dannulation de
transactions non valides simples. Le problme est donc de raliser cette atomicit.
Plusieurs techniques ont t introduites dans les systmes afin de raliser une validation atomique. Elles peuvent tre combines afin damliorer la fiabilit [Gray81]. La
plupart des SGBD combinent dailleurs les critures en place et la validation en deux
tapes.
Validation
Nouvel
tat
Enregistrements
dans le journal
Nouvel
tat
Annulation
Ancien
tat
Enregistrements
dans le journal
Lannulation dune transaction ayant mis en place des mises jour dans la base est
une procdure difficile. Elle seffectue partir du journal des images avant. Lannulation ncessite le parcours du journal lenvers, cest--dire en reculant dans le temps.
Nom
Fichier
Adresse
Table des Pages
Validation
Page ombre
Page ombre
Le protocole ncessite la journalisation des mises jour prpares et des tats des
transactions dans un journal local chaque participant, ceci afin dtre capable de
retrouver ltat dune transaction aprs une ventuelle panne et de continuer la validation ventuelle. Le protocole est illustr figure XVI.37 dans le cas favorable o un site
client demande la validation deux sites serveurs avec succs. Notez quaprs excution de la demande de validation (VALIDER), les participants envoient un acquittement (FINI) au coordinateur afin de lui signaler que la transaction est maintenant termine.
Coordinateur
Participant 1
prparer
prparer
prt
prt
valider
valider
fini
fini
Participant 2
Le cas de la figure XVI.38 est plus difficile : le participant 2 est en panne et ne peut
donc rpondre au message de demande de prparation. Une absence de rponse est
assimile un refus. Le coordinateur annule donc la transaction et envoie le message
ANNULER. Le participant 1 annule la transaction. Le participant 2 lannulera
lorsquil repartira aprs la panne, une transaction non prte tant toujours annule.
Coordinateur
Participant 1
prparer
prt
abandon
prparer
timeout
Participant 2
panne
abandon
fini
fini
reprise
Le cas de la figure XVI.39 est encore plus difficile : le participant 2 tombe en panne
aprs avoir rpondu positivement la demande de prparation. Le coordinateur
envoie donc le message COMMIT qui nest pas reu par le participant 2.
Heureusement, celui-ci a d sauvegarder ltat de la sous-transaction et ses mises
jour dans un journal fiable sur disque. Lors de la procdure de reprise, le journal sera
examin. La transaction tant dtecte prte commettre, son tat sera demand au
coordinateur (ou a un participant quelconque) par un message appel STATUS. En
rponse ce message, la validation sera confirme et les mises jour seront appliques partir du journal. Les deux sous-transactions seront donc finalement valides.
Coordinateur
Participant 1
prparer
prparer
prt
prt
valider
valider
fini
prt
Participant 2
panne
reprise
valider
prt
Au-del du protocole en deux tapes, il existe des protocoles en trois tapes qui vitent les blocages du protocole prcdent en cas de panne du coordinateur. Le plus courant est le protocole dit dabort suppos, qui en cas de panne du coordinateur suppose
labandon de la transaction. Ceci est mme possible en deux phases [Mohan86].
Le protocole en deux tapes a t standardis par lISO. TP est le protocole standard
propos par lISO dans le cadre de larchitecture OSI afin dassurer une validation
cohrente des transactions dans un systme distribu. Le protocole est arborescent en
ce sens que tout participant peut dclencher une sous-transaction distribue. Un site
responsable de la validation de la sous-transaction est choisi. Un coordinateur est responsable de ses participants pour la phase 1 et collecte les PREPARE. Il demande
ensuite la validation ou labort selon la dcision globale un site appel point de validation qui est responsable de la phase 2 : cest le point de validation qui envoie les
COMMIT aux participants. Lintrt du protocole, outre laspect hirarchique, est que
le point de validation peut tre diffrent du coordinateur : ce peut tre un nud critique dans le rseau dont la prsence la validation est ncessaire. La figure XVI.40
illustre ce type de protocole hirarchique avec point de validation.
Coordinateur global
Coordinateur
local
Coordinateur
local
Point de validation
(Nud critique)
La reprise normale ne pose pas de problme. Elle a lieu aprs un arrt normal de la
machine. Lors de cet arrt, un point de reprise systme est crit comme dernier enre-
Validation transaction i
M2 (i+1)
Dbut transaction i+3
M1 (i+3)
M2 (i+3)
M2 (i+2)
Validation transaction i+2
M3 (i+1)
Base au moment de
la panne
PANNE
Les transactions i et (i+2) sont gagnantes alors que (i+1) et (i+3) sont perdantes.
Mj(i) dsigne la je mise jour de la transaction i. Les mises jour dfaites sont marques par une flche.
Cette procdure est excute lors des redmarrages du systme quand le dernier enregistrement du journal nest pas un point de reprise et que loprateur ne signale pas
une perte de mmoire secondaire.
No Undo, Redo
(1)
Undo, Redo
(2)
No Undo, No Redo
(3)
Undo, No Redo
(4)
9. LA MTHODE ARIES
ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) [Mohan92] est
une des mthodes de reprise de transactions des plus efficaces. Elle est la base des
algorithmes de reprises implments dans de nombreux systmes, dont ceux des
SGBD dIBM. Ralise dans le cadre du projet de SGBD extensible dIBM Starburst,
cette mthode sest impose comme une des meilleures mthodes intgres.
9.1. OBJECTIFS
Les objectifs essentiels initiaux de la mthode taient les suivants [Mohan92] :
Simplicit. Vu la complexit du sujet, il est essentiel de viser la simplicit de
sorte tre applicable en vraie grandeur et garantir des algorithmes robustes.
Cest dailleurs vrai pour tous les algorithmes, au moins en systme.
Journalisation de valeur et dopration. Classiquement, ARIES permet de dfaire
et refaire une mise jour avec les images avant et aprs. Au-del, la mthode
intgre la possibilit de journaliser des oprations logiques, comme incrment et
dcrment dun compte. Cela permet le verrouillage smantique avec des modes
doprations sophistiqus, pour supporter des excutions oprations commutatives
non srialisables au niveau des lectures et critures. Ceci est important pour permettre une meilleure concurrence, comme vu ci-dessus. Une des difficults dans ce
type de journalisation par opration est de bien associer un enregistrement du journal avec ltat de la page qui lui correspond : ceci est accompli astucieusement avec
un numro de squence denregistrement journal (Log Sequence Number, LSN)
mmoris dans la page. Une autre difficult est due aux pannes pendant la reprise :
il faut pouvoir savoir si lon a refait ou non une opration. Ceci est accompli en
journalisant aussi les mises jour effectues pendant la reprise par des enregistrements de compensation (Compensation Log Records, CRLs).
Gestion de mmoire stable et du cache flexible. La mmoire stable est gre efficacement. Diffrentes stratgies de report du cache sont utilisables. Reprise et verrouillage sont logiques par nature ; cela signifie que la reprise reconstruit une base
cohrente qui nest pas forcment physiquement identique la base perdue (pages
diffrentes), mais aussi que les verrouillages sont effectus des niveaux de granularits variables, en utilisant le verrouillage dintention vu ci-dessus.
Reprise partielle de transactions. Un des objectifs de la mthode est de pouvoir
dfaire une transaction jusquau dernier point de sauvegarde. Cest important pour
pouvoir grer efficacement les violations de contraintes dintgrit et lutilisation de
donnes primes dans le cache.
Reprise granulaire oriente page. La mthode permet de reprendre seulement une
partie de la base, la reprise dun objet (une table par exemple) ne devant pas impliquer la reprise dautres objets. La reprise est oriente page en ce sens que la granularit de reprise la plus fine est la page : si une seule page est endommage, il doit
tre possible de la reconstruire seule.
Reprise efficace et rapide. Il sagit bien sr davoir de bonnes performances, la
fois pendant lexcution normale de transactions et pendant la reprise. Lide est de
rduire le nombre de pages rcrire sur disques et le temps unit central ncessaire
la reprise.
Outre ces quelques objectifs, ARIES en a atteint de nombreux autres tels que lespace
disque minimal ncessaire en dehors du journal, le support dobjets multi-pages, la
TYPE
PrevLSN
TransID
PageID
UndoNxtLSN Undo next LSN : LSN de lenregistrement suivant traiter pendant la reprise
arrire.
Prsent seulement pour les enregistrements de compensation.
Data
Data : Donnes dcrivant la mise jour qui a t effectue, soit limage avant
et limage aprs, soit lopration et son inverse si elle ne sen dduit pas.
Prsent seulement pour les enregistrements de mise jour ou de compensation
qui nont que les informations pour refaire.
Pour chaque page de donnes, ARIES ncessite un seul champ par page nomm
page_LSN qui mmorise le numro LSN du dernier enregistrement du journal qui
concerne cette page.
En plus, ARIES gre une table des transactions utilise pendant la reprise pour
mmoriser ltat de validation des transactions actives (Prte ou Non dans le protocole
deux phases), et enfin une table des pages sales, cest--dire modifie en cache et
ne correspondant plus la version sur mmoire stable.
Une deuxime passe de reconstruction est ensuite effectue, durant laquelle ARIES
rpte lhistoire mmorise dans le journal et non enregistre sur mmoire stable.
Ceci est fait pour toutes les transactions, y compris celles qui navaient pas t valides au moment de la panne. Lobjectif est de rtablir ltat de la base au moment de
la panne. Un enregistrement du journal est appliqu en avant (refait) sur une page si
son LSN est suprieur celui de la page, ce qui rduit le nombre de rfactions ncessaires. Durant cette phase, les verrous pour les transactions prtes valider au
moment de la panne sont restaurs, afin de pouvoir les relancer.
Une troisime passe de rparation consiste dfaire les transactions perdantes,
cest--dire celles non valides ou non prtes valider au moment de la panne. Ceci
seffectue par parcours du journal en arrire depuis le plus grand LSN restant traiter
pour les transactions perdantes. Si lenregistrement du journal est un enregistrement
normal, les donnes dannulation (image avant ou opration inverse) sont appliques.
Lenregistrement suivant traiter pour la transaction est alors dtermin en regardant
le champ PrevLSN. Sil sagit dun enregistrement de compensation, il est simplement utilis pour dterminer lenregistrement suivant traiter mmoris dans
UndoNxtLSN, puisque les enregistrements de compensation ne sont jamais compenss.
En rsum, la mthode comporte donc trois passes : analyse, reconstruction en avant
et rparation en arrire. Grce aux chanages intelligents des enregistrements du journal et la mmorisation du numro de squence du dernier enregistrement pertinent
au niveau de chaque page, la mthode vite de refaire et dfaire des mises jour inutilement. Elle intgre aussi la possibilit dannulation logique ou physique doprations,
ce qui permet des verrouillages en modes varis exploitant la commutativit. La
mthode a t implmente dans de nombreux systmes industriels.
On obtient ainsi un arbre de transactions (voir figure XVI.44). Une transaction fille
est lance par sa mre par excution dune commande BEGIN ; elle rend un compterendu sa mre qui se termine aprs toutes ses filles. De manire classique, chaque
(sous-)transaction se termine par COMMIT ou ABORT et est une unit atomique totalement excute ou pas du tout. Chaque (sous-)transaction peut tre refaite (REDO)
ou dfaite (UNDO) par un journal hirarchis.
Begin(T)
Begin(t'1)
Begin(t1)
Commit(t'1)
Commit(t1)
Begin(t2)
Begin(t21)
Commit(t21)
Abort(t2)
Commit(T)
La validation dune transaction fille est conditionne par celle de ses anctres, et ce
rcursivement.
En consquence, bien que chaque transaction se termine par COMMIT ou ABORT, la
validation nest confirme que lorsque tous les anctres ont valid. Le modle ferm
[Moss85] garantit latomicit de la transaction globale. Donc un chec dune soustransaction implique une annulation de la mre. Ceci est trs limitatif, mais conserve
les proprits ACID entre transactions globales. Au contraire, le modle ouvert
relche latomicit de la transaction globale.
Du point de vue de la concurrence, chaque (sous-)transaction applique le verrouillage
deux phases. Les verrous sont hrits dans les deux sens : lorsquune transaction fille
rclame un verrou tenu par un de ses anctres, elle nest pas bloque ; lorsquune transaction fille valide, les verrous quelle a acquis sont transmis sa mre. Deux (sous)transactions peuvent donc se bloquer voir sinterbloquer si le verrou nest pas tenu
par un anctre commun. Ceci complique les dtections de verrous mortels.
Le modle ouvert relche donc la ncessit datomicit des transactions globales.
Alors, une (sous-)transaction peut tre annule alors que sa mre est valide. Le travail
est donc seulement partiellement ralis. Ceci ncessite lintroduction de transactions
de compensation [Korth90]. Par exemple, la compensation dune transaction achetant
de la marchandise consiste rendre cette marchandise. Une (sous-)transaction de compensation dfait donc une (sous-)transaction prcdemment excute. Une variante est
une transaction de complment. Ces transactions de complment viendront plus tard
refaire les portions de travail non valides. Par exemple, le complment dune transaction de mise jour dun ouvrage qui a chou sur le chapitre II est une transaction qui
met jour le chapitre II. Finalement, ds que lon relche latomicit, il est ncessaire
dintroduire de telles transactions dpendant de la smantique de lapplication.
Ces principes ont conduit dfinir un modle de transactions imbriques ouvert trs
flexible [Weikum92]. Outre latomicit, ce modle relche en plus le principe disolation en laissant les rsultats des sous-transactions commises visibles aux transactions
concurrentes. La reprise ncessite alors de grer des sphres dinfluence de transactions, gnralisation de la notion de trane dj vue. La smantique des oprations est
aussi intgre pour grer les commutativits doprations types. De tels modles
commencent tre implments dans les SGBD classiques. Leurs limites et intrts
restent encore mal connus.
T2
T3
T1
T2
CT2
...
Tn
CT1
Lintrt des sagas est de pouvoir relcher le principe disolation. En effet, chaque
transaction composante relche ses verrous ds quelle est termine. Une autre saga
peut alors voir les rsultats. Lannulation de la saga doit donc provoquer lannulation
de lautre saga. Pour cela, il suffit denchaner les transactions de compensation.
met de contrler les transactions par des ordres du type If abort, If commit, Run alternative, Run compensation, etc. Le moniteur contrle les transactions et excute les
programmes de ce langage. On obtient ainsi des systmes de gestion de la coopration
trs flexibles, proches des workflows [Rusinkiewicz95].
BD PARTAG
Objet
versionnable
CheckOut
V1
Version
personnelle
CheckIn
V2
V3
CheckOut
Version
personnelle
CheckIn
V4
Lecture
Ecriture
Drivation
Partage
Drivation
Exclusive
Lecture
criture
Drivation
Partage
Drivation
Exclusive
Lors de la rinsertion dune version dans la base (Check-in), le graphe de versions est
mis jour et la nouvelle version ajoute comme une fille de celle dont elle drive. Les
versions sont gnralement maintenues en diffrentiel, cest--dire que pour un nud
donn de larbre, seuls les attributs ou pages modifis par rapport au nud pre sont
maintenus. Le problme qui se pose est de faire converger les versions. Si deux versions drivant dun anctre commun nont pas de donnes communes modifies, une
fusion automatique peut tre ralise par intgration de toutes les mises jour effectues lanctre. Sinon, il y a ncessit de dfinir des procdures de rconciliation de
versions, voire dune intervention manuelle effectuant des choix.
Au-del de ces modles fort nombreux, des formalismes de comprhension et description ont t proposs. ACTA [Chrysanthis90] est un cadre pour spcifier et raisonner
sur la structure des transactions et leur comportement. Il permet dexprimer la sman-
tique des interactions entre transactions en termes deffets sur la validation ou lannulation des autres transactions, et sur ltat des objets et des synchronisations ncessaires. Il permet ainsi de dcrire et de raisonner sur un modle dactivit ou de transaction.
Un premier moyen de violer la scurit des donnes est pour un sujet de se faire passer pour un autre. Afin dviter cela, un procd dauthentification des sujets est
introduit.
Notion XVI.33 : Authentification (Authentification)
Procd permettant de vrifier quun sujet est bien qui il prtend tre.
tifs. Il est donc souhaitable de choisir des mots de passe longs (plus de 7 caractres),
comportant un mixage de caractres numriques, alphanumriques et de contrle.
Dautres procds plus sophistiqus et plus srs sont lutilisation de questionnaires,
lexcution dalgorithmes connus seulement par lobjet et le sujet, lutilisation de
badges, de cartes puces, dempreintes digitales ou dempreintes de la rtine. Ces
derniers procds ncessitent un priphrique spcialis.
La dfinition des sujets ne pose a priori pas de problme : tout utilisateur est un sujet.
Cependant, il est utile de considrer des groupes dutilisateurs.
Notion XVI.34 : Groupe dutilisateurs (User group)
Ensemble dutilisateurs ayant chacun nom et mot de passe, dsign globalement par un nom, pouvant intervenir comme sujet dans le mcanisme dautorisation.
La notion de groupe peut tre tendue de manire hirarchique, avec des sousgroupes. Dans ce cas, un groupe hrite de toutes les autorisations de ses antcdents
hirarchiques. Il est aussi possible de superposer plusieurs hirarchies [Fernandez80].
Egalement, un sujet peut tre un ensemble de transactions catalogues ; laccs ces
transactions doit alors tre aussi protg.
Un utilisateur peut joindre ou quitter un groupe. La dynamique des groupes lors des
dparts de personnes dans une entreprise peut tre un problme : il faut par exemple
enlever un utilisateur et le remplacer par un autre. Attribuer ou enlever de multiples
droits des groupes devient rapidement difficile lors des changements de fonctions.
Pour viter ces problmes, les SGBD ont introduit la notion de rle.
Notion XVI.35 : Rle (Role)
Ensemble de droits sur les objets caractris par un nom, pouvant intervenir comme sujet dans le
mcanisme dautorisation.
Ainsi, des droits sur les objets sont attribus aux rles. Ceux-ci peuvent tre ensuite
affects aux utilisateurs ou aux groupes dutilisateurs. Les SGBD modernes sont
capables de grer la fois des utilisateurs, des groupes et des rles qui sont donc les
sujets des mcanismes de contrle dautorisations.
ensembles de champs dun segment. Au contraire, les systmes relationnels permettent de protger des ensembles doccurrences de tuples dfinis par des prdicats, donc
dpendants du contenu. Les systmes objet permettent souvent de protger la fois
des types et des instances.
Dans les systmes relationnels, les vues jouent un rle essentiel dans la dfinition des
objets protger [Chamberlin75]. Tout dabord, lorsquune vue est un objet autoris
un usager, celui-ci ne peut accder quaux tuples de cette vue. Ensuite, il est possible
avec la notion de vue de dfinir des objets protgs granularit variable. Une vue
peut tre une table de la base : un droit daccs est alors attribu un usager sur une
relation entire. Une vue peut aussi tre un ou plusieurs tuples extraits dynamiquement dune ou de plusieurs tables : un droit daccs est alors attribu sur une relation
virtuelle rsultant de lvaluation dune question. La technique de modification de
questions [Stonebraker75] tudie au chapitre IX traitant des vues permet alors de
protger efficacement les tuples ou attributs de tuples composant la vue. Une autre
approche est dutiliser le mme langage pour dfinir les objets sur lesquels on autorise
des oprations que celui pour exprimer les questions. Cette approche est celle de QBE
o les questions et les autorisations sont exprimes de la mme manire. Cela revient
au mme que lutilisation de vues comme objets de protection, puisquune vue est
dfinie comme une question.
Dans les systmes objet, il est souvent souhaitable de protger les types et mme individuellement les oprations des types, mais aussi les instances. Les objets sont organiss en hirarchie dhritage : les instances dune classe peuvent tre perues comme le
dernier niveau de la hirarchie. Il doit tre possible dajouter des prdicats pour partitionner plus finement lextension dune classe en objets autoriss ou non.
Gnralement, un utilisateur dune sous-classe hrite des droits de la classe de base.
Dans le cas o des autorisations positives (droits daccs) et ngatives (interdictions
daccs) seraient attribues, dterminer les autorisations dune sous-classe devient difficile, notamment en cas dhritage multiple [Rabitti91]. Aujourdhui, les SGBD objet
restent pour la plupart encore assez faibles du point de vue de la scurit.
Les autorisations considres sont en gnral positives : ce sont des accords de droits.
Cependant, la dfense amricaine a aussi introduit dans ses standards des possibilits
dautorisations ngatives, qui sont des interdictions daccs. Cela pose des problmes
de conflits, les interdictions dominant en gnral les autorisations. Dans la suite, nous
ne considrons que les autorisations positives.
Lattribution dune autorisation peut dpendre :
du sujet, par exemple de ses privilges daccs ou du terminal quil utilise,
de lobjet, par exemple de son nom, son tat actuel, son contenu ou sa valeur,
de lopration effectue, par exemple lecture ou mise jour,
dautres facteurs, par exemple de lheure du jour ou de la date.
Il existe plusieurs manires de mmoriser les autorisations. Une premire est lutilisation de matrices dautorisations. Une matrice dautorisations est une matrice dont
les lignes correspondent aux sujets et les colonnes aux objets, dfinissant pour chaque
couple sujet-objet les oprations autorises.
Considrons par exemple deux relations dcrivant les objets NOM et RESULTAT
dtudiants et des sujets tudiants, secrtaires et professeurs. Les oprations que peuvent accomplir les sujets sur les objets nom et rsultat sont lecture et criture. Les
autorisations peuvent tre codes par deux bits, droit dcriture puis droit de lecture.
La figure XVI.48 reprsente la matrice correspondant cet exemple, 0 signifiant
accs interdit et 1 accs autoris.
NOM
RSULTAT
TUDIANT
01
01
SECRTAIRE
11
01
PROFESSEUR
11
11
Dans les SGBD, les dfinitions des sujets, objets et autorisations sont mmorises
dans la mta-base ou catalogue du systme. En pratique, la matrice dautorisation peut
tre stocke :
par ligne chaque sujet est alors associe la liste des objets auxquels il peut accder ainsi que les droits daccs quil possde ;
par colonne chaque objet associe la liste des sujets pouvant y accder avec les
droits daccs associs ;
par lment chaque couple sujet-objet sont associs les droits daccs du sujet
sur lobjet.
Cest cette dernire technique qui est retenue dans les SGBD relationnels. Les autorisations sont mmorises dans une table DROITS(<Sujet>, <Objet>, <Droit>,
<Donneur>), le donneur permettant de retrouver la provenance des droits.
Lattribution de droits aux sujets sur les objets est un autre problme important. Plus
prcisment, il est ncessaire de dfinir qui attribue les droits. Deux approches sont
possibles. Soit, comme dans SQL2, le crateur dun objet (une relation ou une vue par
exemple) devient son propritaire et reoit tous les droits. Afin de passer et retirer les
droits quil possde, il doit alors disposer de commandes du type [Griffiths76] :
GRANT < types oprations > ON < objet >
TO < sujet >
[WITH GRANT OPTION]
avec :
<type opration> ::=
<action>
::=
|
|
<sujet> ::=
PUBLIC
REVOKE < types oprations > FROM < objet > TO < sujet >.
Soulignons que PUBLIC dsigne lensemble des utilisateurs, alors quun identifiant
dautorisation peut dsigner un utilisateur, un groupe ou un rle. Loption WITH
GRANT OPTION permet de passer aussi le droit de donner le droit.
Soit un groupe de sujets particuliers (les administrateurs des bases de donnes) possdent tous les droits et les allouent aux autres par des primitives du mme type. La premire approche est dcentralise alors que la seconde est centralise. Des approches
intermdiaires sont possibles si lon distingue plusieurs groupes de sujets avec des
droits a priori [Chamberlin78].
RSULTAT
TUDIANT
11
01
SECRTAIRE
11
00
PROFESSEUR
11
11
Linconvnient de la solution niveau dautorisation est que lon perd la notion dopration. Cependant, cette solution est simple implanter et de plus elle permet de combiner les niveaux. En effet, si un sujet de niveau S1 accde travers une procdure ou
un quipement de niveau S2, on associera au sujet le niveau S = min (S1, S2). Par
exemple, sil existe un terminal en libre accs de niveau 1 et un terminal situ dans un
bureau priv de niveau 3, un enseignant ne conservera ses privilges que sil travaille
partir du terminal situ dans le bureau. De plus, la mthode peut tre tendue, avec
des classes de niveaux partiellement ordonnes, vers un modle plus complet de
contrle de flots dinformations. Elle peut aussi tre combine avec la mthode MAC.
parallles les plus puissantes. Le mcanisme est donc sr, mais le problme est la gestion des cls qui doivent tre changes. Lapplication dun tel algorithme aux bases
de donnes ncessite son implmentation dans le SGBD et au niveau de lutilisateur.
Il faut en effet pouvoir dcrypter au niveau du SGBD pour effectuer les recherches.
Rechercher sur des donnes cryptes est trs difficile puisque les chanes de donnes
codes dpassent en gnral un attribut. Le SGBD devra donc garder un catalogue des
cls de cryptage/dcryptage. Les utilisateurs doivent pouvoir accder au catalogue
pour retrouver leur cl secrte. Celui-ci devient un point faible du systme.
Les algorithmes cls publiques et prives proposent deux cls diffrentes, inverses
lune de lautre. Lune permet de coder, lautre de dcoder. Les cls doivent tre plus
longues quavec les algorithmes cls secrtes, car elles sont plus facilement cassables,
cest--dire qu partir dune cl publique de 40 bits, on peut dduire la cl prive en
lessayant sur un message comprhensible en quelques heures de calcul dune machine
puissante. Il faut donc des cls de 512 bits et plus pour obtenir une scurit totale, ce qui
peut poser des problmes de lgislation. Avec de telles cls, le SGBD peut garder ses cls
prives et publier ses cls publiques. Lutilisateur code les donnes avec une cl publique
et les insre dans la base. Le SGBD dcode avec la cl prive correspondante. Les rsultats peuvent tre envoys cods avec une cl publique de lutilisateur qui dcode alors
avec sa cl prive. Ce schma est trs sr si les cls sont assez longues. Il est illustr
figure XVI.50. Les algorithmes asymtriques tels que Diffie-Hellmann et RSA permettent ainsi des solutions trs sres, o SGBD et utilisateurs gardent leurs cls prives.
Codage
cl publique de S
Donnes
cryptes
Dcodage
cl prive de S
Recherche
Dcodage
cl prive de U
Utilisateur
Codage
cl publique de U
SGBD
13. BIBLIOGRAPHIE
[Baer81] Baer J.-L., Gardarin G., Girault C., Roucairol G., The Two-Step
Commitment Protocol : Modeling, Specification and Proof Methodology ,
5th Intl. Conf. on Software Engineering, IEE Ed., San Diego, 1981.
Cet article modlise le protocole de validation en deux tapes par des rseaux
de Petri. Il prouve partiellement la correction du protocole, cest--dire que
tous les sites prennent la mme dcision pour une transaction.
[Barghouti91] Barghouti N. S., Kaiser G. E., Concurrency Control in Advance
Database Applications ACM Computing Survey, vol. 23, n 3, p. 270-317,
Sept. 1991
Cet article fait le point sur les techniques de contrle de concurrence avances.
Il rappelle les techniques traditionnelles vues ci-dessus et rsume le verrouillage altruiste, la validation par clichs, les transactions multi-niveaux, le
verrouillage smantique, les sagas, etc.
[Bancilhon85] Bancilhon F., Korth H., Won Kim, A Model of CAD Transactions ,
11th Int. Conf. on Very Large data Bases, Stockholm, Sude, Aot 1985.
Cet article propose un modle de transactions longues pour les bases de donnes en CAO. Il fut lun des prcurseurs des modles de transactions imbriqus
dvelopps par la suite.
[Beeri88] Beeri C., Scheck H-J., Weikum G., Multi-Level Transaction Management,
Theoretical Art or Practical Need ? , Proc. Intl. Conf. on Extending Database
Technology (EDBT), p. 134-155, Venise, Mars 1988.
Cet article introduit la srialisabilit niveaux multiples prsente ci-dessus.
[Bernstein80] Bernstein P.A., Goodman N., Timestamp-based Algorithm for
Concurrency Control in Distributed Database Systems , 5th Intl. Conf. On Very
Large data Bases, Montreal, Oct. 1980.
Cet article introduit diffrents algorithmes destampillage de transactions dans
le contexte de systmes rpartis.
[Bernstein87] Bernstein P.A., Hadzilacos V., Goodman N., Concurrency Control and
Recovery in Database Systems, Addison-Weley, 1987.
Cet excellent livre de 370 pages fait le tour des problmes de gestion de transactions dans les SGBD centraliss et rpartis. Il prsente notamment la thorie de base, le verrouillage, la certification, le multi-version, les protocoles de
validation deux et trois phases, la gestion de donnes rpliques.
[Bernstein90] Bernstein P.A., Hsu M., Mann B., Implementing Recoverable
Requests Using Queues , ACM SIGMOD Int. Conf., ACM Ed., SIGMOD
Record V. 19, n 2, June 1990.
Cet article propose un protocole rsistant aux pannes pour grer les flots de
requtes de transactions entre clients et serveurs. Il discute une implmentation
en utilisant des files dattente persistantes rcuprables aprs panne.
[Besancenot97] Besancenot J., Cart M., Ferri J., Guerraoui R., Pucheral Ph.,
Traverson B., Les Systmes Transactionnels : Concepts, Normes et Produits,
Ed. Herms, Paris, 1997.
Ce remarquable livre sur les systmes transactionnels couvre tous les aspects
du sujet : concepts de base, algorithmes de reprise, transactions rparties,
duplication, modles de transactions tendus, normes et standards, transactions dans les SGBD relationnels et objet.
[Bjork72] Bjork L.A., Davies C.T., The Semantics of the Preservation and Recovery
of Integrity in a Data System , Technical Report TR-02.540, IBM, Dec. 1972.
Un des tout premiers articles introduisant un concept proche de celui de transaction.
[Cart90] Cart M., Ferri J., Integrating Concurrency Control into an ObjectOriented Database System , Proc. Intl. Conf. on Extending Database
Technology, EDBT, LCNS n 416, p. 367-377, Venise, Mars 1990.
Cet article prsente lintgration dalgorithmes de contrle de concurrence
avec prise en compte de la commutativit des oprations dans un SGBD objet.
[Chamberlin75] Chamberlin D.D., Gray J.N., Traiger I.L., Views, Authorizations
and Locking in a Relational Data Base System , Proc. of ACM National
Computer Conf., p. 425-430, 1975
Cet article discute de lutilisation des vues comme mcanisme dautorisation et
de verrouillage par prdicat dans un SGBD.
[Chamberlin78] Chamberlin D.D., Gray J.N., Griffiths P.P., Mresse M., Traiger I.L.,
Wade B.W., Data Base System Authorization , in Foundations of Secure
Computation [Demillo78], p. 39-56.
Cet article discute des mcanismes dautorisation dans un SGBD relationnel.
[Chrysanthis90] Chrystandis P.K., Ramamritham K., ACTA : A Framework for
Specifying and reasoning about Transaction Structure and Behavior , ACM
SIGMOD Intl. Conf. on Management of Data, SIGMOD Record vol. 19, n 2,
p. 194-203, Atlantic City, NJ, Juin 1990.
Cet article prsente ACTA, un formalisme permettant de spcifier structure et
comportement des transactions, en exprimant notamment la smantique des
interactions.
[Dayal91] Dayal U., Hsu M., Ladin R., A Transactional Model for Long-Running
Activities , Proc. of the 17th Intl. Conf. on Very Large Data Bases, Morgan
Kaufmann Ed., p. 113-122, Bacelonne, Sept. 1991.
Cet article dcrit un modle dactivits composes rcursivement de sous-activits et de transactions. Le modle dfinit la smantique des activits et dcrit
une implmentation en utilisant des files rsistantes aux pannes pour chaner
les activits.
[Denning80] Denning D.E., Schlrer J., A Fast Procedure for Finding a Tracker in a
Statistical Database , ACM Transactions on Database Systems, vol. 5, n 1,
p. 88-102, Mars 1980.
Cet article prsente une procdure rapide pour dcouvrir les caractristiques
dun individu partir de requtes sur des ensembles dindividus.
[Demillo78] DeMillo R.A., Dobkin D.P., Jones A.K., Lipton R.J., Foundations of
Secure Computation, Academic Press, 1978.
Ce livre prsente un ensemble darticles sur la scurit dans les BD statistiques
et les systmes opratoires.
[Eswaran76] Eswaran K.P., Gray J.N., Lorie R.A., Traiger L.L., The Notion of
Consistency and Predicates Locks in a Database System , Comm. of the ACM,
vol. 19, n 11, p. 624-633, Nov. 1976.
Un des articles de base sur la notion de transaction et le principe du verrouillage deux phases. La notion de srialisabilit et le verrouillage par prdicat sont aussi introduits par les auteurs qui ralisent alors la gestion de transactions dans le fameux systme R.
[Fernandez80] Fernandez E.B., Summers R.C., Wood C., Database Security and
Integrity, The Systems Programming Series, 1980.
Ce livre de 320 pages fait le tour des techniques dintegrit et de scurit au
sens large dans les bases de donnes.
[Garcia-Molina87] Garcia-Molina H., Salem K., Sagas Proc. ACM SIMOD Intl.
Conf. on Management of Data, p. 249-259, San Fransisco, 1987.
Cet article prsente le modle des sagas introduit ci-dessus.
[Gardarin76] Gardarin G., Spaccapietra S., Integrity of Databases : A General
Locking Algorithm with Deadlock Detection , IFIP Intl. Conf. on Modelling
in DBMS, Freudenstadt, January 1976.
Cet article prsente un algorithme de verrouillage multi-mode et un algorithme
de dtection du verrou mortel dans ce contexte.
[Gardarin77] Gardarin G., Lebeux P., Scheduling Algorithms for Avoiding
Inconsistency in Large Data Bases , 3rd Intl. Conf. on Very Large Data Bases,
IEEE Ed., Tokyo, 1977.
Cet article introduit pour la premire fois la commutativit des oprations comme
solution pour tolrer plus dexcution srialisable. Il prsente un algorithme de
verrouillage modes multiples prenant en compte les commutativits possibles.
Cet article introduit les transactions imbriques, inventes par Moss dans son
PhD. Les transactions imbriques, au dpart fermes, ont t ouvertes (nonatomicit globale) et son implmentes dans des systmes de plus en plus nombreux.
[Moss85] Moss J.E.B., Nested Transactions : An Approach to Reliable Distributed
Computing, The MIT Press, Cambridge, Mass., 1985.
Ce livre, version amliore du PhD de Moss, introduit et tudie en dtail la
thorie et la pratique des transactions imbriques.
[Murphy68] Murphy J.E., Ressource Allocation with Interlock Detection in a MultiTask system , Proc of AFIPS-FJCC Conf., vol. 33, n 2, p. 1169-1176, 1968.
Cet article introduisit les graphes dattente et lun des premiers algorithmes de
dtection de deadlock.
[zsu91] zsu M.T., Valduriez P., Principles of Distributed Database Systems,
Prentice Hall, Englewood Cliffs, New Jersey, 562 p., 1991.
Cet ouvrage est le livre de rfrence en anglais sur les bases de donnes rparties. Il couvre en particulier les aspects architecture, conception, contrle
smantique, optimisation de requtes, gestion de transactions, fiabilit et
concurrence, bases de donnes fdres. Chaque aspect est trait de manire
trs complte. Les algorithmes sont esquisss et une formalisation minimale est
souvent introduite.
[Ozsu94] Ozsu T., Transaction Models and Transaction Management in ObjectOriented Database Management Systems , in Advances in Object-Oriented
Database Systems, p. 147-184, A. Dogac et. Al. Ed., NATO ASI Series,
Springer Verlag, Computer and System Sciences, 1994.
Ce remarquable article est un autre tutorial sur la gestion de transactions. Il
couvre particulirement bien les modles de transactions tendus et linfluence
de la commutativit des oprations.
[Pu88] Pu C., Kaiser G.E., Hutchinson N., Split-Transactions for Open-Ended
Activities 14th Intl. Conf. on Very Large data Bases, p. 26-37, Morgan
Kaufman Ed., Los Angels, 1998.
Cet article prsente le modle dynamique split et join voqu ci-dessus pour les
transactions imbriques.
[Rabitti91] Rabitti F., Bertino E., Kim W., Woelk D., A Model of Authorization for
Next Generation Database Systems , ACM Trans. On Database Systems,
vol. 16, n 1, p. 88-131, Mars 1991.
Cet article dveloppe un modle formel de scurit de type DAC pour un SGBD
objet. Il sappuie sur lexprience conduite avec le SGBD ORION.
Chapitre XVII
CONCEPTION
DES BASES DE DONNES
1. INTRODUCTION
Une des tches essentielles des dveloppeurs de bases de donnes est la conception du
schma des bases. Lobjectif est de structurer le domaine dapplication de sorte le
reprsenter sous forme de types et de tables. La reprsentation doit tre juste pour viter les erreurs smantiques, notamment dans les rponses aux requtes. Elle doit aussi
tre complte pour permettre le dveloppement des programmes dapplication souhaits. Elle doit enfin tre volutive afin de supporter la prise en compte rapide de nouvelles demandes.
Le concepteur, ou plutt ladministrateur de base, effectue galement le choix du placement des tables sur disques et le choix des index, choix essentiels pour les performances.
En exagrant un peu, on peut dire quil ny a pas de mauvais SGBD, mais de mauvais
concepteurs responsables des erreurs smantiques ou des mauvaises performances. Les
choix de structures physiques sont dpendants des programmes qui manipulent la base,
particulirement des types et frquences des requtes dinterrogation et de mise jour.
Traditionnellement, la dmarche de conception seffectue par abstractions successives, en descendant depuis les problmes de lutilisateur vers le SGBD. Nous proposons de distinguer cinq tapes :
1. Perception du monde rel et capture des besoins. Cette tape consiste tudier
les problmes des utilisateurs et comprendre leurs besoins. Elle comporte des
entretiens, des analyses des flux dinformation et des processus mtier. Des
dmarches de type BPR (Business Process Reengineering) [Hammer93] de reconception des processus mtiers existants en les dirigeant vers le client peuvent tre
un support pour cette tape. La gnration de modles de problmes est aussi une
technique courante ce niveau [DeAntonellis83]. Comme il est difficile de comprendre le problme dans son ensemble, les concepteurs ralisent des tudes de cas
partiels. Le rsultat se compose donc dun ensemble de vues ou schmas externes
quil faut intgrer dans ltape suivante. Ces vues sont exprimes dans un modle
de type entit-association ou objet, selon la mthode choisie.
2. laboration du schma conceptuel. Cette tape est base sur lintgration des
schmas externes obtenus ltape prcdente. Chaque composant est un schma
entit-association ou objet. Il rsulte dun modle de problme reprsentant une
partie de lapplication. La difficult est dintgrer toutes les parties dans un schma
conceptuel global complet, non redondant et cohrent. Des allers et retours avec
ltape prcdente sont souvent ncessaires.
3. Conception du schma logique. Cette tape ralise la transformation du schma
conceptuel en structures de donnes supportes par le systme choisi. Avec un
SGBD relationnel, il sagit de passer des tables. Avec un SGBD objet-relationnel,
il est possible de gnrer des types et des tables, les types tant rutilisables. Avec
un SGBD objet, il sagit de gnrer des classes et des associations. Cette tape peut
tre compltement automatise, comme nous le verrons.
4. Affinement du schma logique. Une question qui se pose est de savoir si le
schma logique obtenu est un bon schma. titre de premire approximation,
un bon schma est un schma sans oublis ni redondances dinformations. Pour
caractriser plus prcisment les bons schmas, le modle relationnel sappuie
sur la thorie de la normalisation, qui peut tre avantageusement applique ce
niveau. En relationnel, lobjectif est de grouper ou dcomposer les tables de
manire reprsenter fidlement le monde rel modlis.
5. laboration du schma physique. Cette tape est ncessaire pour obtenir de
bonnes performances. Elle ncessite la prise en compte des transactions afin de
dterminer les patterns daccs frquents. partir de l, il faut choisir les bonnes
structures physiques : groupage ou partitionnement de tables, index, etc. Cest l
que se jouent pour une bonne part les performances des applications.
Dans ce chapitre, nous tudions essentiellement les tapes 2, 3 et 4 qui font largement
partie du domaine des bases de donnes. La partie 1 appartient plutt au gnie logiciel, voire lconomie ou la psychologie. Nous ne laborderons gure. Nous
dtaillons surtout la partie 3 o toute une thorie sest dveloppe la fin des
annes 70 et au dbut des annes 80 pour les bases relationnelles.
Dans la section qui suit, nous abordons le problme de la conception du schma
conceptuel. Cest loccasion de prsenter le langage de modlisation UML, plus prci-
2. LABORATION DU SCHMA
CONCEPTUEL
Dans cette section, nous traitons des techniques permettant de dfinir un schma
conceptuel. Nous procdons par modlisation entit-association ou objet en construisant des diagrammes bass sur UML, le langage de modlisation unifi standardis
par lOMG.
doute rsistant lusure du temps, comme tous les standards. La construction de base
drive du langage UML pour reprsenter des entits est symbolise figure XVII.1.
titre dexemple, nous avons reprsent des voitures avec les attributs numro de
vhicule (NV), marque, type, puissance et couleur.
Nom
Voitures
Attribut: Type
.
Attribut: Type
NV: Int
Marque: String
Type: String
Puissance: Int
Couleur: String
Entit2
Association
Rle1
Rle2
Donnes
Dans une association, chaque entit participante joue un rle. Celui-ci peut tre explicitement nomm, comme indiqu figure XVII.2. Mais ceci nest pas obligatoire. Les
associations sont caractrises par des cardinalits : la cardinalit [m,n] attache
une entit indique les nombres minimal et maximal dinstance dassociations pour une
instance de cette entit.
Notion XVII.1 : Cardinalits dassociation (Relationship cardinalities)
Cardinalits minimale et maximale associes chacun des rles de lassociation, indiquant le
nombre minimal et maximal dinstances dassociation auxquelles participe une instance de lentit
du rle.
Une cardinalit se lit donc dans le sens entit vers association. Il faut se demander
pour une instance dentit (ou de classe) combien dinstances dassociation lui sont
attaches ? Avec des associations binaires, cela revient indiquer le nombre dinstances de lautre entit pour une instance de celle laquelle est attache la cardinalit.
UML propose les notations indiques figure XVII.3 pour les cardinalits. Notez que 1
signifie la fois un minimum de 1 et un maximum de 1. La notation {ord} signifie
que lordre dapparition des entits dans lassociation est important.
1
*
0..1
1..*
1
plusieurs (0 N)
optionnel (0 ou 1)
obligatoire (1 ou plus)
0..*
{ord}
3..5
ordonn (0 N)
limit (de 3 5)
titre dexemple, soient une base modlisant des entits personne et voiture ,
et le type dassociation possde qui traduit le fait quune personne est propritaire
dune ou plusieurs voitures. Une personne est caractrise par un numro de Scurit
Sociale (NSS), un nom, un prnom et une date de naissance alors quune voiture est
caractrise par les attributs dj vus NV, MARQUE, TYPE, PUISSANCE et COULEUR. Chaque personne est identifie par une occurrence du numro de Scurit
Sociale (NSS), alors que chaque voiture est identifie par un numro de vhicule
(NV). chaque occurrence dassociation correspond par exemple une date dachat
(DATE) et un prix dachat (PRIX). La figure XVII.4 reprsente le schma externe
correspondant dcrit avec les notations UML rduites aux entits, associations et attributs. Les cardinalits indiquent quune personne peut possder de O N voitures alors
quune voiture est possde par une et une seule personne.
Personne
Voiture
nv
marque
type
puissance
couleur
Possde
*
nss
nom
prenom
datenais
date
prix
Nous prsentons figure XVII.5 lexemple classique des buveurs, des vins et de lassociation boire caractrise par une date et une quantit. Les cardinalits sont donc portes par les rles : le rle Estbu porte la cardinalit 1..*, ce qui signifie qu un buveur
est associ entre 1 et N abus ou vins si lon prfre. * est une notation raccourcie pour
0..*. Le rle Estbu porte cette cardinalit, ce qui signifie quun vin est bu par 0 N
buveurs. Tout cela, aux notations prs, est bien connu mais souvent confus, les cardinalits tant interprtes de diffrentes manires selon les auteurs. Nous avons choisi
ces notations pour assurer la compatibilit avec lapproche objet et UML que nous
allons maintenant dvelopper un peu plus.
Buveurs
Vins
*
Boire
Abus
1..*
Estbu
Abus
Date
Quantit
attributs
oprations
Voiture
NV: Int
Type: String
Marque: Constructeur
Vitesse: Int
Km : Int
Dmarrer()
Acclrer()
Rouler(km:Int)
Freiner()
La dcouverte des classes, comme celle des entits, ncessite disoler les types
dobjets du monde rel qui ont un cycle de vie propre. Dans une description en langage naturel, les classes comme les entits correspondent souvent des noms. partir
des objets, il faut abstraire pour dcouvrir les proprits, attributs et mthodes. Une
rflexion sur le cycle de vie de lobjet et sur ses collaborations avec les autres objets
permet de prciser les mthodes, et par l les attributs manipuls par ces mthodes.
UML fournit des outils pour reprsenter cycle de vie et collaboration : ce sont les diagrammes dtat et de collaboration, dont ltude dpasse le cadre de cet ouvrage.
La dcouverte des classes conduit dcouvrir les liens de gnralisation et de spcialisation entre classes. Dans une description en langage naturel, les objets sont alors
relis par le verbe tre (relation is a). UML permet la reprsentation de lhritage
comme indiqu figure XVII.7. Sil est possible de grouper les deux flches en une
seule, cela na pas de signification particulire. Si les deux sous-classes sont disjointes, une contrainte {Exclusive} peut tre explicitement note. De mme, il est possible de prciser {Inclusive} si tout objet se retrouve dans toutes les sous-classes. Un
nom discriminant peut tre ajout sur larc de spcialisation, pour distinguer diffrentes spcialisations dune classe.
Classe
de base
Personnes
Employs
Sous-classe
C1
Sous-classe
C2
Etudiants
Hommes
Personnes
{exclusif}
Femmes
Lagrgation est utilise pour reprsenter les situations o une classe est compose
dun ou plusieurs composants. UML permet de distinguer lagrgation indpendante
de lagrgation composite. La premire est une association particulire qui relie un
objet un ou plusieurs objets composants ; les deux classes sont deux classes autonomes. La seconde permet de reprsenter des objets composites rsultant de lagrgation de valeurs. Elle se distingue de la premire par un losange plein. Les diagrammes
reprsentant ces deux types dassociations sont symboliss figure XVII.8.
Classe
attributs
oprations
Composant
Attribut
attribut
nom
opration
opration
Les figures XVII.9 et XVII.10 illustrent les constructions introduites par deux tudes de
cas conduisant llaboration de schmas externes ou vues, ou encore paquetages (un
paquetage UML est un ensemble de composants objets qui peut comporter beaucoup
dautres lments). Chaque paquetage est reprsent par un rectangle tiquet contenant
ses composants. UML permet dajouter des notes tous les niveaux. Pour les paquetages, nous dfinissons dans la note associe la situation correspondante en franais.
La vie
Habite
Personne
*
nss
nom
prenoms
datenais
Adresse
1
tage
no
rue
code
ville
vieillir()
dormir()
dpend
*
Infrieur
Employ
fonction
1 salaire
Suprieur primes
travailler()
Voiture
Date
Prix
rouler()
1
Moteur
Type
type
puissance
marque
code
dmarrer()
stopper()
nss
nom
prenoms
adresse
dmnager()
1
1
nveh
couleur
km
Personne
Acheter()
Le premier problme est disoler les conflits. Cela ncessite le passage par un dictionnaire unique des noms, voire par une ontologie. Une ontologie est une dfinition complte des concepts, avec leurs relations smantiques. Lutilisation dune ontologie spcifique au domaine permet de ramener les concepts un rfrentiel unique et de
mesurer la distance et le recouvrement entre eux [Mtais97]. On peut ainsi isoler les
conflits potentiels.
Pour chaque cas, des solutions doivent tre envisages, telles que :
Changement de dnomination de classes, dassociations ou dattributs
Ajout dattributs ou remplacement par des oprations
Dfinition de classes plus gnrales ou plus spcifiques
Transformation dagrgation en objets composites et vice versa
Redfinition de types plus gnraux
Transformation de reprsentation
Conversion et changement dunits.
Certains conflits ne sont solubles que manuellement. Un outil graphique daide
lintgration peut tre avantageusement utilis.
Possde
Voiture
1
1
Moteur
Type
type
puissance
marque
code
dmarrer()
stopper()
Dpend
Suprieur
dmnager()
Habitation
tage
no
rue
code
ville
vieillir()
dormir()
Vendre()
Infrieur
nss
nom
prenoms
datenais
Date
Prix
rouler()
1
nveh
couleur
km
Habite
Personne
Employ
fonction
salaire
primes
Buveur
type
tat
boire()
travailler()
Boire
1..*
date
quantit
Vin
nv
cru
millsime
degr
qualit
EmployBuveur
un minimum de redondance. titre dillustration, la figure XVII.12 (ci-avant) propose un schma intgr rsultant de lintgration des vues La vie et La voiture
avec nos ternels buveurs ( La fte ). Vous pouvez reprer les transformations
effectues, qui sont assez rduites.
Les transformations proposes donnent autant de relations que dentits et dassociations. Il est possible de regrouper certaines relations et associations dans les cas particuliers o un tuple dune table rfrence un et un seul tuple de lassociation. Une telle
association est dite bijective avec lentit : en effet, tout tuple de la table correspond
un tuple de lassociation et rciproquement. La rgle est la suivante :
R3. Une association bijective, cest--dire de cardinalits minimale et maximale 1,
peut tre regroupe en une seule table avec la relation attache par jointure sur
la cl de lentit.
Cette rgle est illustre figure XVII.13. Dans le cas o lassociation est 1..1 des deux
cts, la rgle peut tre applique droite ou gauche, et si les deux entits ne sont
relies aucune autre association, elles peuvent mme tre regroupes en une seule table.
Pour implmenter un modle objet, il nest pas ncessaire d avoir une BD objet. Audel des entits et associations, tous les concepts dun modle objet peuvent tre
implments avec un SGBD relationnel. Alors que les tables mmorisent ltat des
objets, les mthodes apparaissent comme des attributs calculs. Elles seront gnralement implmentes sous forme de procdures stockes. Nous allons maintenant examiner le passage dun modle UML au relationnel, sachant que ce que nous avons dit
pour les associations restent vrai dans le contexte objet. La plupart des rgles dcrites
ci-dessous ont t implmentes dans le systme expert SECSI daide la conception
de bases de donnes [Bouzeghoub85].
Ent1
K1
A1
An
Ass
Abus
D1
Dp
Ent2
K2
B1
Bm
sibles, consistant toutes aplatir les hirarchies de spcialisation. Pour les mthodes,
le polymorphisme doit tre ralis dans le corps de la mthode par des tests (CASE).
Nous examinons ici la transformation des donnes, comme il se doit pour une base de
donnes.
La solution la plus naturelle pour traduire une hirarchie de gnralisations de classes
C1, C2Cn vers une classe C est dappliquer la rgle suivante, en plus de la rgle R1
qui conduit traduire chaque classe (ou entit) comme une table avec une cl primaire, la rgle suivante :
R4.a Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par rptition de la cl de la table reprsentant C au niveau de chacune des
tables reprsentant C1, C2Cn.
Cette solution conduit une table par classe (voir figure XVII.14(a)). Lorsquon souhaite retrouver un attribut hrit dans une classe drive, il faut effectuer une jointure
avec la table reprsentant la classe de base. Lhritage doit donc tre accompli par les
programmes dapplication. La dfinition dune vue jointure des tables drives et de
la table de base (par exemple C|X|C1) permet dautomatiser lhritage.
Dautres solutions sont possibles pour traduire des spcialisations, comme le montre
la figure XVII.14(b) et (c). La solution (b) consiste faire une table par classe feuille
de la hirarchie en appliquant la rgle suivante :
R4.b Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par rptition des attributs reprsentant C au niveau de chacune des tables
reprsentant C1, C2Cn et par transformation de C en une vue drive de C1,
C2Cn par union des projections sur les attributs de C.
Le problme avec cette solution survient lorsque les classes C1, C2, Cn ne sont pas
exclusives et contiennent des objets communs. Les attributs de C sont alors rpts
dans chacune des tables C1, C2Cn, ce qui pose des problmes de cohrence. Cette
rgle sera donc seulement applique dans le cas dhritage exclusif. Par exemple, il
est intressant de reprsenter la hirarchie dhritage FEMMES, HOMMES PERSONNES de la figure XVII.7 par les tables FEMMES et HOMMES, la table PERSONNES pouvant tre drive par une vue. Au contraire, la mme technique utilise
pour la hirarchie dhritage EMPLOYES, ETUDIANTS PERSONNES conduirait dupliquer les employs tudiants. On prfrera alors appliquer la rgle R4.a
conduisant trois tables EMPLOYES, ETUDIANTS et PERSONNES, chacune ayant
pour cl le numro de scurit sociale de la personne.
Une autre solution encore possible consiste implmenter une seule table comme
illustr figure XVII.14(c) :
R4.c Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par une table unique comportant la traduction de la classe C complte avec les
attributs de C1, C2Cn, les tables correspondant C1, C2Cn tant des vues
drives de C par projection sur les attributs pertinents.
Classe
C
Sous-classe
C1
C K
C1 K
C2 K
(a)
Sous-classe
C2
C1 C
C2 C
(b)
C C1 C2
(c)
Le problme avec cette solution survient lorsquun objet de la classe C na pas de spcialisation dans une sous classe Ci : dans ce cas, tous les attributs de la classe Ci apparaissent comme des valeurs nulles ! Par exemple, pour la hirarchie FEMMES,
HOMMES PERSONNES, les attributs spcifiques aux femmes seront nuls pour
chaque homme dans la table PERSONNES gnrale (par exemple, le nom de jeune
fille). Pour la hirarchie EMPLOYES, ETUDIANTS PERSONNES, tout employ
non tudiant aura les attributs dtudiants nuls et tout tudiant non employ aura les
attributs spcifiques aux tudiants nuls. Cette solution nest donc bonne que dans le
cas dhritage complet, o chaque objet de la classe de base est membre de la sousclasse.
En rsum, les diffrents cas sont illustrs figure XVII.14. Bien sr, ils peuvent tre
mixs et il faut rflchir pour chaque sous-classe. Certaines peuvent par exemple tre
regroupes avec la classe de base, dautres implmentes de manire autonome.
par concatnation des noms des entits participantes. On ajoutera un nom de rle si
plusieurs agrgations indpendantes relient deux classes.
Lagrgation composite correspond un groupe dattributs (et mthodes) imbriqus
dans lobjet composite. Dans le cas de bijection (cardinalit 1..1), tous les attributs de la
classe cible (le composant) sont simplement ajouts la table reprsentant la classe
source (le compos). La classe cible est reprsente par une vue. La rgle est la suivante :
R5. Une classe dpendant dune autre par une agrgation composite monovalue
est reprsente par des attributs ajouts la table reprsentant lobjet composite
et si ncessaire transforme en une vue, sinon omise.
Cette rgle est applique figure XVII.15. Au-del, le relationnel pur ne permet pas de
traduire les agrgations composites multivalues par une seule table. On procde alors
comme avec une agrgation indpendante et plus gnralement une association. Des
contraintes dintgrit additionnelles peuvent tre ajoutes, comme nous le verrons cidessous.
Marque et code sont intgrs
car l'agrgation composite est monovalue.
Voiture
nveh
couleur
km
rouler()
1
1
4
Porte
Type
hauteur
largeur
marque
code
Les attributs multivalus peuvent tre intgrs directement dans une classe par le
biais de collections SET<X>, LIST<X>, BAG<X>, etc. Une bonne modlisation
UML traduit de tels attributs en agrgations composites. Cependant, il est permis
dutiliser des templates ; alors le problme de la traduction en relationnel se pose.
Deux cas sont considrer pour traduire en relationnel. Si le nombre maximal N de
valeurs est connu et faible (< 5 par exemple), il est possible de dclarer N colonnes, de
nom A1, A2,, etc., o A est le nom de lattribut. Cette solution manque cependant de
flexibilit et conduit des valeurs nulles ds quil y a moins de N valeurs. Une solution
plus gnrale consiste isoler la cl K de la table rsultant de la classe ayant un attribut
collection, et crer une table rpertoriant les valeurs de la collection associe la cl.
La table a donc pour schma AS (K, A) et donne les valeurs de A pour chaque valeur
de K. Par exemple, si une collection a trois valeurs v1, v2, v3 pour la cl 100, (100-v1),
(100-v2) et (100-v3) seront trois tuples de la table AS. Les collections seront reconstitues par des jointures lors des interrogations. Cette solution est connue sous le nom
de passage en premire forme normale et nous y reviendrons ci-dessous.
Boire
1..*
Estbu
Abus
Abus
Date
Quantit
Vins
nv
cru
millsime
degr
sens permet les parcours de chemins dans les deux sens. Cest utile si les requtes le
ncessitent.
En fait, aujourdhui bien peu de SGBD objet-relationnel supporteront une telle
dmarche pour une grosse base (quelques centaines de classes). Elle conduit en effet
grer beaucoup de types et beaucoup de rfrences. De plus, le schma rsultat ne
peut tre normalis simplement et peut prsenter des difficults dvolutions, les types
tant souvent lis par hritage ou par agrgation. Nous conseillerons donc plutt
lapproche UML/RO plus compatible avec la thorie hrite du relationnel que nous
tudions ci-dessous.
Marque
Type
672RH75
Renault
RME8
Puiss. Coul.
8
Rouge 142032
NSS
Nom
Prnom
Date
Prix
Martin
Jacques
10021998
70 000
800AB64
Peugeot
P206A
Bleue
686HK75
Citron
BX20V
Verte
142032
Martin
Jacques
11061999
90 000
158037
Dupond
Pierre
200499
120 000
720CD63
Citron
2CV8
400XY75
Renault
RCL5
Verte
158037
Dupond
Pierre
200278
5 000
Verte
275045
Fantas
Julie
110996
20 000
280037
Schiffer
Claudia
963TX63
Renault
P306B
Bleue
NV
CRU
100
200
300
400
500
Volnay
Chablis
Chablis
Volnay
Sancerre
VIN2
CRU
MILL
DEGRE
Volnay
Chablis
Chablis
Sancerre
1992
1997
1999
2002
11.5
12.3
12.1
12.0
Lentit VIN a t reprsente par deux tables VIN1 et VIN2. En interrogeant par des
jointures et projections, et plus gnralement en SQL, il est impossible de retrouver
prcisment le degr dun vin ou la qualit dun cru millsim. Il y a perte de smantique car la jointure naturelle des deux tables VIN1 et VIN2 sur lattribut commun
CRU ne permet pas de retrouver les vins de dpart, avec un degr unique (par exemple
pour les Chablis).
TYPE
NV MARQUE
TYPE
PUISS. COUL.
NV NSS NOM
NSS NOM
PRNOM
Par suite, lors dune dcomposition, le schma de relation R (A1, A2 An) est remplac
par une collection de schmas dont lunion des attributs est (A1, A2 An). La jointure
naturelle R1 |X| R2 |X| Rn constitue donc une relation de mme schma que R, mais
dont les tuples ne sont pas forcment les mmes que ceux de R. titre dillustration, la
figure XVII.20 propose deux dcompositions possibles pour la relation VOITURE.
NV
MARQUE
TYPE
PUISS.
872RH75
Peugeot
P206A
Bleue
975AB80
Peugeot
P206A
Rouge
Dcomposition 1
R1
Dcomposition 2
NV
TYPE
COUL.
872RH75
975AB80
P206A
P206A
Bleue
Rouge
V1
V2
R2
COUL.
TYPE
MARQ.
PUISS.
P206A
Peugeot
V3
NV
TYPE
872RH75
975AB80
P206A
P206A
TYPE
PUISS.
COUL.
P206A
P206A
7
7
Bleue
Rouge
TYPE
MARQ.
P206A
Peugeot
Si lon admet qu un type de vhicule sont associes une seule marque et une seule
puissance (ce qui est vrai pour les tuples figurant sur des cartes grises), la dcomposi-
tion 1 est plus plaisante que lautre : elle permet de retrouver toutes les informations
par jointure, alors que la dcomposition 2 ne permet pas de retrouver la couleur dun
vhicule ; la jointure V1
V2
V3 est diffrente de la relation initiale VOITURE. Do la notion de dcomposition sans perte (dinformation).
Notion XVII.4 : Dcomposition sans perte (Lossless join decomposition)
Dcomposition dune relation R en R1, R2 Rn telle que pour toute extension de R, on ait :
R = R1
R2
Rn.
DATE
NSS
NSS
NV PRIX
NV
COUL.
MARQUE
DATE
NV PRIX
PUISS.
TYPE
DATE
MARQUE
NV
PRIX
TYPE
PRNOM
NOM
NSS
PUISS.
NSS
PRNOM
NOM
COUL.
PRNOM
NOM
5. DPENDANCES FONCTIONNELLES
Dans cette section, nous tudions les liens smantiques entre attributs, particulirement les liens fonctionnels.
Il est essentiel de bien remarquer quune dpendance fonctionnelle (en abrg, DF)
est une assertion sur toutes les valeurs possibles et non pas sur les valeurs actuelles :
elle caractrise une intention et non pas une extension dune relation. Autrement dit, il
est impossible de dduire les DF dune ralisation particulire dune relation. La seule
manire de dterminer une DF est de regarder soigneusement ce que signifient les
attributs car ce sont des assertions sur le monde rel qui lient les valeurs possibles des
attributs entre elles. Les DF devraient ainsi tre dclares par ladministrateur dentreprise au niveau du schma conceptuel et un bon SGBD devrait les faire respecter.
Dcomposition : X Y et Z Y X Z.
partir de ces rgles, il est possible dintroduire la notion de dpendance fonctionnelle lmentaire [Zaniolo81].
Notion XVII.6 : Dpendance fonctionnelle lmentaire
(Elementary functional dependancy)
Dpendance fonctionnelle de la forme X A, o A est un attribut unique nappartenant pas X (A
X) et o il nexiste pas X X tel que X A.
La seule rgle dinfrence qui sapplique aux dpendances fonctionnelles lmentaires est la transitivit.
COULEUR
TYPE
MARQUE
PUISSANCE
Il nest pas toujours possible de reprsenter les DF dune relation par un graphe
simple : si une partie gauche dune DF comporte plus dun attribut, il faut introduire
des arcs reprsentant une association de plusieurs sommets vers un sommet. Nous
pouvons alors utiliser la notation des rseaux de Ptri pour reprsenter les dpendances (voir figure XVII.23).
En effet, la relation :
REDUCTION (CRU, TYPE, CLIENT, REMISE)
dans laquelle :
(a) un cru possde un type associ et un seul,
(b) les rductions sont effectues selon le type et le client,
comporte une dpendance partie gauche multiple :
TYPE, CLIENT REMISE.
CRU
TYPE
CLIENT
REMISE
CHENAS
MEDOC
JULIENAS
A
A
B
C1
C2
C1
3%
5%
4%
CRU
TYPE
CLIENT
CRU TYPE
TYPE, CLIENT REMISE
REMISE
TYPE
COULEUR
MARQUE
PUISSANCE
En clair, une cl est un ensemble minimal dattributs qui dtermine tous les autres. Un
ensemble dattributs qui inclut une cl est appel supercl. Par exemple, NV est une
cl de la relation VOITURE, alors que (NV, TYPE) nest pas une cl mais une supercl. Il peut y avoir plusieurs cls pour une mme relation : on en choisit en gnral
une comme cl primaire. On parle parfois de cl candidate pour dsigner une cl
quelconque.
Cette forme normale est justifie par la simplicit et lesthtique. Elle consiste simplement viter les domaines composs de plusieurs valeurs. Plusieurs dcompositions
sont possibles, comme vu ci-dessus. Par exemple, la relation PERSONNE(NOM, PRENOMS) pourra tre dcompose en PERSONNE1(NOM, PRENOM1) et
PERSONNE2(NOM, PRENOM2) si lon sait que les personnes nont pas plus de deux
prnoms. Plus gnralement, nous avons montr ci-dessus quune relation de cl K
avec un attribut multivalu A* pouvait tre dcompose en deux relations par limina-
tion de lattribut multivalu et gnration dune table de schma (K, A) donnant les
valeurs lmentaires de A associes aux valeurs de la cl. La rgle de dcomposition
en premire forme normale nest rien dautre que lapplication systmatique de cette
transformation. Si la relation na pas dautre attribut que la cl et lattribut multivalu,
elle est simplement dsimbrique comme pour lexemple de la figure XVII.25.
PERSONNE
NOM
PROFESSION
DUPONT
Ingnieur, Professeur
MARTIN
Gomtre
Une telle relation doit tre dcompose en rptant les noms pour chaque
profession (Opration UNNEST)
Soulignons que la premire forme normale est une question de dfinition de domaine :
chaque valeur dun domaine est en effet un atome du point de vue du modle relationnel. Par suite, rien nempche de considrer une date ou une figure gomtrique
comme atomique si les domaines de valeur sont les dates et les figures gomtriques.
Cest une question de point de vue et de niveau de dcomposition.
Le schma typique dune relation qui nest pas en 2e forme normale est reprsent
figure XVII.26. K1 et K2 dsignent deux parties de la cl K. Le problme est que K2
lui seul dtermine Y : K2 Y. Donc Y dpend dune partie de la cl. Comme nous
le verrons plus loin, une telle relation doit tre dcompose en R1(K1,K2,X) et
R2(K2,Y).
Par exemple, considrons la relation :
FOURNISSEUR (NOM, ADRESSE, ARTICLE, PRIX)
Par suite, une partie de la cl (NOM) dtermine un attribut nappartenant pas la cl.
Cette relation nest donc pas en deuxime forme normale. Elle pourra tre dcompose en deux relations :
FOURNISSEUR (NOM, ADRESSE)
PRODUIT (NOM, ARTICLE, PRIX)
K1
K2
Soulignons quune partie de cl nest pas une cl. En consquence, une relation en 3e
forme est automatiquement en 2e : la condition 1 est automatiquement vrifie, mais
figure par souci de claret. Soulignons aussi que si la relation possde plusieurs cls
candidates, la dfinition doit tre vrifie pour chacune delles successivement.
Le schma typique dune relation qui nest pas en 3e forme normale est reprsent
figure XVII.27. K est la cl de R. Le problme est que X lui seul dtermine Z : X
Z. Donc Z dpend dun attribut non cl. Comme nous le verrons plus loin, une telle
relation doit tre dcompose en R1(K1,K2,X) et R2(K2,Y).
nest pas en troisime forme normale. En effet, lattribut non cl TYPE dtermine
MARQUE et aussi PUISSANCE. Cette relation peut tre dcompose en deux relations :
VOITURE (NV, TYPE, COULEUR)
MODELE (TYPE, MARQUE, PUISSANCE).
Si la relation possde une seule cl primaire, il est possible de donner une dfinition
quivalente comme suit. Une relation R est en troisime forme normale si et seulement si :
1)elle est en deuxime forme normale ;
2)tout attribut nappartenant pas la cl ne dpend pas transitivement de la cl.
Par exemple, dans la relation VOITURE, lattribut MARQUE dpend transitivement
de la cl ainsi que lattribut PUISSANCE :
NV TYPE PUISSANCE,
NV TYPE MARQUE.
NV
TYPE
COULEUR
MARQUE
PUISSANCE
R1
R2
K1
K2
R1
R2
X
Y
dpendances entre les attributs non cls. Quid des dpendances de parties de cls entre
elles ou dattributs non cl vers une partie de cl ? Eh bien, la 3e FN est insuffisante.
Afin dliminer les redondances cres par des dpendances entre parties de cls et
celles dj limines par la 3e FN, Boyce et Codd ont introduit la forme normale qui
porte leur nom (en abrg BCNF) [Codd74].
Notion XVII.13 : Forme normale de Boyce-Codd (Boyce-Codd normal form)
Une relation est en BCNF si et seulement si les seules dpendances fonctionnelles lmentaires sont
celles dans lesquelles une cl entire dtermine un attribut.
Cette dfinition a le mrite dtre simple : pas de dpendance autre que KA, K tant
la cl et A un attribut non cl. Il a t montr que toute relation a une dcomposition
en BCNF qui est sans perte. Par contre, une dcomposition en BCNF ne prserve en
gnral pas les DF. La figure XVII.32 illustre le cas typique o un attribut non cl
dtermine une partie de cl, et indique le schma de dcomposition associ.
K1
K2
Une telle relation doit tre dcompose en R1(K1, K2, X) et R2(Y, K1)
Cette relation nest pas en BCNF bien quen 3e forme puisque le cru ne dtermine pas
la rgion (il y a du Chablis en Bourgogne mais aussi en Californie ; notez que la qualit dpend bien du pays !). Une instance, le rseau de DF et la dcomposition souhaitable sont reprsents figure XVII.33. La DF CRU, PAYS REGION est perdue. La
dcomposition est cependant sans perte.
CRU
PAYS
REGION
QUALITE
Chenas
Julinas
Morgon
Chablis
Brouilly
Chablis
France
France
France
tats-Unis
tats-Unis
France
Beaujolais
Beaujolais
Beaujolais
Californie
Californie
Beaujolais
Excellent
Excellent
Bon
Moyen
Mdiocre
Excellent
PAYS
CRU
REGION
QUALITE
Dcomposition :
CRUS (CRU, PAYS, QUALITE)
REGIONS(REGION, PAYS)
NE est le numro dtudiant, COURS les cours suivis et SPORT les sports pratiqus.
Une extension de cette relation est reprsente figure XVII.34. NE, COURS et SPORT
constituent la cl compose. En effet, NE ne dtermine ni cours ni sport car il est
conseill de suivre plusieurs cours et de pratiquer plusieurs sports (cest le cas de
ltudiant 100 ci-dessous).
NE
COURS
SPORT
100
Bases de donnes
Tennis
100
Bases de donnes
Football
100
Rseaux
Tennis
100
Rseaux
Football
200
Rseaux
Vlo
Y).
Comme avec les dpendances fonctionnelles, il est possible deffectuer des infrences
partir des dpendances multivalues. Les axiomes dinfrence des DM sont les suivants, en considrant une relation compose dun ensemble dattributs R [Beeri79] :
1. Complmentation : (X
Y) (X
R X Y)
2. Augmentation : (X
Y) et (V W) (XW
YV)
3. Transitivit : (X
Y) et (Y
Z) (X
Z Y)
Des rgles additionnelles sen dduisent, telles que celle dunion :
4. Union : (X
Y) et (Y
Z) (X
YZ)
partir des axiomes prcdents, il est possible dintroduire la notion de dpendance
multivalue lmentaire, ceci afin dliminer les dpendances dduites trivialement
dun ensemble de dpendances de base [Zaniolo81].
Notion XVII.15 : Dpendance multivalue lmentaire
(Elementary multivalued dependency)
Dpendance multivalue X
Y telle que X X et Y Y.
AVION
PILOTE
PRENOM-ENFANT
NVEHICULE
Rappelons quune supercl est un ensemble dattributs contenant une cl. Donc, une
relation R nest pas en 4e FN si lon peut trouver une dpendance de la forme
X
Y o X ninclut pas une cl de R. Comme une dpendance fonctionnelle est
un cas particulier de dpendance multivalue, il apparat quune relation en quatrime
forme normale est en forme normale de Boyce-Codd et donc en troisime forme normale.
titre dexemple, la relation ETUDIANT (NE, COURS, SPORT) nest pas en quatrime forme normale : la cl est lensemble des attributs et il existe des DM lmentaires entre des attributs participants la cl :
NE
NE
COURS
SPORT.
Il a t montr que toute relation a une dcomposition (pas forcment unique) en quatrime forme normale qui est sans perte [Fagin77]. Par exemple, la relation ETUDIANT peut tre dcompose en deux relations (NE, COURS) et (NE, SPORT) qui
sont bien en quatrime forme normale.
CRU
PRODUCTEUR
Ronald
Chablis
Georges
Ronald
Chablis
Nicolas
Ronald
Volnay
Nicolas
Claude
Chablis
Nicolas
Cette relation est bien en quatrime forme normale. En effet, il nexiste pas de dpendance multivalue daprs lextension reprsente ci-dessus :
BUVEUR
CRU est faux car par exemple le tuple (Ronald Volnay Georges)
nexiste pas.
CRU
PRODUCTEUR est faux car par exemple le tuple (Claude Chablis
Georges) nexiste pas.
PRODUCTEUR
BUVEUR est faux car par exemple le tuple (Claude Volnay
Nicolas) nexiste pas.
Autrement dit, si lon considre les projections R1, R2, R3 de la relation BUVCRU
sur deux attributs (voir figure XVII.36), on constate que lon a :
BUVCRU R1
R2,
BUVCRU R1
R3,
BUVCRU R2
R3.
Cependant, la relation reprsente figure XVII.35 prsente bien des redondances : on
apprend deux fois que Ronald boit du Chablis et que Nicolas produit du Chablis. Elle
nest cependant pas dcomposable en deux relations.
R1
BUVEUR
CRU
Ronald
Ronald
Claude
Chablis
Volnay
Chablis
R2
R2
BUVEUR PRODUCTEUR
Ronald
Ronald
Claude
CRU
PRODUCTEUR
Chablis
Chablis
Volnay
Georges
Nicolas
Nicolas
Georges
Nicolas
Nicolas
Lide simple est que si la DJ est implique par les cls, la dcomposition nliminera
pas de redondance et est sans intrt. Si elle contient R, elle ne sert rien puisque R
demeure. Dans les autres cas, il est possible de dcomposer par projection selon les
schmas de la DJ ; lexpression de jointures drives de la JD permet de recomposer
la relation R. Par suite, la dcomposition dune relation non en 5e forme suit les DJ et
est sans perte. Par contre, elle ne prserve en gnral pas les DF, comme la BCNF.
Notons aussi que la 5e forme normale est une gnralisation directe de la BCNF et de
la 4e ; donc une relation en 5e forme est en 4e et bien sr en 3e.
Ainsi la relation BUVCRU nest pas en 5e forme normale puisque la seule cl candidate (BUVEUR, CRU, PRODUCTEUR) nimplique pas la DJ *{(BUVEUR CRU),
(CRU PRODUCTEUR), (BUVEUR PRODUCTEUR)}. Elle doit donc tre dcompose
en ces trois relations afin dviter les anomalies de mise jour.
[Fagin79] a dmontr le rsultat essentiel suivant. Toute relation en 5e forme normale
ne peut plus tre dcompose sans perte dinformations (except par les dcompositions bases sur les cls qui sont sans intrt) si lon ne considre que la dcomposition par projection et la recomposition par jointure. La 5e forme normale est donc un
point final la dcomposition par projection-jointure. Voil pourquoi Fagin a propos
dappeler cette forme forme normale de projection-jointure (JD/NF).
La 5e forme nest cependant pas la forme ultime de dcomposition si lon accepte
aussi des dcompositions horizontales, cest--dire en partitionnant la table en soustables comportant chacune un ensemble de tuples avec tous les attributs. Il est possible dintroduire des dpendances algbriques du style R E(R) o E est une
expression de lalgbre relationnelle avec union, projection et jointure
[Yannakakis80]. Les dpendances dinclusion constituent une forme plus restreinte
de dpendances qui unifient les FD et les JD [Abiteboul95]. Mais tout cela nest pas
dune grande utilit pour concevoir une BD.
ou en supprimant un index. Les modles base doutils gnraux bass sur les files
dattente sont aussi utilisables.
Au-del du modle qui est un problme en soi, nous examinons ci-dessous les paramtres sur lequel ladministrateur systme peut jouer. Ceux-ci sont souvent dpendant
du SGBD.
Cette technique est connue depuis longtemps sous le nom de placement proximit
dans le modle rseau. Elle permet par exemple de placer les lignes de commandes
dans la page de len-tte. Ainsi, la jointure ne ncessite quune entre-sortie par commande. Il ny a cette fois pas de duplication et donc pas de problme introduit en mise
jour. Cest donc une excellente technique qui peut cependant pnaliser les slections
sur lune et lautre des tables.
Tout tuple respectant les contraintes dintgrit doit appartenir lune des partitions.
Un exemple typique est la cration de partitions sur le mois pour la table des commandes. Ainsi, douze partitions sont cres, une par mois. Cette technique est particulirement intressante si les requtes indiquent souvent le mois de la commande, donc
en gnral un des i. Elle permet surtout de diviser les grosses tables notamment pour
le chargement et la sauvegarde. De nombreux SGBD limplmentent de manire invisible au dveloppeur dapplication. Le partitionnement horizontal correspond de fait
une dcomposition par union.
recherche sur cl, etc. Les SGBD du march automatisent de plus en plus ce type
dindexation.
2. Un attribut sur lequel figure un prdicat conjonctif avec galit sera index :
par un arbre B si le nombre de valeurs possibles dpasse quelques centaines ;
par un index bitmap sinon.
Il ne faut cependant pas abuser de lindexation pour les tables frquemment mises
jour ou avec insertions nombreuses. Dans ce cas, un modle analytique ou une simulation permettront dy voir plus clair. On pourra consulter [Cardenas75,
Schkolnick85] pour de tels modles.
9. CONCLUSION
En rsum, concevoir une base de donnes ncessite tout dabord dlaborer un
schma conceptuel. Le modle objet et le langage graphique de modlisation UML
nous semble un bon vhicule pour ce faire. partir de l, des rgles prcises permettent dobtenir un schma logique relationnel. Faut-il ensuite normaliser les schmas
de tables ? Cela peut tre utile en cas de mauvaise isolation des entits. Cependant, la
normalisation est un processus long qui ncessite danalyser les dpendances quon
napplique finalement qu lexception. Trop systmatiquement applique, elle
conduit clater les tables en molcules de quelques attributs. Il apparat alors des
myriades de tables quil faut regrouper. Loptimisation est finalement beaucoup plus
importante pour les performances, mais trs difficile matriser. Cest un mtier de
spcialiste de systme.
La conception reste encore plus un art quune science, surtout avec le modle objet.
En effet, on est peu prs incapable de dire ce quest un bon schma objet. De plus, le
passage dun schma objet un schma logique objet-relationnel reste une tape
mal matrise. Les approches par un modle smantique de plus haut niveau sont trs
10. BIBLIOGRAPHIE
[Abiteboul95] Abiteboul S., Hull R., Vianu V., Foundations of Databases, AddisonWesley, 1995.
Ce livre sur les fondements des bases de donnes couvre particulirement bien
la thorie des dpendances fonctionnelles, de jointure et dinclusion, et bien
dautres aspects.
[Aho79] Aho A.V., Beeri C., Ullman J-D., The Theory of Joins in Relational
Databases , ACM Transactions on Database Systems, Vol.4, n 3, p. 297-314,
Sept. 1979.
Cet article tudie la dcomposition dune relation par projection et donne des
algorithmes efficaces pour dterminer si la jointure de relations est sans perte
en prsence de dpendances fonctionnelles et multivalues.
[Armstrong74] Amstrong W.W., Dependency Structures of Database
Relationships , IFIP World Congress, North-Holland Ed., p. 580-583, 1974.
Cet article introduit les fameux axiomes de Armstrong.
[Batini86] Batini C., Lenzerini M., A Methodology for Data Schema Integration in
the Entity-Relationship Model , IEEE Transactions on Software Engineering,
vol. 10, n 6, p.650-664, Nov. 1984.
Les auteurs prsentent une mthodologie pour intgrer les schmas entit-association.
[Beeri79] Beeri C., Bernstein P.A., Computational Problems Related to the Design
of Norma Form Schemas , ACM Transactions on Database Systems, Vol.4,
n 1, Mars 1979.
Cet article dcrit un algorithme linaire pour tester si une dpendance fonctionnelle est dans la fermeture dun ensemble de DF et une implmentation
optimise de lalgorithme de synthse de Bernstein.
[Benci76] Benci E., Concepts for the Design of a Conceptual Schema , IFIP
Conference on Modelling in Database Management Systems, North-Holland
Ed., p. 181-200, 1976.
Chapitre XVIII
CONCLUSION ET PERSPECTIVES
1. INTRODUCTION
Trois gnrations de systmes de bases de donnes ont dj vu le jour. La premire
gnration des annes 70 correspondait aux modles hirarchique et rseau. Elle tait
reprsente par des produits tels TOTAL, IDS II, IMS et Socrate. La seconde gnration des annes 80 tait base sur le modle relationnel et fut conduite par les produits
Oracle, DB2, Ingres, Informix et Sybase. La 3e gnration des annes 90 a vu lintgration de lobjet aux systmes de 2e gnration. Bien que des systmes purs objets
tels O2 ou Object Store aient montr le chemin, lindustrie a procd par extension, si
bien que dun point de vue industriel Oracle, DB2, Informix et SQL Server restent les
produits phares maintenant de 3e gnration.
Les principes des systmes de bases de donnes sont souvent venus de la recherche au
cours de ces trente dernires annes. Lenjeu aujourdhui est le dveloppement de la
gnration de SGBD de lan 2000. Celle-ci devrait voir lintgration efficace du dcisionnel aux systmes transactionnels, le support transparent de lInternet et bien sr la
possibilit de recherche par le contenu des objets multimdias sur le Web vu comme
une grande base de donnes. Tous ces travaux sont dj bien engags dans les laboratoires de recherche et chez les constructeurs de SGBD, notamment aux USA. Nous
rsumons ci-dessous quelques aspects des recherches en cours qui nous paraissent
essentiels pour le futur.
2. LES BD ET LE DCISIONNEL
La dcennie 90 a vu le dveloppement des entrepts de donnes (Datawarehouse). Un
entrept de donnes est un ensemble de donnes historises variant dans le temps,
organis par sujets, agrg dans une base de donnes unique, gr dans un environnement de stockage particulier, aidant la prise de dcision dans lentreprise. Trois
fonctions essentielles sont prises en compte par ces nouveaux systmes dcisionnels :
la collecte de donnes partir de bases existantes et le chargement de lentrept, la
gestion et lorganisation des donnes dans lentrept, lanalyse de donnes pour la
prise de dcision en interaction avec les analystes.
La figure XVIII.1 illustre les composants dun entrept de donnes. Le moniteuradapteur est charg de la prise en compte des mises jour des sources de donnes
locales, de la prparation de tables diffrentielles (les deltas) pour envois lentrept
et du transfert des deltas priodiquement vers le mdiateur. Ce dernier assure la fusion
des sources et la mise en forme des donnes pour la base de lentrept. Autour du
datawarehouse, les outils OLAP (On Line Analysis Processing) permettent lanalyse
des donnes historises. Les outils de data mining permettent lextraction de rgles et
de modles partir des donnes.
Prsentation
Composant
dcisionnel
Composant
dcisionnel
Datawarehouse
Mining
Analyse
BD
Entrept
Mdiateur
Transformation
Moniteur/Adaptateur
Moniteur/Adaptateur
Source
Moniteur/Adaptateur
BD Source
Donnes
externes
BD Source
Donnes
oprationnelles
BD lgataires
3. BD ET WEB
Le Web sest dvelopp comme un hypertexte sur le rseau Internet, pour permettre
facilement laccs des fichiers chans. Rapidement, le besoin de couplage avec les
bases de donnes est apparu. Pourquoi coupler ? Trois raisons au moins motivent ce
besoin : lintroduction du client-serveur prsentation universelle (architectures 3tiers), la gnration de sites Web dynamiques composs partir de templates Html et
de donnes extraites de bases, et le commerce lectronique, qui ncessite la gestion de
catalogues et de transactions en bases de donnes.
Il existe dj de nombreuses solutions industrielles, plus ou moins issues de la
recherche, telles Oracle Web, Web SQL de Sybase, LiveWire de Netscape, Visual
Interdev de Microsoft, O2 Web, etc. Ces outils ralisent une intgration faible de deux
modles de donnes (le relationnel-objet et le modle semi-structur abstrait de Html).
Ils sont insuffisants car ils ne permettent gure la transcription automatique de rsultats de requtes en Html et vice-versa.
De nombreux projets de recherche (par exemple, Tsimmis Stanford [Abiteboul97],
Strudel ATT [Fernandez97], MiroWeb au PriSM en collaboration avec Osis et
lInria) tendent permettre le stockage direct dhypermdia dans la base. XML parat
le standard adapt pour les bases de donnes semi-structures. Les principaux projets
proposent des modles de reprsentation de documents XML et des langages dinterrogation associs. Les bases de donnes semi-structures [Abiteboul96, Buneman97]
modlisent les donnes par un graphe tiquet, chaque nud feuille pouvant correspondre un objet externe, structur ou non. Les tiquettes correspondent aux tags
XML. La figure XVIII.2 illustre un document semi-structur reprsent sous la forme
dun graphe et en XML.
Lutcia
RACINE
NOM
HOTEL.1
TEL
12345678
FAX
ADRESSE
HOTEL.2
98765432
Rivoli
RUE
VILLE
NOM
TEL
Paris
Crillon
13578642
<RACINE>
<HOTEL>
<NOM> Lutcia </NOM>
<TEL> 12345678 </TEL>
<FAX> 98765432 </FAX>
<ADRESSE>
<RUE> Rivoli </RUE>
<VILLE> Paris </VILLE>
</ADRESSE>
</HOTEL>
<HOTEL>
<NOM> Crillon </NOM>
<TEL> 13578642 </TEL>
</HOTEL>
</RACINE>
grammaire des documents (DTD) peut tre maintenue comme une nouvelle sorte de
contrainte dintgrit. La question dintgrer le semi-structur aux SGBD existants
reste pose. Elle ncessite en particulier la capacit dcouvrir des structures rptitives dans les documents, afin de les reprsenter sous forme dextensions de types.
Les langages SQL ou OQL doivent aussi tre tendus pour manipuler les graphes
dobjets semi-structurs, par exemple avec des parcours de chemins et des expressions
rgulires [Abiteboul97, Arocena98, Consens93, Fernandez97, Konopnicki95,
Mendelzon96].
La ralisation dadaptateurs capables de gnrer une vue semi-structure de sources
de donnes structures ou non est aussi un problme dactualit. Il faut non seulement
comprendre la smantique des sources afin de dcouvrir un peu de structure mais
aussi assurer le passage du structur au semi-structur. Des vues partielles de sources
sous forme de graphes tiquetes doivent tre gnres sur demande partir de
requtes.
Loptimisation de requtes mixant des donnes structures et semi-structures pose
aussi des problmes nouveaux. Il faudrait pouvoir disposer dun modle de cot pour
donnes semi-structures. La gestion de documents distribus (sur Intranet ou
Internet) ncessite aussi des techniques doptimisation originale pouvant allier les
approches push et pull.
4. BD MULTIMDIA
Le multimdia est la mode [Subrahmanian96]. Il est reconnu quune BD multimdia
doit possder cinq caractristiques :
1. grer des types de donnes multimdias incluant texte libre, gomtrie, image, son,
vido ;
2. offrir les fonctionnalits des bases de donnes, cest--dire lexistence dun langage
dinterrogation non procdural permettant les recherches par le contenu, la persistance, la concurrence et la fiabilit ;
3. assurer la gestion de larges volumes de donnes, pouvant atteindre les pta-bases
(10**15) ;
4. supporter des structures de stockage efficaces comme les Quadtree, les Rtree et
leurs variantes, pour permettre la recherche rapide par le contenu ;
5. tre capable de rcuprer des informations partir de sources htrognes.
Linterrogation dobjets multimdias passe par la recherche classique dans une BD
structure partir dattributs dcrivant les objets (exact-match retrieval), mais surtout
par la recherche base sur le contenu des objets. Une requte typique est la recherche
des k objets les plus similaires un objet donn. L, il ny a pas de garantie sur la correction et la prcision des rsultats. On rcupre un ensemble de rsultats classs par
ordre de pertinence et interrogeable nouveau (raffinement). Dans cet esprit, une
extension de SQL3 avec des types de donnes abstraits spcifiques au multimdia est
en cours de conception par un sous-groupe de lISO : SQL multimdia (SQL/MM). Il
sagit dun projet international de standardisation dont lobjectif est de dvelopper une
librairie de types SQL pour les applications multimdias. SQL/MM est compos de
diverses parties amenes voluer : Full text, Graphic still, Animation, Image still,
Full motion video, Audio, Spatial 2D et 3D, Music. Tous ces types de donnes
devraient tre standardiss, en conjonction avec dautres efforts (MPEG 7 par
exemple).
Les thmes de recherche lis au multimdia sont nombreux et sortent souvent du strict
domaine des bases de donnes. Il sagit en particulier de lindexation automatique
[Salton88], de lextraction de caractristiques (features), de lvaluation de distances
combines entre objets, de la gestion de proximit smantique, du dveloppement de
structures de stockage efficaces. Loptimisation de requtes, les modles de cots, la
formulation et lvaluation de requtes mixtes, lintgration aux SGBD existants, la
distribution et la recherche sur Internet/Intranet devraient aussi contribuer la constitution de muses virtuels interrogeables par le contenu sur les grands rseaux.
5. CONCLUSION
Les bases de donnes ont connu une volution douce vers lobjet, le standard tant
aujourdhui le relationnel-objet et SQL3. Les domaines les plus actifs sont le dcisionnel, lintgration avec le Web et le multimdia. Nous dveloppons ces thmes
dans un ouvrage complmentaire. Les bases de donnes mobiles ne sont pas non plus
ngliger et la conception, notamment dentrept de donnes et de BD actives, restent des problmes ouverts. Il ne faut pas non plus ngliger les thmes de recherche
traditionnels o il y a encore beaucoup faire (mthodes daccs, concurrence,
rparti, intgrit et vues, paralllisme).
Un sondage effectu rcemment auprs de 20 chercheurs reconnus (comit de programme de CIKM) sur leurs domaines dintrt a donn les rsultats indiqus
figure XVIII.3. La note est un poids entre 0 et 20 (intrt ou non).
Si lon analyse les thmes des articles des derniers VLDB et SIGMOD, on obtient des
rsultats sensiblement diffrents comme indiqus figure XVIII.4. Tout ceci montre
la fois la multiplicit, la diversit et louverture de la recherche en bases de donnes.
Les enjeux conomiques sont trs grands, ce qui explique la croissance du nombre de
chercheurs (400 articles soumis au dernier VLDB, 220 CIKM).
20
16
16
Application
15
14
Multimedia Databases
11
Database Design
10
Multimedia Databases
19
18
Application
Database Design
Figure XVIII.4 : Analyse des thmes des articles des derniers SIGMOD et VLDB.
Pour terminer, nous voudrions souligner la vertu des prototypes et des applications en
bases de donnes. La ralisation de systmes plus ou moins exploratoires (Socrate,
Syntex, Sabre, O2) a permis par le pass de constituer des quipes masse critique de
pointe. Elle permet aussi dacqurir des connaissances, de les et maintenir et de le
passer de nouveaux chercheurs au sein dun systme. Il ne faudrait pas que la rduction et la dispersion des crdits conduisent abandonner les grands projets au profit
de publications souvent secondaires.
La ralisation dapplications laide de prototypes avancs permet de cerner les vritables besoins et de dcouvrir des sujets neufs. De grandes expriences couples au
rseau (Intranet ou Internet) sont dj en cours par exemple au Muse du Louvre et
Bibliothque Nationale. Une meilleure participation de la recherche dans ces projets
est souhaitable.
6. BIBLIOGRAPHIE
[Abiteboul97] Abiteboul S., Querying semi-structured data , Proc. Of the
International Conference on Database Theory (ICDT), Jan. 1997.
Une mise en perspective thorique des bases de donnes semi-structures.
[Abiteboul97] Abiteboul S., Quass D., McHugh J., Widom J., Weiner J., The Lorel
Query Language for Semi-structured Data , Journal of Digital Libraries,
vol. 1, n 1, p. 68-88, April 1997.
Cet article prsente le langage LOREL, extension de OQL pour les donnes
semi-structures.
[Agrawal93] Agrawal R., Imielinski T., Swami A. N., Mining Association Rules
between Sets of Items in Large Databases , Proc. of the 1993 ACM SIGMOD
International Conference on Management of Data, Washington, D.C., 1993 ,
p. 207-216.
Le premier article sur les rgles associatives. Il propose la mthode Apriori
pour extraire les rgles associatives de grandes bases de donnes.
[Arocena98] Arocena G., Mendelzon A., WebOQL : Restructuring documents, databases and Webs , in Proc. IEE ICDE 98, Orlando, Florida, Feb. 1998.
Cet article propose un langage dinterrogation pour le Web construit partir
dOQL.
[Buneman97] Buneman P., Semi-structured data , Proc. ACM PODS97, Tucson,
Arizona, USA, p. 117-121, 1997.
Cet article prsente un tutoriel sur les donnes semi-structures. En particulier
le langage UnQL et les premires techniques doptimisation, en particulier
pour les expressions rgulires, sont dcrits.
EXERCICES
Prpars en collaboration avec
Yann Vimont
Laboratoire PRiSM, UVSQ
Question 1
Rappelez le fonctionnement dune E/S disque et calculez le temps ncessaire en fonction de la vitesse de rotation et du temps de dplacement de bras unitaire. Fixez les
paramtres des valeurs correspondant aux technologies courantes.
Question 2
Quel est le temps ncessaire pour excuter les requtes en attente suivant leur ordre
darrive (stratgie FIFO) ?
Question 3
Dterminez les quatre meilleures permutations possibles des requtes minimisant le
temps dE/S disques. Parmi ces quatre squences, quelle est la meilleure ? Pourquoi ?
Question 4
Donnez le principe dun algorithme permettant de trouver la squence optimale. Quel
doit tre son temps de rponse maximal pour quil puisse tre utilis ?
Question 5
Calculez le temps ncessaire pour excuter les cinq instructions dE/S en attente en choisissant chaque fois dexcuter la requte la plus proche des ttes de lecture-criture.
Question 6
Lutilisation de disques RAID permet dacclrer les E/S disques. Discutez des diffrents types de RAID et de leur intrt pour acclrer les cinq requtes.
Exercices 725
Question 1
Discutez le choix de la taille du paquet.
Proposez quelques fonctions de hachage afin de dterminer le numro de paquet
partir du numro de produit. Discutez de lintrt de ces fonctions selon le mcanisme
dattribution des numros de produits.
Question 2
Lorsquun paquet est plein, un produit devant tre insr dans ce paquet est crit en
dbordement. Proposez diffrentes solutions pour la gestion des dbordements. Pour
chacune delles, calculez le nombre dentres-sorties moyen ncessaires pour crire
un nouvel article et lire un article existant.
Question 3
On utilise le hachage extensible. Rappelez lalgorithme dcriture dun nouvel article
et de lecture dun article. Calculez le nombre dentres-sorties ncessaires pour crire
un nouvel article et lire un article existant.
Question 4
Mme question avec le hachage linaire.
Question 1
Rappelez la dfinition dun arbre B et dun arbre B+. Illustrez ces dfinitions en
construisant un arbre B et un arbre B+ pour stocker lalphabet dans des arbres dordre
2. Quel est lintrt dun arbre B+ par rapport un arbre B ?
Question 2
Calculez le nombre de comparaisons de cls ncessaires la recherche dune lettre
dans un arbre B et B+ dordre 2. Ce nombre est-il diffrent pour un arbre dordre 3 ?
Question 3
Il est possible de comprimer les cls dans un arbre B ou B+ en enregistrant pour
chaque cl seulement la diffrence par rapport la prcdente. Prciser alors le format
de chaque entre dans larbre B. Donnez les algorithmes de recherche et dinsertion
dune cl dans un arbre B ou B+ en prenant en compte la compression.
Question 4
VSAM implmente les arbres B+ en essayant de les calquer la structure des disques.
Discutez de lintrt de cette approche et de ses inconvnients. Calculez le nombre
dentres-sorties ncessaires pour lire un article dans un fichier avec un seul niveau
dindex matre. Mme question pour les insertions darticles.
Question 5
Une recherche dans un fichier simplement index par un arbre B sur une cl non discriminante (cl secondaire) peut tre coteuse. Pourquoi ? Proposez des approches
pour rduire le temps dentres-sorties disques ncessaire.
Exercices 727
Question 1
Donnez larbre obtenu en partant dune racine vide aprs insertion des articles de cl :
{Marcel, Marius, Martine, Maurice, Marcelle, Maude, Marc, Marguerite, Mathilde,
Maxime, Marielle, Martial, Mariette, Marina, Matthieu, Mattias} dans lordre indiqu.
Question 2
Donnez larbre obtenu si la liste des articles est trie selon lordre des cls :
{Marc, Marcel, Marcelle, Marguerite, Marielle, Mariette, Marina, Marius, Martial,
Martine, Mathilde, Matthieu, Mattias, Maude, Maurice, Maxime}.
Question 3
Proposez une procdure de construction de larbre B+ par construction directe des
feuilles et des sommets intermdiaires partir dun fichier tri des articles.
Question 4
On remarque que dans un arbre B+ les cls dans les sommets non-feuilles ne servent
que daiguilleurs dans la recherche dun article de cl donne. On utilise cette
remarque pour augmenter le nombre de couples cl/pointeur dans les sommets nonfeuilles en remplaant les cls par un prfixe de ces cls.
Donnez la rgle qui permet de dterminer le plus petit prfixe possible qui conserve la
proprit daiguiller correctement la recherche dans larbre.
Question 5
Donnez larbre obtenu en utilisant des prfixes par insertions rptes comme dans la
question 1.
Question 6
Discutez les avantages et les inconvnients de cette mthode pour de petits fichiers et
pour de grands fichiers.
Question
Quelle est la meilleure mthode et le nombre correspondant dentrees/sorties disques
ncessaires pour rpondre aux recherches suivantes :
Q1. (A = valeur)
Q2. (valeur < A )
Q3. (C = valeur)
Q4. (B = valeur)
Q5. (valeur 1 < C < valeur 2).
Q6. (C = valeur 1) ET (E = valeur 2)
Exercices 729
Les comparateurs peuvent tre =, <, > , , . Les expressions de AND et OR peuvent
tre encadres de parenthses pour indiquer les priorits.
Par exemple, on recherchera dans un fichier de vins tous les articles satisfaisant :
(CRU = Volnay OR CRU = Chablis)
AND DEGR 12 AND MILLSIME = 2000.
Question 1
On suppose le fichier des vins indexs par un arbre B sur la cl secondaire DEGR.
Proposez un format dentre pour un tel index. Justifiez votre solution.
Les degrs tant nombreux car continus entre 0 et 20, comment peut-on rduire leur
nombre ?
Proposez un algorithme permettant de rpondre aux requtes prcisant DEGR > $v,
o $v dsigne un rel compris entre 0 et 20.
Question 2
Ce fichier est aussi index sur les cls secondaires CRU et MILLSIME. Proposez
trois mthodes pour rsoudre des requtes du type CRU = $c AND MILLSIME =
$m, lune utilisant les deux index, les deux autres un seul ($c et $m sont deux
constantes). Essayer destimer le cot en entres-sorties de chacune delles. Donnez
des heuristiques simples pour choisir lune ou lautre.
Question 3
De manire gnrale, proposez un algorithme capable dvaluer efficacement des
recherches avec critres multiples conjonctifs (AND).
Question 4
tendre lapproche au cas de critres multiples connects avec des AND et des OR.
Question 5
Un fichier hach peut aussi tre index selon plusieurs attributs. Comment peut-on
amliorer lalgorithme prcdent pour supporter aussi des fichiers hachs ?
Question 1
On dsire placer un fichier de lignes de commandes de format (NC, NP, TYPE,
QUANTIT, PRIX) par hachage multi-attributs. NC dsigne le numro de commande, NP le numro de produit et TYPE le type du produit. Sachant que 50 % des
recherches se font sur NC, 20% sur NP et 30% sur le type de produit, proposez des
fonctions de hachage optimum afin de placer un tel fichier dans 100 paquets.
Question 2
Proposez un algorithme gnral pour rpondre aux requtes multicritres prcisant
deux des attributs hachs parmi les trois, par exemple NC et TYPE.
Question 3
Gnralisez lalgorithme pour traiter des requtes multicritres avec AND et OR,
comme vu lexercice prcdent.
Question 4
Les fichiers hachs peuvent aussi tre indexs par des arbres B. Discutez des formats
dadresses darticles intressants pour grer les index en conjonction au hachage.
Intgrez les rsultats de lexercice prcdent lalgorithme de la question 3. En
dduire un algorithme gnral pour traiter des requtes multicritres sur des fichiers
hachs sur plusieurs attributs et indexs.
Exercices 731
Question 1
Prcisez le format dun index bitmap et des structures associes. Calculez la taille
dun tel index. Proposez des mthodes de compression pour un tel index.
Question 2
Donnez les algorithmes dinsertion et suppression dun enregistrement dans un fichier
avec index bitmap.
Question 3
Un index bitmap sur un attribut A est idal pour acclrer des recherches sur critre
de la forme :
A = $a0 OR A = $a1 OR ... A = $an.
Question 4
On peut grer plusieurs index bitmap pour un mme fichier, sur des attributs A, B, etc.
Prcisez les types de critres pouvant tre traits par des index bitmap.
Question 5
On considre un fichier avec index bitmap et index secondaires sous la forme darbre
B. Que doit rfrencer une entre dans un index secondaire pour tre combinables
avec les index bitmap ? Donnez un algorithme gnral de recherche multicritres prenant en compte les index secondaires et les index bitmap.
CARREFOUR
RC
CC
CONNEXION
Une rue possde un nom, une longueur, une largeur minimum, un revtement et un
nombre de voies. Un carrefour possde un nom et un indicateur de prsence de feu tricolore. Une connexion indique la prsence ventuelle dun sens interdit.
Question 1
Donnez le schma CODASYL correspondant ce diagramme.
Question 2
Donnez le graphe des occurrences correspondant au plan simplifi, trois rues (X, Y,
Z) et quatre carrefours (C1, C2, C3, C4), suivant :
C2
Rue X
Rue Y
C3
C4
C1
Rue Z
Question 3
Donnez le programme en DML CODASYL permettant de trouver tous les carrefours
avec feu de la rue Albert Einstein.
Question 4
Donnez le programme en DML CODASYL permettant de trouver toutes les rues qui
sont directement accessibles depuis la rue Albert Einstein (donc qui lintersectent o
sy raccordent). Une rue nest pas accessible si elle est en sens interdit.
Question 5
Sachant que les poids lourds partent dun dpt situ dans la rue A, doivent rejoindre
le client situ rue B et ne doivent circuler que dans des rues de largeur suprieure 10
mtres, donner le programme en DML CODASYL et pseudo-code qui recherche tous
les itinraires possibles en ne les donnant quune fois avec leur longueur et le nombre
de feux. On prcise que la partie pseudo code devra rester un niveau de quelques
blocs de commentaires et devra rsoudre le problme de la dtection des boucles.
Exercices 733
Question 6
Proposez un placement des types darticle dans un ou plusieurs fichiers pour acclrer
les performances. Donnez le nombre dentres-sorties disque ncessaires pour traiter
la question 4.
Nom
Type
FOURNISSEURS
(1,N)
Couleur
(0,N)
Date
ACHTE
NSS
Nom
Prnom
CLIENTS
Prix
VEND
(0,N)
Remise
FOURNISSEURS
NF
Nom
Rgion
Cette base dcrit des produits vendus par des fournisseurs des clients.
Question 1
Donnez le schma rseau en DDL CODASYL correspondant au diagramme entitassociation reprsent figure 1. On prcise que les entits PRODUITS et FOURNISSEURS sont ranges dans un mme fichier FOU via le set VEND, alors que les instances de CLIENTS sont ranges dans le fichier CLI.
Question 2
crire les programmes en DML CODASYL correspondant aux requtes suivantes :
1. Nom des fournisseurs vendant des produits de type informatique .
2. Nom des clients ayant achet de tels produits.
3. Noms des produits et liste des fournisseurs associs ayant vendu au client de NSS
153300017012.
4. Chiffre daffaires total ralis avec le client Dupond Jules.
Utiliser du pseudo-Pascal ou pseudo-C si ncessaire.
Question 3
Donnez un schma relationnel pour la base de donnes reprsente.
Question 4
Exprimer en SQL les requtes correspondant aux questions tudies au 2.
Question 5
Pour les schmas reprsents, proposez un algorithme de traduction automatique de
requte SQL de type restriction-projection-jointure en programme DML CODASYL.
Pour cela, on traduira chaque requte en un arbre doprations de lalgbre relationnelle optimis de manire adquate ; ensuite, on traduira des groupes doprateurs
choisis en programmes DML avec du pseudo-PASCAL ou pseudo-C.
Question 6
tudiez le r-engineering de la base rseau propose en base relationnelle. Discutez
des difficults. Proposez une dmarche.
Exercices 735
C2
C1
C3
S
(0,1)
C4
B1
A1
A2
A3
(0,N)
RS
(1,1)
D1
ST2
ST1
(0,N)
D2
(1,N)
T
E1
E2
E3
Question 1
Donnez le schma de la base de donnes relationnelle reprsentant directement ce diagramme entit-association (une entit gnrant une relation, une association gnrant
une relation), avec les cls et les contraintes rfrentielles ncessaires.
Question 2
Exprimer en calcul de tuples les requtes suivantes :
1. Donnez tous les attributs de S pour les tuples dont lattribut C3 est compris entre
100 et 200.
2. Donnez les attributs C1 et C2 de S, E1 et E2 de T tels que les tuples de S et T soient
associs par un tuple de ST1 dattribut D1 suprieur 10.
3. Mme question, mais on souhaite en plus quil existe un tuple de R correspondant
chaque tuple de S slectionn, via lassociation RS, ayant un attribut A2 positif.
4. Donnez les tuples de T associs par RS tout tuple de R et au moins un tuple de T
par ST1 ou ST2.
Question 3
Exprimer ces mmes requtes en calcul de domaines.
Question 4
Exprimer ces mmes requtes en QBE.
Question 5
Exprimer ces mmes requtes en SQL.
Question 1
Exprimer sous la forme dun arbre de calcul de lalgbre relationnelle les requtes suivantes :
a) Donnez le nom, le prnom, la date de laccident pour chaque personne blesse fatalement dans un accident du dpartement 75 dans une voiture Citron.
b)Trouver les personnes qui ont t blesses dans tous les accidents o elles taient
conductrices.
Question 2
Que retrouve larbre algbrique suivant ?
Exercices 737
VHICULE
TYPE
VHPART
BLESS
'HONDA-CIVIC'
GRAVIT
'LGRE'
NVH
NACC
N COND
NVH
NACC
N PERS
N PERS
Question 3
Calculez le cot en entres/sorties disques de larbre de la question prcdente avec
les hypothses suivantes :
La relation VHICULE comporte 1 000 000 tuples dont 850 sont des Honda Civic;
elle est place par hachage statique sur le NVH ; elle possde un index secondaire
sur le TYPE qui est un arbre B+ 3 niveaux.
Les index secondaires du systme utilis retournent la cl primaire (ou cl de placement) et non pas directement ladresse physique.
La relation VHPART comporte 100 000 tuples ; elle est place sous forme darbre
B+ sur le NACC (index primaire).
La relation BLESS comporte 40 000 tuples dont 10 000 sont des blesss lgers ;
elle est place en squentiel avec un facteur de blocage (moyen) de 20 tuples par
page.
Les jointures sont faites par lalgorithme des boucles imbriques.
Tous les rsultats intermdiaires tiennent en mmoire centrale ; une page de
mmoire correspond un bloc de disque.
Question 4
Que devient le cot des entres/sorties si la mmoire est limite m pages ?
{B}
{5,7}
{8}
{8}
Exercices 739
{B}
{5,7}
{8}
{8}
Afin dillustrer, on considre une base de donnes dcrivant un stock de jouets de type
A, B, C ou D livrs par des fabricants en une certaine quantit une certaine date. Le
schma de la base est le suivant :
JOUETS(NJ,NOMJ,TYPE,PRIX)
FABRIQUANTS(NF,NOMF,VILLE,ADRESSE)
LIVRAISONS(NF,NJ,DATE,QUANTITE)
Question 1
Exprimez en algbre relationnelle tendue les questions suivantes sur la base de donnes des jouets :
a) Donnez la liste des fabricants qui ont livr au moins un jouet de type A et de prix
suprieur 1 000 F ainsi que le nom des jouets correspondants livrs.
b)Donnez la liste des fabricants qui nont pas livr de jouets.
c) Donnez la somme des quantits livres par chaque fabricant (caractris par NOMF
et ADRESSE).
Question 2
On se propose doptimiser lalgorithme dintersection de deux relations R1 et R2.
Proposez trois algorithmes permettant de raliser cet oprateur dans les cas sans
index, respectivement bass sur :
a) le produit cartsien des deux relations ;
b)le tri des deux relations ;
c) le hachage des relations avec tableaux de bits.
En supposant quil existe trois tampons dune page en mmoire, que les relations
comportent respectivement r1 et r2 pages (r1 < r2) et que la relation intersection est
compose de i pages, calculez approximativement le cot en E/S de chaque algorithme. On supposera que les tableaux de bits tiennent en mmoire et quils permettent dliminer un pourcentage b des tuples de la deuxime relation.
Question 3
On se propose dtudier lalgorithme de groupage dune relation R. Proposez trois
algorithmes permettant de raliser cet oprateur dans les cas sans index, respectivement bass sur :
a) la comparaison des tuples de la relation (proche du produit cartsien) ;
b)le tri de la relation ;
c) le hachage de la relation avec comparaisons internes aux paquets.
En supposant quil existe trois tampons dune page en mmoire, que la relation comporte r pages et que la relation groupe est compose de g pages, calculez approximativement le cot en E/S de chaque algorithme.
Question 4
Exprimer la question suivante en SQL sur la base de donnes des jouets :
Donnez les chiffres daffaires de chaque fabricant (caractris par son NOMF et son
ADRESSE) de poupes (NOMJ LIKE Poupe ).
Exprimer cette question en algbre relationnelle tendue.
Donnez un arbre doprateurs dalgbre relationnelle optimis permettant de calculer
la rponse cette question. On ajoutera pour cela loprateur de groupage (not par un
rectangle) aux oprateurs classiques.
Les rayons identifis par la cl NOMR sont situs un tage donn. Les articles sont
rfrencs par lentier RFRENCE et dcrit par un type, une description et une couleur. Ils sont disponibles en une certaine quantit chaque rayon. Un employ travaille un rayon et a pour responsable un autre employ. Lattribut responsable reprsente donc un numro demploy.
Exercices 741
Question 1
Proposez sous la forme dun graphe un ensemble de cls trangres pour cette base de
donnes.
Question 2
Exprimer en algbre relationnelle puis en SQL les requtes suivantes :
a) rfrences des articles de type lectromnager en rayon au second tage,
b)nom des employs travaillant dans un rayon proposant des articles de type jouet
pour une quantit totale suprieure 1 000.
Question 3
Exprimer en SQL les requtes suivantes :
c) nom des employs qui gagnent plus que leur responsable,
d)tages qui ne vendent que des vtements.
Question 4
Exprimer en calcul de tuple puis en SQL la requte suivante :
e) nom et salaire du responsable le mieux pay.
La base du WCCR comprend cinq relations et les cls sont soulignes. Les SPOTS
sont les bons coins pour faire de la planche, avec un numro, leur nom, lexposition
principale par exemple Sud-Ouest, le type par exemple Slalom ou Vague, et une
note dapprciation globale. Les PLANCHISTEs sont les membres du club et les invits, les niveaux varient de Dbutant Comptition. Le MATOS (jargon planchiste
pour matriel) comprend la description des planches utilises (pour simplifier les
voiles, ailerons, etc., ne sont pas reprsents). Le VENT dcrit la condition moyenne
dun spot pour une date donne. Enfin NAVIGUE enregistre chaque sortie dun plan-
chiste sur un spot une date donne avec le matos utilis. Pour simplifier, on suppose
quun planchiste ne fait quune sortie et ne change pas de matos ni de spot dans une
mme journe.
Question 1
Indiquez les cls trangres ventuelles de chaque relation.
Question 2
Donnez les expressions de lalgbre relationnelle qui permettent de calculer les
requtes suivantes :
a) Nom des planchistes de niveau Confirm qui ont navigu le 20/07/99 sur un spot
o le vent moyen tait suprieur force 4 sur une planche de moins de 2,75 m.
b)Nom des planchistes qui ne sont pas sortis le 20/07/99
c) Nom des planchistes qui ont essay tous les types de planches de la marque
FANA-BIC. On suppose que tous les types sont dans la relation MATOS.
Question 3
Donnez les expressions de calcul de tuples correspondant aux trois requtes prcdentes.
Question 4
Donnez les ordres SQL correspondant aux requtes suivantes :
c) Nom des planchistes qui ont essay tous les types de planches de la marque
FANA-BIC. On suppose que tous les types sont dans la relation MATOS.
d)Pour chaque spot de la base, en indiquant son nom, donner le nombre de jours de
vent au moins de force 4 pour lanne 94.
e) Pour chaque marque de matriel reprsente par au moins 10 planches, indiquer le
nombre dutilisateurs Confirm ou Expert.
Exercices 743
Les clients rservent des chambres dans des htels en station. On note que pour une
rservation de plusieurs personnes (couple ou famille) un seul nom de client est enregistr. De plus une rservation porte sur une seule chambre (pour une famille dans
deux chambres il faudra deux tuples dans rservation).
Exprimer en SQL les questions suivantes :
Question 1
Donnez le nom des clients et le nombre de personnes correspondant pour les rservations de lhtel Bellevue Courchevel.
Question 2
Pour chaque station de Haute-Savoie, donner le nombre de lits en catgorie trois
toiles.
Question 3
Pour chaque station de Haute-Savoie, donner le nombre de chambres rserves le
samedi 11/02/95.
Question 4
Quels sont les noms des htels de catgorie deux toiles de Mribel qui sont complets la semaine du 12/02/2000 au 18/02/2000 ?
Question 5
Quelles sont les rgions dont toutes les stations sont plus de 1500 m daltitude ?
Question 6
Quels sont les clients qui sont alls dans toutes les stations du Jura ?
Tous les attributs sont de type chanes de caractres notamment un bar, un buveur ou
un vin.
Exercices 745
Cette base gre des objets archologiques et des publications sur ces objets. La relation OBJET dcrit les objets proprement dits avec lindication de leur type (par
exemple vase), de leur datation qui est une anne, du site o ils ont t dcouverts et
du muse o ils se trouvent actuellement. La relation VILLE comprend deux noms
pour simplifier (ce qui par exemple exclut le cas BIZANCE-CONSTANTINOPLEISTAMBUL). La relation SITE indique la ville laquelle se rattache le site et un
numro qui est un numro dordre pour cette ville : toutes les villes ont un site 1, un
site 2, etc. La civilisation du site est une grande catgorie comme romaine ou crtoise. Les cls sont soulignes.
Question 1
Exprimer en SQL les requtes suivantes sur la base :
Q1. Quelles sont les frises du troisime sicle ? Donnez leur numro et leur description.
Q2. Mme question avec en plus le nom du muse o elles sont exposes.
Q3. Noms et prnoms des auteurs douvrage(s) rfrenant des objets de la civilisation Dorienne.
Q4. Quelles statues sont exposes dans la ville o elles ont t dcouvertes ?
Donnez le numro et la description.
Q5. Donnez le nom actuel des villes (sil en existe) dont le nom actuel est le mme
que le nom ancien dune autre ville.
Q6. Donnez le nombre de statues trouves dans chaque site de la civilisation phnicienne.
Q7. Quels sont les sites dAthnes qui ont fourni plus dobjets que le site 5 nen a
fourni ?
Q8. Noms et prnoms des auteurs des ouvrages qui rfrencent tous les objets trouvs dans le site 2 de Thbes.
Question 2
Soit la requte SQL suivante :
SELECT P.TITRE, P.DATE
FROM
PUBLICATION P, AUTEUR A, COOPERATION C,
REFERENCE R, OBJET O, MUSEE M
WHERE A.NOM = Vieille
AND
A.PRENOM = Pierre
AND
A.NUM-AUT = C.NUM-AUT
AND
C.NUM-PUB = P.NUM-PUB
AND
P.EDITEUR = ditions archologiques modernes
AND
P.NUM-PUB = R.NUM-PUB
AND
R.NUM-OBJ = O.NUM-OBJ
AND
O.TYPE = Mosaque
AND
O.NUM-MUSEE = M.NUM-MUSEE
AND
M.NOM = Le Louvre
Proposez deux arbres algbriques diffrents pour excuter cette requte. Le premier
arbre sera optimis au mieux en utilisant les heuristiques de restructuration algbrique
et le second sera le pire possible.
Question 3
On suppose quil y a dans la base 10 000 publications, 100 diteurs distincts,
1 000 auteurs de noms diffrents (pas dhomonymes), 2000 cooprations, 100 000 objets,
200 types dobjets diffrents, 1 000 000 de rfrences et 100 muses de noms diffrents (pas dhomonyme).
On suppose de plus que toutes les distributions sont uniformes et indpendantes.
En prenant comme unit de cot la comparaison pour les slections et les jointures, en
supposant quil ny a pas dindex et en admettant que toutes les jointures se font par
produit cartsien, calculer le cot dexcution des deux arbres que vous avez propos.
Question 4
Si vous tiez autoris crer un seul index pour acclrer cette requte, lequel choisiriez-vous ? Pourquoi ?
Exercices 747
relations diffrentielles sont associes chaque relation R : la relation des tuples supprims R et celle des tuples insrs R+. Un tuple modifi donne naissance deux
tuples, lun dans R-, lautre dans R+. En fin de transaction valide, les tuples de R
sont enlevs de R et ceux de R+ ajouts R. Le SGBD ralise : R = (R R-) R+.
En guise dillustration, on utilisera la base compose des tables suivantes :
PLAGE (NP, NOMP, TYPE, REGION, POLLUTION)
NAGEUR (NN, NOM, PRENOM, QUALITE)
BAIGNADE (NN, NP, DATE, DUREE).
La relation PLAGE modlise les plages de France, de nom NOMP, de type TYPE
(galets, sable ou rocher) ayant un taux de pollution donn (attribut POLLUTION). La
relation NAGEUR mmorise les nageurs de qualit excellente, bonne ou mdiocre. La
relation BAIGNADE dcrit les bains effectus par les nageurs.
Question 1
Dfinir en SQL2 les contraintes dintgrit suivantes :
1. La qualit dun nageur est excellente, bonne ou mdiocre (contrainte de domaine).
2. Toute baignade a t effectue par un nageur existant dans la base sur une plage
existante (contraintes rfrentielles).
3. Le type et la rgion dune plage dterminent sa pollution de manire unique (dpendance fonctionnelle).
4. La somme des dures des baignades dun nageur par jour ne doit pas excder deux
heures.
Question 2
Prcisez quels types de contraintes dintgrit peuvent tre vrifies aprs chaque
ordre de mise jour (INSERT, DELETE, UPDATE) ceux qui ncessitent dattendre la
fin de transaction.
Question 3
Proposez des algorithmes pour traiter chaque type de contraintes dintgrit, soient
excuts aprs la mise jour, soient en fin de transaction. Montrer quil est possible
de combiner les deux types de vrification.
Question 4
Les contraintes avec agrgats comme la somme des dures des baignades sont coteuses vrifier chaque mise jour. Proposez une mthode base sur des donnes
redondantes afin de rduire ce cot.
NUMF, NUMP, NUMA, NUMC, NUMS, sont des identifiants uniques (cls primaires) pour
respectivement : FILM, PERSONNE, ACTEUR, CINMA, SALLE.
Tout nom de relation utilis comme attribut est une cl trangre qui renvoie lidentifiant (cl primaire) de la relation correspondante, par exemple dans GNRIQUE,
FILM correspond NUMF de FILM et est dfini sur le mme domaine.
RALISATEUR dans FILM et NUMA dans ACTEUR sont dfinis sur le domaine des
NUMP.
Le numro de salle NUMS est un numro local pour chaque cinma (Salle 1, 2, 3, ).
Question 1
Donnez la dfinition de FILM en SQL2 en prcisant les contraintes de domaine, de
cl (primaire ou candidate), et de cl trangre.
Question 2
Mme question pour GNRIQUE si on suppose quun acteur peut jouer plusieurs
rles dans un mme film.
Question 3
Exprimer la contrainte gnralise suivante : Le budget dun film doit tre suprieur
la somme des salaires des acteurs jouant dans ce film
Question 4
crire un dclencheur qui met jour automatiquement le numro de film dans toutes
les relations o il est utilis si ce numro est modifi dans la relation FILM.
On ajoute un attribut NBSALLES a FILM qui indique le nombre de salles o le film
est actuellement visible.
Exercices 749
Question 5
Utiliser des dclencheurs pour grer automatiquement ce nombre de salles.
La relation produit dcrit des produits en stock de numro NP, de nom NOMP, en
quantit QTES, dont le prix de vente unitaire est PRIXU. La relation VENTES dcrit
les ventes ralises ; celles-ci sont numrotes par client. QTEV est la quantit vendue
pour le produit NP au client NC lors de la vente NV. Pour simplifier, on supposera que
les prix des produits ne changent pas.
Question 1
Dfinir les vues VENTEPRO (NC,NP,NV, QTEV, PRIXU) et VENTETOT (NC,
PRIXT) spcifies comme suit :
VENTEPRO donne pour chaque client, pour chaque produit et pour chaque vente la
quantit de produit vendu et le prix unitaire du produit correspondant.
VENTETOT donne pour chaque client le montant total en francs (PRIXT) des
ventes effectues.
On crira les questions SQL permettant de crer ces vues partir des relations de
base.
Montrer que la vue VENTETOT peut tre dfinie partir de la vue VENTEPRO.
Donnez sa dfinition en SQL partir de VENTEPRO.
Question 2
On introduit un oprateur partitionnement reprsent par un rectangle prparant
lapplication du GROUP BY sur une relation, utilisable dans les arbres relationnels ;
cet oprateur partitionne horizontalement la relation sur les attributs paramtres en
effectuant simplement un tri sur ces attributs : il sagit donc en fait dun oprateur de
tri. En addition, on permet lusage de fonctions agrgats et arithmtiques dans les projections. Appliques aux relations partitionnes suite loprateur prcdent, les fonctions agrgats accomplissent les calculs dagrgats selon le dernier partitionnement
effectu.
Donnez larbre relationnel optimis permettant de retrouver les clients ayant achet
pour plus de 10 000 F de produits avec la liste des produits quils ont achets.
Question 3
La modification de questions sur des vues (avec ou sans agrgat) ne permettant pas
toujours doptimiser, une autre mthode dimplantation de vues peut tre base sur la
matrialisation de la vue comme une relation implante sur disque (vue concrte). Le
problme qui se pose est alors de mettre jour la vue concrte lors des mises jour
des relations de base. Une technique possible consiste gnrer des dclencheurs
(triggers).
Exprimer en SQL les dclencheurs permettant de maintenir les relations VENTEPRO et
VENTETOT lors dinsertion dun nouveau produit ou dune nouvelle vente dans la base.
De manire gnrale, prciser les rgles gnrer pour maintenir une vue lors dinsertion dans une relation de base. On pourra considrer les cas suivants :
1. La vue est sans agrgat, cest--dire issue de projection, jointure et restriction des
relations de base.
2. La vue est avec agrgat.
Question 4
Donnez les rgles permettant de maintenir les relations VENTEPRO et VENTETOT
lors dune suppression dun produit ou dune vente dans la base.
De manire gnrale, prciser les rgles gnrer pour maintenir une vue sans agrgat, puis avec agrgat, lors dune suppression dans une relation de base. Discutez
selon les cas. Prciser les attributs quil est ncessaire de rajouter la vue afin dtre
capable de grer correctement les suppressions.
Exercices 751
Celles-ci dcrivent des buveurs identifis par lattribut numro NB, des vins identifis
par lattribut numro NV et des consommations (ABUS) de vins identifis par le
numro de buveur, le numro de vin et la date de consommation.
Question 1
Donnez les commandes SQL permettant de crer les vues suivantes :
BUVEURSB (NB, NOM, PRENOM, NV, DATE, QUANTITE)
Question 2
Un utilisateur ayant droit dinterroger partir des vues prcdentes pose la question
suivante :
Donnez le nom des buveurs ayant bu du Beaujolais de millsime 1983 en quantit
suprieure 100, le mme jour .
Exprimez cette question telle que doit le faire lutilisateur en SQL. Exprimez galement la question modifie portant sur les relations BUVEURS, VINS et ABUS que traitera le systme.
Question 3
De manire gnrale, proposez en quelques botes, sous la forme dun organigramme,
un algorithme permettant de transformer une question pose sur une vue en une question exprime sur la base.
Question 4
partir de lexemple, dcouvrir et noncer quelques problmes soulevs par la mise
jour travers une vue rfrenant plusieurs tables :
1. ajout dun tuple dans BUVEURSB ;
2. suppression dun tuple dans BUVEURSB.
o:
NOMV = nom de ville,
POP = population,
NDEP = numro de dpartement,
NOMD = nom de dpartement,
REGION = nom de rgion,
NOMP = nom de produit,
TYPE = type de produit.
Soit lexpression algbrique suivante rfrenant les relations de cette base de donnes (
reprsente la jointure naturelle) :
DEPARTEMENT
NOMV,NOMP(REGION=Auvergne(POP>10000 (VILLE
SPECIALITE)))
DEPARTEMENT
NOMV,NOMP ( NOMP=Fromage (VILLE
SPECIALITE)))
Question 1
Exprimez cette requte :
1) en calcul relationnel de domaine;
2) en calcul relationnel de tuple;
3) en SQL.
Question 2
Reprsentez la question sous forme dun arbre doprations algbriques.
Proposez un arbre optimis par restructuration algbrique pour cette question.
Question 3
Soit v, d et s les tailles respectives en tuples des relations VILLE, DEPARTEMENT et
SPECIALITE. En supposant luniformit des distributions des valeurs dattributs,
calculez une approximation de la taille du rsultat de la question prcdente en
nombre de tuples. On pourra introduire tout paramtre supplmentaire jug ncessaire.
Exercices 753
Question 1
Donnez les arbres algbriques relationnels optimiss par les heuristiques classiques
des BD relationnelles (descente des projections et restrictions) permettant dexcuter
cette question.
Question 2
On choisit larbre qui effectue les jointures dans lordre R1 avec R2 puis avec R3. En
considrant lutilisation dun algorithme de jointure par produit Cartsien (boucles
imbriques), calculez le temps dexcution en nombre dE/S de cet arbre en fonction
de la taille en page des relations R1, R2 et R3, du nombre moyen de tuples par page T,
du nombre de valeurs distinctes et non distinctes des attributs utiliss. On supposera
pour cela une distribution uniforme des valeurs dattributs. Tout paramtre supplmentaire jug ncessaire pourra tre introduit.
Question 3
Proposez un ensemble dindex plaant et non plaant optimaux pour la base de donnes et la question considre.
Calculez alors le temps dexcution de la question.
On pourra supposer pour simplifier que tous les index sont deux niveaux et on ngligera les temps de calcul.
U1 et V1 sont respectivement les cls uniques de R3 et R2. Tous les attributs sont des
entiers tirs alatoirement.
Question 1
On considre alors la question :
SELECT U2,V2
FROM R1, R2, R3
WHERE R3.U1 = R2.V2 AND R2.V1 = R1.T1 AND R3.U3 = 100.
Donnez tous les arbres relationnels effectuant les projections ds que possible permettant dexcuter cette question.
Question 2
Calculez le cot en nombre dentre-sortie des trois arbres effectuant la restriction
dabord dans le cadre dun SGBD relationnel implmentant les restrictions par
balayage et les jointures par parcours dindex ou boucles imbriques. On prcise quil
existe un index sur les cls U1 de R3 et V1 de R2 et pas dautre index. La taille de
chaque relation R1, R2 et R3 est respectivement r1, r2 et r 3. On supposera une distribution uniforme des valeurs dattributs. Le nombre de valeurs distinctes dun attribut
est obtenu par la fonction DIST (par exemple, DIST(U2) est le nombre de valeurs distinctes de U2). Ce nombre peut tre calcul.
Question 3
Mme question avec des jointures par hachage.
Question 4
Avec un algorithme par hachage ou par boucles imbriques, il est possible de commencer une jointure avant davoir fini la prcdente. Expliquez ces algorithmes dits
de type pipeline.
Dans quel cas est-il intressant dutiliser un algorithme de type pipeline ?
Question 5
On gnralise ce type de requtes N relations Rn, Rn-1,...R1. Donnez la forme gnrale dune requte. Calculez le nombre de plans possibles pour une telle requte.
Exercices 755
Question 1
Proposez un algorithme en pseudo-code, utilisant au mieux lindex de jointure, permettant de rpondre la question (bta est une constante et il ny a pas dindex sur
V2) :
SELECT U.U2
FROM U, V
WHERE U1 = V1 AND V2 = beta
Question 2
On suppose que le systme gre un index de U sur U1 et de V sur V1 la place de
lindex de jointure. Dtailler lalgorithme pour rpondre la question prcdente en
utilisant la jointure par index. Calculez le cot dune telle jointure. On prcise que :
1. le nombre doctets occups par chaque valeur de U1 ou U2 est dnot a ;
2. le nombre de valeurs distinctes de U1 est DIST(U1), celui de U2 est DIST(U2) ;
3. les index sont des arbres B+ deux niveaux (feuille + racine).
Comparer la solution index de jointure vue en 1.
Question 1
Donnez en UML la dfinition dun schma objet quivalent cette base relationnelle.
Exprimez ce schma en ODL.
Question 2
Puisque DOCTEUR et INFIRMIER sont des EMPLOYEE, proposez un nouveau
schma objet utilisant lhritage pour la base hospitalire.
Exercices 757
Question 3
Exprimez en OQL la requte suivante : Nom et prnom des cardiologues soignant un
malade Parisien (dont ladresse contient Paris) dans le service de Chirurgie gnrale.
Question 4
Essayez de simplifier le schma objet en introduisant des attributs multivalus.
Proposez des requtes OQL utilisant des collections dpendantes.
Question 1
Discutez de lintrt de choisir un SGBD objet ou objet-relationnel. Effectuez un
choix.
Question 2
Compltez la reprsentation UML de la base en prcisant les cardinalits des associations.
Personnes
PreNoel
Enfants
Effectue
Visite
Possde
Tourne
Distribue
Hte
Contient
Jouets
Question 3
Dfinir le schma de la base en C++. Bien lire le texte et la question 4 afin de prvoir
les structures et mthodes capables dy rpondre.
Question 4
crire des programmes C++ naviguant dans la base et rpondant aux requtes suivantes :
Q1 : Nom du pre nol qui vous a visit et prix total des jouets que vous avez reus
Nol (on suppose que vous tes un enfant).
Q2 : Distance parcourue par le pre nol Georges Gardarin et liste des jouets distribus.
U1 : Mettre jour la base par enregistrement dune nouvelle tourne pour un pre
nol donn.
Exercices 759
M#
I#
Nom
...
Nom
...
Modle
Ingnieur
Suivi
Date
Pice
Rle
...
P#
Des.
...
Question 1
Proposez une reprsentation objet de ce schma en utilisant UML. Discutez les proprits de votre reprsentation. Donnez la dfinition en ODL correspondante.
Question 2
crire les mthodes ncessaires pour faire une affectation dune pice un modle
davion avec lindication de la liste des ingnieurs chargs du suivi. Les mthodes
seront crites en Smalltalk, C++ ou Java persistant (ODMG) ou en pseudo-code pour
ceux qui ne sont pas laise avec les concepts de lun de ces langages objet. Attention
lencapsulation.
Question 3
Certaines pices sont en fait des modules composs dautres pices ou dautres
modules. Proposez une modification du schma pour Pice.
Question 4
crire une mthode qui donne la liste de tous les ingnieurs impliqus dans le suivi
dun module, soit directement soit au titre dun composant. On pourra utiliser la
mthode prdfinie union de la classe gnrique Set qui prend un autre Set en
paramtre.
Question 1
Rappelez les extensions ncessaires lalgbre relationnelle pour exprimer les
requtes objets. Proposez des exemples gnriques de requtes illustrant chaque
extension.
Question 2
Soit une succession de classes T1, T2, ...Tn relies par des associations [M-N] via des
attributs de rle nomms A, B, ...X, comme reprsent ci-dessous :
C1
*
A
C2
*
B
C3
*
C
...
Cn1
*
X
Cn
Quels algorithmes proposeriez-vous pour traiter efficacement la requte SQL3 de parcours de chemins :
SELECT *
FROM C1, C2, ... Cn
WHERE C1.A = OID(C2)
AND C2.B = OID(C3)
...
AND Cn-1.X = OID(Cn) ?
Exercices 761
Cette base reprsente des objets RGIONS ayant un identifiant utilisateur (ID), un
pays (PAYS), un nom (NOM) une population et une carte gomtrique. Les objets
VILLES dcrivent les grandes villes de ces rgions et sont positionns sur la carte par
une gomtrie. Les forts (FORETS) ont un identifiant utilisateur, un nom et une gomtrie. Les routes (ROUTES) sont reprsentes comme des relations entre villes origine et extrmit ; elles ont une gomtrie.
Une gomtrie peut tre un ensemble de points reprsents dans le plan, un ensemble
de lignes reprsentes comme une liste de points ou un ensemble de surfaces, chaque
surface tant reprsente comme un ensemble de lignes (en principe fermes). Sur le
type GEOMETRIE, les mthodes Longueur, Surface, Union, Intersection et DRAW
(pour dessiner) sont dfinies.
Question 1
Proposez une dfinition du schma de la base en ODL.
Question 2
Exprimer les questions suivantes en OQL:
Q1. Slectionner les noms, pays, populations et surfaces des rgions de plus de
10 000 km2 et de moins de 50 000 habitants.
Q2. Dessiner les cartes des rgions traverses par la RN7.
Q3. Donnez le nom des rgions, dessiner rgions et forts pour toutes les rgions
traverses par une route dorigine PARIS et dextrmit NICE.
Question 3
Rappelez les oprations dune algbre dobjets complexes permettant dimplmenter
le langage OQL. Donnez les arbres algbriques correspondants aux questions Q1, Q2
et Q3.
Question 1
Proposez un schma UML pour cette base de donnes. On ajoutera les mthodes
appropries pour illustrer. On supprimera tous les pointeurs cachs (cls de jointures)
qui seront remplacs par des associations. Dfinir ce schma directement en SQL3, en
utilisant des rfrences et des collections imbriques.
Exercices 763
Question 2
Exprimer en SQL3 les questions (a), (b), (c) et (d).
Question 3
Comparer limplmentation objet-relationnelle avec une implmentation directe en
relationnel.
Question 4
Reprendre les questions 1, 2 et 3 en utilisant ODL et OQL la place de SQL3.
Comparer les solutions.
Question 1
Dfinir cette base en ODL puis en SQL3.
Question 2
Exprimer les requtes suivantes en OQL puis SQL3 :
Q1 : Nom du pre nol qui vous a visit et prix total des jouets que vous avez reu
Nol (on suppose que vous tes un enfant).
Q2 : Distance parcourue par le pre Nol Georges Gardarin et liste des jouets distribus.
Question 3
Pour chacune des questions prcdentes, proposez un arbre algbrique optimis permettant de lexcuter.
Question 4
Rappelez la dfinition dun index de chemin. Proposez deux index de chemins permettant dacclrer lexcution des questions Q1 et Q2.
Personnes
nss
nom
vhicules
Voitures
date_nais
nveh
* age()
marque
couleur
Question 1
Exprimer en OQL les questions suivantes:
Q1: ensemble des numros de scurit sociale et noms de personnes ges de plus
de 40 ans possdant au moins un vhicule de couleur rouge.
Q2: liste des noms de compagnies employant des personnes de plus de 40 ans possdant une voiture rouge.
Question 2
Donnez un arbre doprations dalgbre dobjets complexes optimis par heuristique
simple permettant dexcuter la question Q2.
Question 3
La jointure de deux classes C1 et C2, telles que Personnes et Voitures relies par une
association oriente multivalue du type A>>C1 peut tre ralise par un algorithme de parcours de pointeurs ou de jointure sur comparaison didentifiant clas-
Exercices 765
sique. Nous les appellerons jointure avant JV (par pointeur) et jointure arrire
JR (par valeur). Dtailler ces deux algorithmes en pseudo-code.
Question 4
On constate que la jointure de N classes relies par des associations peut tre ralise
par un seul oprateur de jointure n-aire, traversant le graphe en profondeur dabord,
appel ici DFF. Dtailler cet algorithme en pseudo-code.
Question 5
En dnotant page(Ci) et objet(Ci) le nombre respectif de pages et dobjets dune
classe Ci, par fan(Ci,Cj) le nombre moyen de pointeurs par objet de Ci vers Cj, en
supposant un placement squentiel sans index des objets, calculez le cot de chacun
des algorithmes JR, JV et DFF. On pourra introduire dautres paramtres si ncessaire.
PRE et MRE sont des cls trangres sur la relation PERSONNE elle-mme, ce
sont donc des numros de personne. Cette relation permet donc de reprsenter un
arbre gnalogique complet.
Question 1
Donnez larbre algbrique correspondant la requte : Quels sont les enfants de M.
Martin, de numro 152487.
Question 2
Donnez larbre algbrique correspondant la requte : Quels sont les petits enfants de
M. Martin, de numro 152487.
Question 3
Donnez larbre algbrique tendu correspondant la requte : Quels sont les descendants de M. Martin, de numro 152487.
Pour cette dernire question on tendra les arbres algbriques de la faon suivante :
Un nud supplmentaire de test permettra de spcifier un branchement conditionnel ;
Question 1
Donnez une expression relationnelle quivalente ce programme pour le calcul des
faits instances des prdicats p1(X,X) et p2(X,Y).
Question 2
Donnez les faits instancis de symbole de prdicat p1 dduits de ce programme et de
la base de donnes.
PARTIE 2
Soit le programme DATALOG :
anc(X,Y) par(X,Y)
anc(X,Y) anc(X,Z), par(Z,Y)
la base de donnes :
par(baptiste,lon), par(lon,lucie), par(janine,lon), par(tienne,clo),
par(lucie,clo), par(baptiste,pierre), par(janine,pierre), par(pierre,bernard),
par(bernard,nicolas), par(bernard,lucien), par(bernard,nomie), par(lucien,ric).
Exercices 767
et la requte :
? anc(bernard,Y)
Question 1
Calculez les rponses cette requte en appliquant la mthode nave. Donnez les faits
dduits chaque itration.
Question 2
Mme question avec la mthode semi-nave.
Question 3
crire le programme modifi obtenu par la mthode des ensembles magiques.
valuez ce programme modifi sur la base, en montrant chaque itration les faits
dduits, et en prcisant pour chaque fait dduit, par quelle rgle il a t dduit.
NSS est le numro de scurit sociale de lemploy, NSER son numro de service et
NCHEF le numro de scurit sociale du chef.
Question 1
crire un programme DATALOG calculant la relation :
DIRIGE(NSSC, NSSD)
donnant quel employ dirige directement ou indirectement quel autre employ (le
numro de scurit sociale NSSC dirige le numro de scurit sociale NSSD), ceci
pour tous les employs.
Question 2
Transformer le programme DATALOG obtenu la question 1 en appliquant la
mthode des ensembles magiques pour trouver les employs dirigs par Toto.
Question 3
Modifier le programme trouv la question 1 pour calculer la relation
DIRIGE(NSSC, NSSD, NIVEAU)
NIVEAU est le niveau hirarchique du chef (1 chef direct, 2 chef du chef direct, etc.).
Dans quel cas ce programme a-t-il un modle infini ?
Question 4
Donnez le graphe Rgle-But et le graphe doprateurs relationnels correspondant la
question ? DIRIGE(Toto, x, 2) pour le programme trouv en 3.
Question 5
crire en DATALOG avec ensemble la question permettant de calculer la table
STATISTIQUE (NSER, CHEF, SALMAX, SALMIN, SALMOY)
donnant pour chaque service, le nom du chef, le salaire maximum, le salaire minimum
et le salaire moyen, ceci pour tous les services dont le salaire minimum dpasse
7 000 F.
Question 1
En utilisant les ensembles magiques, donnez le programme de rgles transformes
permettant de calculer la rponse cette question.
Question 2
Simplifier le programme obtenu par limination des rgles redondantes. Peut-on proposer une mthode gnrale permettant dviter de transformer des rgles
redondantes ?
Exercices 769
Une gomtrie peut tre un ensemble de points reprsents dans le plan, un ensemble
de lignes reprsentes comme une liste de points ou un ensemble de surfaces, chaque
surface tant reprsente comme un ensemble de lignes (en principe fermes). Sur le
type GEOMETRIE, les mthodes LONG, UNION, INTERSECTION et DRAW (pour
dessiner) sont dfinies. LONG est suppose calculer la longueur dune gomtrie en
km.
Question 1
Donnez un programme DATALOG avec fonctions (utiliser en particulier les fonctions
OID et DRAW) permettant de gnrer et tracer tous les parcours allant de la ville de
nom A la ville de nom B en parcourant moins de K km.
Discutez de loptimisation de ce programme.
Question 2
On dsire calculer le cot dun billet de train. Le cot est proportionnel au nombre de
km parcourus. Il existe des billets normaux, des billets rduits, des billets T.G.V., et
des billets T.G.V. rduits. La majoration sur les lignes T.G.V. est un cot de rservation initial plus un cot proportionnel la longueur du trajet. La rduction est un pourcentage du prix appliqu au seul cot proportionnel la distance parcourue. Proposez
une organisation en classes et sous-classes pour les billets de train. Programmer en
pseudo C++ une mthode TARIF qui calcule le prix de chaque billet. On prcise quil
est possible dappeler une mthode dune classe (qui peut tre une super-classe) par la
syntaxe classe::mthode ().
Question 3
Proposez une intgration de la mthode TARIF dans le programme ralis la question 1 afin de calculer le prix de chaque itinraire de moins de x km permettant daller
de A B et de choisir le moins coteux.
:
:
:
:
E2
L2
E5
L6
E3
L4
L1
L2
L5
L1
L3 E4
E3
Question 1
Dessiner le graphe de prcdence. Que peut-on en conclure ?
Question 2
On suppose que les demandes se font dans lordre global suivant :
E2(A) L2(B) L6(D) E5(C) E3(A) L5(A) L1(C) L2(D) L3(C) E4(C) E3(D)
L4(B) L1(B)
Question 3
On rappelle que pour lalgorithme destampillage multiversion, les accs doivent tre
effectus dans lordre des estampilles des transactions, sauf les lectures qui peuvent se
produire en retard. Une lecture en retard obtient la version quelle aurait d lire si elle
tait arrive son tour. Les critures en retard provoquent par contre un abandon de
transaction.
Toujours avec lordre des accs de Q2, que se passe-t-il en estampillage multiversion ?
Question 4
Pour grer le multiversion on suppose que lon dispose dune table en mmoire pouvant
contenir 100 000 versions avec les estampilles correspondantes (pour lensemble des granules). De plus on conserve sur disque la dernire version produite de chaque granule.
On se propose de modifier lalgorithme destampillage multiversion de la faon suivante : chaque nouvelle version dun granule mis jour est crite sur disque tandis
que la version prcdente est recopie dans la table en mmoire. Cette table est gre
comme une file circulaire : chaque nouvelle version entre chasse la version la plus
ancienne (tous granules confondus). Lors dune lecture on recherche dans la table (ou
Exercices 771
sur disque) la version ncessaire si elle est disponible. Une lecture peut donc chouer
et conduire un abandon.
Donnez en pseudo-code les algorithmes LIRE et CRIRE correspondants.
Les actions de base indivisibles pour le contrle de concurrence tudier sont les oprations sur objets, cest--dire + et * sur lexemple.
On considre trois transactions travaillant sur des rels nomms A et B :
T1: { A+1 -> A; B+1 -> B }
T2: { A+2 -> A: B+2 -> B}
T3: { A*3 -> A: B*3 -> B}
Question 1
Donnez un exemple dexcution simultane des transactions T1 et T3 non srialisable.
Tracer le graphe de prcdence associ.
Question 2
Montrer que la commutativit de lopration daddition garantie la correction de toute
excution simultane de T1 et T2.
Question 3
La commutativit des oprations permet donc daccepter des excutions simultanes
non priori srialisable. On se propose de munir chaque classe persistante dun
contrleur de concurrence utilisant une matrice de commutativit des oprations et un
vecteur doprations en cours par transaction.
Dfinir les primitives ncessaires un tel contrle de concurrence.
Prciser les algorithmes sous-jacents.
Question 1
Que fait ce programme ? Prcisez le dbut et la fin de la (des) transaction(s).
Question 2
Que se passe-t-il si on supprime linstruction exec sql commit ?
Question 3
Prcisez les effets du rollback.
Exercices 773
Question 4
On lance plusieurs instances simultanes du programme prcdent. Une transaction ne
peut pas lire (et encore moins modifier) les donnes mises jour par une transaction
non valide. Pourquoi ?
Prcisez les complications des procdures de reprise quimpliqueraient la leve de
cette limitation, cest--dire le non respect de la proprit disolation des mises jour.
Comptes
*
Numro
Ville
IdClient
Avoir
Avoir
*
Caissiers
Comptes
Numro
Numro
Ville
IdClient
Avoir
Avoir
Lobjectif de ltude est dtudier la rsistance aux pannes dans un contexte centralis
puis rparti sur une telle base de donnes implmente en relationnel.
Question 1
Donnez le schma relationnel de la base. crire le code de la transaction dbit/crdit
sous la forme de requtes SQL.
Question 2
Le systme dmarre aprs un point de reprise et excute quatre instances de la transaction dbit/crdit notes T1, T2, T3, T4. T1 crdite 1 000 F sur votre compte avec
succs. T2 tente de crditer 2 000 F mais choue, T3 crdite 3 000 F avec succs et T4
dbite 4 000 F avec succs. Donnez le format du journal (images aprs et avant
comme dans ARIES) aprs excution de ces quatre transactions.
Ce journal est gr en mmoire. Quand est-il crit sur disque ?
Question 3
Le systme tombe en panne aprs validation (commit) de T4. Que se passe-t-il lors de
la procdure de reprise ?
Question 4
Chaque agence bancaire possde un serveur grant sa base de donnes. crire le code
dune transaction sexcutant depuis un client C et effectuant le transfert de m francs
depuis un compte dune agence A sur le compte dune agence B. Prciser les messages changs entre client et serveurs dans le cas dexcution avec succs dune telle
transaction, puis dans le cas o le site A ne rpond plus lors de la premire phase du
commit.
Question 5
Le site client lance la transaction de transfert qui est bien excute sur A et B.
Malheureusement, le site client se bloque juste avant lenvoi de la demande de validation (COMMIT). Prciser ltat du systme (messages changer et journaux). Que se
passe-t-il alors ?
Afin de sortir des situations de blocage, proposez une extension au protocole de validation deux phases en ajoutant une phase et en introduisant un tat intermdiaire
basculant automatiquement en chec de la transaction aprs un dlai dattente.
Question 1
crire la commande permettant de transmettre les droits de lecture et insertion sur la
relation VINS lusager FANTOMAS, en lui garantissant le droit de transmettre ces
droits.
Exercices 775
Question 2
Afin de rendre plus souple lattribution de droits, on introduit la notion de rle.
Prcisez les commandes ncessaires la gestion des rles.
Question 3
Les droits donns aux usagers sont mmoriss dans une relation DROITS. Proposez
un schma pour la relation DROITS.
Question 4
Dcrivez en quelques lignes ou par un organigramme les principes des algorithmes
daccord de droit (GRANT), de suppression de droits (REVOKE) et de vrification dun
droit.
Question 1
Proposez une couverture minimale DF pour DF.
Question 2
Dessiner le graphe des dpendances fonctionnelles.
Question 3
Proposez une dcomposition en troisime forme normale pour R.
PARTIE 2
Soit la liste suivante de donnes lmentaires utilises pour construire une base de
donnes Commandes :
Identifiant unique
Identifiant unique
Doubles possibles
Doubles possibles
Identifiant unique
Doubles possibles
On suppose que lon commence par former une unique relation Commandes avec les
donnes prcdentes pour attributs.
Question 1
Proposez une liste de dpendances fonctionnelles entre ces attributs en respectant les
hypothses.
Question 2
Dessiner le graphe des dpendances fonctionnelles en utilisant des arcs en traits pleins
pour la couverture minimale et des arcs en pointill pour ceux qui peuvent se dduire
par transitivit.
Question 3 :
Proposez une dcomposition en troisime forme normale de la relation.
Exercices 777
On prcise que:
1. Il nexiste pas deux stations de mme nom (NOMS)
2. Une rgion appartient un pays unique.
3. ALTITUDE et HAUTEUR_NEIGE sont dtermins par le nom de station NOMS.
4. Deux pistes de stations diffrentes peuvent avoir le mme nom.
5. Une piste dans une station possde une longueur et une dnivele unique.
6. La position dune bosse la dtermine de manire unique sur une piste donne.
Question 1
En considrant chaque classe, donnez le graphe des dpendances fonctionnelles entre
attributs. Ajouter au graphe des arcs reprsentant les dpendances hirarchiques de 1
vers N reprsents par des arcs tte multiple (du style ->>). Complter ce graphe
par les dpendances interclasses fonctionnelles ou hirarchiques.
Question 2
partir du graphe prcdent, dduire un schma relationnel en 3e forme normale permettant de reprsenter la base de donnes objet initiale.
Question 3
Prciser les contraintes dunicit de cl du schma relationnel. Spcifier ensuite les
contraintes rfrentielles permettant dimposer lexistence dune station pour insrer
une piste puis lexistence dune piste pour insrer une bosse.
Question 4
Proposez un langage de dfinition de contraintes permettant dexprimer les mmes
contraintes dans le monde objet. Illustrez sur la base objet initiale.
Exercices 779
Question 1
Donnez la liste des dpendances fonctionnelles non triviales entre donnes lmentaires sous la forme dun graphe. Sassurer quil ne reste aucune dpendance fonctionnelle qui puisse se dduire des autres par transitivit (les enlever sil en reste).
Question 2
Proposez un schma normalis en 3FN pour la base DGUSTATION partir de
lensemble des dpendances fonctionnelles et laide de lalgorithme vu en cours.
Question 3
Exprimez en SQL les requtes suivantes sur le schma propos :
a) Quels sont les vins de 1991 de la rgion du Pimont (en Italie) qui ont reu au
moins une note suprieure 17 lors de la dgustation du 14/05/1994 ?
b)Quelle est la note moyenne dcerne tous vins confondus par chaque membre
(dgustateur) ?
c) Quels sont les crus qui nont pas reu de note infrieure 15 pour le millsime 1989 ?
d)Quels sont les dgustateurs qui ont particip tous les vnements ?
Question 4
Donnez une expression des requtes a) c) et d) en algbre relationnelle (en utilisant de
prfrence la notation graphique vue en cours).
Question 5
Proposez un schma physique pour le schma relationnel prcdent. On suppose que
lon peut placer en squentiel (avec index primaire non plaant), par des index primaires plaant de type arbre B+ ou par hachage classique. Choisir un mode de placement pour chaque relation en le justifiant.
Question 6
Proposez les index secondaires les mieux mme dacclrer la manipulation de la
base. Indiquer les organisations dindex retenues dans chaque cas et donner les justifications des choix raliss.
TRANSPARENTS
Pour chacun des chapitres, une srie de transparents peut tre obtenue pour lenseignement public en contactant le site Web du laboratoire PRiSM de luniversit de
Versailles :
www.prism.uvsq.fr/~gardarin/home.html
INDEX
A
acteur, 448
action, 269, 591
administrateur, 30
dapplication, 30
dentreprise, 30
de bases de donnes, 30
de donnes, 16, 30
adressage ouvert, 75
adresse relative, 66
affinement du schma logique,
662
agrgat, 210
agrgation 21, 668, 369, 670
composite, 668, 676
indpendante, 668, 675
agrgats auto-maintenables,
295
algorithme
dunification, 169
gntique, 501, 503
amlioration itrative, 343,
497, 498
analyseur
de rgles, 266
de requtes, 43
annotation, 302
annulation de transaction, 619
anomalies de mise jour,680
aplatissage dune collection,
387
apparition dincohrence, 589
appel de mthodes, 572
approche
par synthse, 683
relationnelle tendue, 678
arbre
algbrique, 306
B, 85
B+, 88
de segments, 136
de traitement, 306
de versions dobjet, 642
ET/OU, 548
linaire droit ou gauche,
335
ramifi, 335
relationnel, 207
relationnel, 306
architecture
deux strates, 47
trois strates, 48
BD rpartie, 50
client-serveur, 45
rpartie, 50
article, 60, 61, 113
association, 21, 670
bijective, 673
atome, 113, 523
instanci, 523
atomicit des transactions, 37,
588
attribut multivalu, 676
attribut, 22, 182, 356, 663
attribution de droits, 648
authentification, 644
autorisation, 646
B
balayage squentiel, 326
base cohrente, 254
base de donnes
active, 264, 248
dductive, 154
hirarchique, 137
logique, 154
blocage, 67
permanent, 607
boucles imbriques, 330
C
cache volatile, 621
calcul relationnel
de domaine, 157
de tuples, 166
capture des besoins, 662
cardinalits dassociation, 665
catalogue, 68
de base, 71
hirarchis, 69
certification de transaction,
614
chanage, 75
arrire, 543
avant, 542
champ, 136
classe, 358, 670
de base, 362
drive, 362
gnrique, 367
paramtre, 367
clause, 151
de Horn, 152
cl, 63,136, 185
base de donnes, 122, 123
candidate, 689
darticle, 63
de relation, 689
primaire, 100, 186, 689
prive, 650
publique, 650
secondaire, 100
secrte, 649
clich, 294
cohrence, 588
de contraintes, 254
collection, 367
dpendante, 418
compactage, 67
complment, 200, 201
comptage magique, 570
concatnation darbre, 286,
287
conception du schma
logique, 662
concurrence daccs, 374
condition, 269
de dclencheur, 269
de rgle, 523
conflits de noms, 364
connecteurs logiques, 523
consquence immdiate, 529
constante, 225, 523
de Skolem, 152
constructeur, 448
dobjet, 375
contexte dun vnement,
268
contrainte
dentit, 188
dintgrit, 37, 247
dunicit de cl, 37
de colonnes, 220
de comportement, 250
de domaine, 37, 189, 249
de non nullit, 250
de relations, 220
quationnelle, 251
redondante, 255
rfrentielle, , 37, 187,
249
structurelle, 249
temporelle, 251
contrleur de requtes, 43
coordinateur de validation,
628
corps de rgle, 523
correction des transactions,
38
D
DATALOG, 522
avec double ngation
avec ensemble, 539
avec fonction , 537, 538
avec ngation, 533
dclencheur, 38, 248, 264
dcomposition, 682, 686
prservant
les dpendances, 693
sans perte, 683
dfinition
de classe, 407
de littral , 408
degr disolation, 600
dgroupage, 385, 386, 539
dune collection, 386
dmarche objet, 678
dnormalisation, 705
densit dun index, 83
dpendance
algbrique, 703
dinclusion, 251, 703
de jointure, 702
fonctionnelle lmentaire,
686
fonctionnelle, 250, 684
gnralise, 251
multivalue, 251, 700
multivalue lmentaire,
701
drivation
exclusive, 642
partage, 642
descripteur de fichier, 68
destructeur, 448
dobjet, 375
destruction
dobjets, 572
de valeurs, 572
dtachement, 320
dtection, 601
deuxime forme normale,
691
diagramme
de Bachman, 116
UML, 663
dictionnaire
de rgles, 266
des donnes, 30
diffrence, 191, 387
distribution des objets, 374
division, 199
domaine, 181
de discours, 150
donnes prives, 357
durabilit, 588
E
clatement, 201, 202
criture des clauses, 153
effet
domino, 610
net, 275
laboration
du schma conceptuel,
662
du schma physique, 662
limination
de duplicata, 387
des implications, 152
des quantificateurs, 152
encapsulation des donnes,
439
enregistrement de compensation, 637
ensemble, 367
entit, 21, 663, 672
entrept de donnes, 290,
714
quation au point fixe, 567
qui-jointure, 196
espace des plans, 340
estampille, 604
de transaction, 604
valuateur de conditions, 266
valuation
Bottom-up, 542
top-down, 544
vnement, 265, 267, 268
excuteur
dactions, 266
de plans, 43
Index 785
excution, 592
de transactions, 592
ensembliste, 307, 308
pipline, 308
srialisable, 595
expression
dactions, 535
dattributs, 209
de chemin, 383, 418
de chemin monovalu,
418
de chemins multivalue,
383
de mthodes, 383
fonctionnelle, 383
valuable, 382
extension, 185
de classe, 359, 407
de prdicat, 154
extraction dobjets, 419
F
facilit dinterrogation, 374
facteur de slectivit, 338
fait relevant, 531, 544
fermeture transitive, 204
fiabilit des objets, 374
fichier, 60
grille, 101, 102
hach statique, 73
index, 89
inverse, 100
squentiel index, 91
squentiel index
rgulier, 95
fonction
arguments ensemblistes,
566
de hachage, 74
membres, 357
forme normale
de boyce-codd, 696
de projection-jointure,
703
formule, 149
atomique, 149, 523
de Tang, 494
de Yao, 493
ferme, 151
G
gnralisation, 668, 362
gnration
nave, 556
semi-nave, 558
gestionnaire de fichiers, 4
granule, 67
dallocation, 68
de concurrence, 591
graphe
dhritage, 362
de connexion de
prdicats, 550
de connexion
des attributs, 311
de connexion
des relations, 310
de gnralisation, 362
de groupage, 474
de prcdence, 597
de propagation, 561
de stockage, 476
des allocations, 603
des appels de mthodes,
371
des attentes, 601
des dpendances
fonctionnelles, 686
des jointures, 310
rgle/but, 549
relationnel de rgles, 547,
548
groupage, 385, 474, 539
conjonctif, 475
dune collection, 386
disjonctif, 475
simple, 475
groupe, 113
groupement, 705
groupes dutilisateurs, 645
H
hachage, 73
extensible, 77
linaire, 79
hritage, 362
doprations
et de structures, 439
de table, 442
de type, 442
multiple, 364, 375
simple, 375
hypothse du monde ferm,
154, 532
I
identifiant
dobjet, 355
logique, 470
physique, 470
identification, 644
identit dobjet, 355, 375,
438
image
dune collection, 386
rciproque, 290
incohrence, 590
incorporation dobjet, 473
indpendance
logique, 60
physique, 60
index, 81, 82, 327
bitmap, 104
daires, 98
dintervalles, 97
index de chemin, 471
de chemin imbriqu, 472
de chemin simples, 471
hirarchis, 84
matre, 98
secondaire, 99
inqui-jointure, 196
insertion, 218
dans table dpendante,
262
de valeurs, 572
instance, 15, 185
dobjet, 15
intention, 184
interface dobjet, 357
interprtation dun langage
logique, 153
intersection, 198, 387
isolation des transactions, 38,
588
J
jointure, 195
de collections, 387
externe, 202
naturelle, 196
par rfrence, 388
par valeur, 388
-projection, 320
journal des images
aprs, 622
avant, 622
journalisation
avant criture, 624, 637
de valeur et dopration,
635
L
label, 68
de volume, 68
langage
complet, 33, 206
de description de donnes
(LDD), 16
de rgles, 518
DEL, 573
hte, 61
ROL, 571
liaison, 473
dobjet, 473
dynamique, 367
lien, 115
liste, 367
littral positif, 523
M
manipulation de collections,
465
matrice dautorisations, 647
mmoire
un seul niveau, 382
secondaire, 57
stable, 620, 621
volatile, 623
message, 370
dexception, 375
mta-rgles, 535
mtabase, 31, 43
mthode, 357
daccs, 61
daccs slective, 63
daccs squentielle, 62
de dtection, 258, 259
de prvention, 259
de rsolution, 171
interprte, 564
virtuelle, 366
mise jour de colonne rfrenante, 262
mise en forme
normale conjonctive, 153
prenex, 152
mode
dexcution, 276
de couplage, 276
de synchronisation, 276
modle
analytique, 704
dactivits, 641
de description
de donnes, 16
de transaction volu,
374
ferm, 640
ouvert, 640
relationnel imbriqu, 439
simul, 704
modification, 218
de question, 286
de requte, 43
module, 236
modus ponens, 169
moniteur dvnements, 266
mot de passe, 644
moteur de rgles, 266
moyennage de cot, 494
multi-ensemble, 367
multi-index, 472
multiclasse, 361
mutateur, 448
mutation, 502
de pointeurs, 380
N
navigation entre objets, 380
ngation par chec, 528, 532
niveau dautorisation, 648
O
objet, 354, 355, 644
versions, 374
long, 438
persistant, 374
transient, 374
versionnable, 374
observateur, 448
occurence, 15
ODL, 403
ODMG, 401
ODMG 2.0, 403
OML, 403
ontologie, 671
oprateur
de slection, 320
monotone, 532
opration, 35, 593, 644
compatible, 595
permutable, 594
prive, 358
optimisation
deux phases, 497
logique, 302
physique, 302
optimiseur
de requtes, 43
extensible, 481
ferm, 341
OQL, 403
ordonnancement par estampille, 613
organisation de fichier, 61
P
page, 66
panne
catastrophique, 634
dune action, 617
dune transaction, 617
de mmoire secondaire,
618
du systme, 618
paquetages, 669
Index 787
Q
qualification, 32
de chemin, 140
de question, 32
quatrime forme normale,
700
question
contradictoire, 312
correcte, 312
irrductible, 322
mal formule, 312
questions quivalentes, 312
R
recherche, 218
taboue, 497, 500
recuit simul, 497, 499
redfinition, 366
rduction de la porte des
ngations, 152
rcriture, 308
smantique, 310
syntaxique, 310
S
sac, 367
sagas, 640
sauvegarde, 625
schma
conceptuel, 17, 20
de BD objet, 371
de classes, 371
de donnes, 16
de relation, 184
externe, 18, 20
interne, 18, 20
segment, 136
slecteur de proprit, 371
slection, 388
dobjets, 386
smantique
bien fonde, 537
de la preuve, 527
des oprations, 611
du modle, 528
du point fixe, 530
inflationiste, 537
semi-jointure, 203, 322
srialisabilit, 595
SGBD
actif, 264
dductif, 521
externe, 5
interne, 4
signature, 563
simultanit inter-usagers,
63, 64
sous-but, 523
sous-classe, 362
sous-schma, 127
spcialisation , 169, 362, 668,
674
SQL2
complet, 238
entre, 238
intermdiaire, 238
stratgie
alatoire, 343
de recherche, 340
des frres siamois, 72
du meilleur choix, 72
du plus proche choix, 72
du premier trouv, 72
numrative, 343
exhaustive, 343
gntique, 343
T
table
des pages sales, 636
des transactions, 636
support, 479
tableau, 367
de disques, 59
technique
de mmoire virtuelle, 381
des pages ombre, 627
terme, 149, 225, 523
test diffrentiel, 257
trane dune transaction ,
610
transaction, 586, 588
de compensation, 640
de complment, 640
multi-niveaux, 642
transactions imbriques, 639
transformation de donnes,
35
traverse
de chemin, 465
en largeur dabord, 479
en profondeur dabord,
478
tri externe, 329
troisime forme normale, 691
tuple, 183
tuple, 308
type
dobjet, 15
de donnes abstrait, 358,
441
de donnes utilisateur,
441
U
UML 668
UML/OR, 678
UML/RO, 678
unicit de cl, 249
unification, 169
union, 190, 387
unit duvre, 618
usine objets, 359
utilisation de doubles pointeurs, 381
V
valeur nulle, 188
validation aprs criture, 624,
637
validation bloque, 624
validation de transaction, 619
variable, 523
dinstance, 356
vecteur, 113
verrou
court, 600
long, 600
mortel, 600
verrouillage
altruiste, 610
deux phases, 598
multi-versions, 610
version dobjet, 374
volume, 58
vue, 25, 281, 283
auto-maintenable, 292
concrte, 291
mettable jour, 288