You are on page 1of 121

i

BASES DE DONNES
CONCEPTS ET PROGRAMMATION
Antoine Cornujols
AgroParisTech, Spcialit Informatique (2009-2010)
Version du 19 octobre 2009
ii
Table des mati` eres
Table des matires iii
1 Concepts fondamentaux 1
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Un vieux problme : la bibliothque de Leibniz . . . . . . . . . . . . . . . . . . . . 2
1.2 Donnes, bases de donnes et SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Un exemple : BD sur lINA-PG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Quelles comptences pour utiliser un SGBD? . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Dnition du schma de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Les oprations sur les donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Concurrence daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Caractristiques de lapproche base de donnes . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Architecture des SGBD et indpendance des donnes . . . . . . . . . . . . . . . . . 5
3.2 Persistance des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Langage de requte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Partage des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Fiabilit des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6 Scurit des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Pourquoi une Base de Donnes ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 O trouve-ton des BD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Applications rcentes et venir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4 Avantages lis lutilisation dun SGBD . . . . . . . . . . . . . . . . . . . . . . . . 6
4.5 Les acteurs en jeu dans lusage de SGBD . . . . . . . . . . . . . . . . . . . . . . . 6
4.6 Historique des SGBD et types de SGBD . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Objectifs du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Modle abstrait des bases de donnes 9
1 Introduction : modlisation des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Gnralits sur la conception dune Base de Donnes . . . . . . . . . . . . . . . . . 9
1.2 Problmes dune conception sans prcautions . . . . . . . . . . . . . . . . . . . . . 10
1.3 Introduction une bonne mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Le modle entit-association (E/A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Prsentation informelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Le modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Avantages et inconvnients du modle E/A . . . . . . . . . . . . . . . . . . . . . . 13
3 Langages de bases de donnes 15
1 Le modle relationnel et ses rgles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Un peu dhistoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Les notions de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Bases thoriques des langages relationnels : lalgbre relationnelle . . . . . . . . . . . . . . 18
iv Table des matires
2.1 Une manipulation ensembliste des donnes . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Les oprateurs de lalgbre relationnelle . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Expressions de requtes avec lalgbre . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Bien concevoir une base de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Les dpendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Dcomposition en formes normales . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Les contraintes dintgrit structurelles . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Passage dun schma E/A un schma relationnel . . . . . . . . . . . . . . . . . . 31
4 Le langage relationnel SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Les langages relationnels complets . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Le langage SQL : historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Le DML : Data Manipulation Language en SQL . . . . . . . . . . . . . . . . . . . 33
4.4 Le DDL (Data Description Language) en SQL . . . . . . . . . . . . . . . . . . . . 48
4 Pratique des SGBD 53
1 Exemples de SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.1 Perspectives historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.2 ORACLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.3 Microsoft Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2 Techniques doptimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3 Techniques daccs partags : le contrle de concurrence . . . . . . . . . . . . . . . . . . . 54
3.1 Problmes potentiels et notions de base . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2 Techniques de contrle de concurrence . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3 La gestion des transactions en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4 Le contrle de concurrence sous Oracle . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 Techniques de rcupration derreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1 Les mcanismes utiliss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Les bancs de mesure des performances ("benchmarks") . . . . . . . . . . . . . . . . . . . . 71
6 Scurit et autorisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7 Linterface C/SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1 Un exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2 Autres commandes SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8 Les environnements de programmation dapplications sur les bases de donnes . . . . . . . 79
8.1 La "programmation visuelle" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2 Langages de quatrime gnration . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.3 Les interfaces au standard SQL et la portabilit . . . . . . . . . . . . . . . . . . . . 80
8.4 Les ateliers de gnie logiciel (AGL / CASE) . . . . . . . . . . . . . . . . . . . . . . 81
5 Ralisation physique des bases de donnes 83
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2 Techniques de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.1 Stockage de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.2 Organisation des chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.3 Organisation primaire des chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.4 Lexemple du SGBD Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3 Structures de donnes pour optimiser les accs . . . . . . . . . . . . . . . . . . . . . . . . 87
3.1 Indexation de chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.2 Hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.3 Larbre-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4 Autres mthodes dindexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.6 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.7 Quelques rgles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.8 Indexation dans Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.9 Index en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.10 Structures de donnes multidimensionnelles . . . . . . . . . . . . . . . . . . . . . . 105
4 valuation des requtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.1 Introduction loptimisation des performances . . . . . . . . . . . . . . . . . . . . 105
Table des matires v
4.2 Algorithmes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.3 Algorithmes de jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.4 Compilation dune requte et optimisation . . . . . . . . . . . . . . . . . . . . . . . 106
4.5 Oracle : optimisation et valuation des requtes . . . . . . . . . . . . . . . . . . . . 106
5 Vision globale sur lexcution dune requte SQL . . . . . . . . . . . . . . . . . . . . . . . 106
6 Optimisation de laccs une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6 Perspectives des SGBD 107
1 Nouveaux modles de donnes pour nouvelles applications . . . . . . . . . . . . . . . . . . 107
2 Bases de donnes rparties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.2 Fragmentation dune BD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.3 Les problmes spciques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.4 Transaction rpartie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3 Bases de donnes dductives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4 Entrepts de donnes et fouille de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.1 Perspectives historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Bibliographie 111
Index 113
vi Table des matires
Chapitre 1
Concepts fondamentaux
Sommaire
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Un vieux problme : la bibliothque de Leibniz . . . . . . . . . . . . . . . . . . 2
1.2 Donnes, bases de donnes et SGBD . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Un exemple : BD sur lINA-PG . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Quelles comptences pour utiliser un SGBD? . . . . . . . . . . . . . . . . . 3
2.1 Dnition du schma de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Les oprations sur les donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Concurrence daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Caractristiques de lapproche base de donnes . . . . . . . . . . . . . . . . 5
3.1 Architecture des SGBD et indpendance des donnes . . . . . . . . . . . . . . . 5
3.2 Persistance des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Langage de requte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Partage des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Fiabilit des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6 Scurit des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Pourquoi une Base de Donnes ? . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 O trouve-ton des BD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Applications rcentes et venir . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4 Avantages lis lutilisation dun SGBD . . . . . . . . . . . . . . . . . . . . . . 6
4.5 Les acteurs en jeu dans lusage de SGBD . . . . . . . . . . . . . . . . . . . . . 6
4.6 Historique des SGBD et types de SGBD . . . . . . . . . . . . . . . . . . . . . . 6
5 Objectifs du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 1 Introduction
1. Introduction
1.1 Un vieux problme : la bibliothque de Leibniz
1.2 Donnes, bases de donnes et SGBD
Une donne est une information quelconque, comme, par exemple, voici une personne, elle sappelle
Antoine . Cest aussi une relation entre des informations. Par exemple : Antoine enseigne les bases
de donnes . Des relations de ce genre dnissent des structures.
Une base de donnes est un ensemble, en gnral volumineux, de telles informations, avec la caractristique
essentielle que lon cherche les mmoriser de manire permanente.
Dnition 1.1 (Base de donnes)
Une base de donnes est un gros ensemble dinformations structures mmorises sur un support per-
manent qui peut tre partage par plusieurs applications et qui est interrrogeable par le contenu.
Lutilisation de chiers classiques pourrait sembler pouvoir apporter une solution ce problme. Mais
lutilisation directe de gros chiers soulve de gros problmes :
Lourdeur daccs aux donnes. En pratique, pour chaque accs aux donnes, mme le plus simple, il
faudrait crire un programme.
Manque de scurit. Si tout programmeur peut accder directement aux chiers, il est impossible de
garantir la scurit et lintgrit des donnes.
Pas de contrle de concurrence. Dans un environnement dans lequel plusieurs utilisateurs accdent aux
mmes donnes, des problmes de concurrence daccs se posent.
Il est donc ncessaire davoir recours un logiciel charg de grer les chiers constituant une base de
donnes, de prendre en charge les fonctionnalits de protection et de scurit et de fournir les dirents
types dinterfaces ncessaires laccs aux donnes. Ce logiciel (le SGDB) est trs complexe.
Dnition 1.2 (Systme de Gestion de Bases de Donnes (SGBD))
Un Systme de Gestion de Bases de Donnes (SGBD) est un logiciel de haut niveau permettant aux
utilisateurs de structurer, dinsrer, de modier, de rechercher de manire ecace des donnes spciques,
au sein dune grande quantit dinformations, stockes sur mmoires secondaires partage de manire
transparente par plusieurs utilisateurs.
Plus prcisment, les systmes de gestion de bases de donnes (SGBD) sont des programmes
permettant lutilsateur de crer et de grer des bases de donnes. les SGBD sont des logiciels usage
gnral qui assurent les processus de dnition, de construction, de manipulation et de partage des bases
de donnes par et entre les dirents utilisateurs et applications.
La dnition dune base de donnes implique une spcication des types de donnes, des structures et des
contraintes. La construction dune base de donnes consiste enregistrer les donnes proprement dites
sur un support de stockage contrl par le SGBD. La manipulation de la base consiste notamment
linterroger an den extraire des informations, lactualiser en fonction des modications du microcosme
considr et gnrer des rapports. Le partage dune base de donnes permet dirents utilsateurs et
applications dy accder simultanment.
Les SGBD assurent dautres fonctions importantes, notamment la protection de la base de donnes et son
/em entretien long terme. La protection implique la fois la protection du systme contre les pannes
logicielles et matrielles et la protection scuritaire conre les accs illicites ou malveillants. Une grande
base de donnes peut tre utilises de nombreuses annes. Le SGBD doit donc tre capable dentretenir
et de faire voluer ses propres structures dans la dure.
La complexit dun SGBD tient essentiellement la diversit des techniques mises en uvre, la multi-
plicit des composants intervenant dans son architecture, et aux dirents types dutilisateurs (adminis-
Chapitre 1 Concepts fondamentaux 3
trateurs, programmeurs, utilisateurs non informaticiens, ...) qui sont confronts, dirents niveaux, au
systme.
Ainsi, dans ce cours, seront abords :
Les modles de donnes : entit-relation (mais pas les modles en rseaux, hirarchiques, relationnels,
orients objets, smantiques).
Les langage de requte, incluant leurs fondements thoriques et les langages comme SQL.
Les techniques de stockage.
Lorganisation des chiers : index, arbre-B, hachage, ...
Larchitecture : centralise, distribue, sur dautres bases accessibles par rseau.
Les techniques dvaluation et doptimisation de requtes.
La concurrence daccs et les techniques de reprise sur panne.
Ces fonctions sont remplies par trois niveaux, thoriquement distincts, dun SGBD :
1. Le niveau physique : gestion sur mmoire secondaire (chiers) des donnes, du schma, des index ;
Partage de donnes et gestion de la concurrence daccs ; reprise sur pannes (abilit) ; Distribution
des donnes et interoprabilit (accs aux rseaux).
2. Le niveau logique : Dnition de la structure des donnes : Langage de Description des Don-
nes (LDD) ; Consultation et Mise Jour des donnes : Langage de Requte (LR) et Langage de
Manipulation de Donnes (LMD) ; Gestion de la condentialit (scurit) ; Maintien de lintgrit.
3. Le niveau externe : Vues ; Environnement de programmation (intgration avec un langage de
programmation) ; Interfaces conviviales et Langage de 4me Gnration (L4G) ; Outils daides (e.g.
conception de schmas) ; Outils de saisie, dimpression dtats.
En rsum, un SGBD est destin grer un gros volume dinformations, persistantes, ables (protection
sur pannes), partageables entre plusieurs utilisateurs et/ou programmes manipuls indpendamment de
leur reprsentation physique.
Nous avons introduit un certain nombre de termes et de sigles. Nous allons progressivement en apprendre
le sens.
1.3 Un exemple : BD sur lINA-PG
Quest-ce quon veut faire ?
Quelles donnes sont utiles ?
Quels types de requtes ?
Quelles mises jour ?
Quels acteurs ?
Concurrence
Redondance et incohrence
Quelle scurit ?
1.3.1 Questions essentielles
Comment concevoir une BD?
Comment optimiser sa conception ?
Comment optimiser son fonctionnement ?
Comment assurer la concurrence ?
Comment assurer la scurit ?
2. Quelles comptences pour utiliser un SGBD?
Lutilisation dun SGBD suppose de comprendre et de savoir utiliser les fonctionnalits suivantes :
1. Dnition du schma de donnes en utilisant les modles de donnes du SGBD.
4 2 Quelles comptences pour utiliser un SGBD?
2. Oprations sur les donnes : recherches, mises--jour, etc.
3. Partager les donnes entre plusieurs utilisateurs (mcanismes de transaction).
4. Optimiser les performances par le rglage de lorganisation physique des donnes. cet aspect relve
plutt de ladministrateur de donnes.
En reprenant ces dirents points.
2.1 Dnition du schma de donnes
Un schma est simplement la description des donnes contenues dans la base. Cette description est
conforme un modle de donnes qui propose des outils de description (structures, contraintes et op-
rations). Dans un SGBD, il existe plusieurs modles plus ou moins abstraits des mmes objets. Par
exemple :
Le modle conceptuel : la description du systme dinformation
Le modle logique : rglant linterface avec le SGBD
Le modle physique : les chiers.
Ces dirents modles correspondent aux niveaux de larchitecture dun SGBD. Prenons lexemple du
modle conceptuel le plus courant : le modle Entit/Association. Cest essentiellement une description
trs abstraite dcrivant :
lanalyse du monde rel telle que pertinente pour lutilisation
la conception du systme dinformation
la communication entre dirents acteurs de lentreprise.
En revanche, il ne propose pas doprations. Or dnir des structures sans disposer doprations pour
agir sur les donnes stockes dans ces structures ne prsente pas dintrt pratique pour un SGBD. Do,
un niveau infrieur, des modles dits logiques qui proposent :
1. Un langage de dnition de donnes (LDD) pour dcrire la structure, incluant les contraintes.
2. Un langage de manipulation de donnes (LMD) pour appliquer des oprations aux donnes.
Ces langages sont abstraits. le LDD est indpendant de la reprsentation physique des donnes, et le LMD
est indpendant de limplantation des oprations. On peut citer une troisime caractristique : outre les
structures et les oprations, un modle logique doit permetre dexprimer des contraintes dintgrit sur
les donnes.
Exemple
nom character 15, not null ;
ge integer between 0 and 120 ;
dbit = crdit ;
...
Bien entendu, le SGBD doit tre capable de garantir le respect de ces contraintes.
Quand on conoit une application pour une BD, on tient compte de cette architecture en plusieurs niveaux.
Typiquement : (1) on dcide la structure logique, (2) on dcide la structure physique, (3) on crit les
programmes dapplication en utilisant la structure logique, enn (4 le SGBD se charge de transcrire les
commandes du LMD en instructions appliques la reprsentation physique.
Cette approche ore de trs grands avantages. Tout dabord elle ouvre lutilisation des SGBD des
utilisateurs non-experts : les langages proposs par les modles logiques sont plus simples, et donc plus
accessibles, que les outils de gestion de chiers. Ensuite, on obtient une caractristique essentielle : lind-
pendance physique. On peut modier limplantation physique sans modier les programmes dapplication.
Un concept voisin est celui dindpendance logique : on peut modier les programmes dapplication sans
toucher limplantation.
Enn le SGBD dcharge lutilisateur, et en grande partie ladministrateur, de la lourde tche de contrler
la scurit et lintgrit des donnes.
2.2 Les oprations sur les donnes
Il existe 4 oprations classiques (ou requtes :
Chapitre 1 Concepts fondamentaux 5
1. La cration (ou insertion)
2. La modication (ou mise--jour)
3. La destruction
4. La recherche
Ces oprations correspondent des commandes du LMD. La plus complexe est la recherche en raison de
la varit des critres.
Pour lutilisateur, une bonne requte a les caractristiques suivantes. Tout dabord, elle sexprime fa-
cilement : lidal serait de pouvoir utiliser le langage naturel, mais celui-ci prsente trop dambiguts.
Ensuite, le langage ne devrait pas demander dexpertise technique (syntaxe complique, structure de
donnes, implantation particulire ...). Il est galement souhaitable de ne pas attendre trop longtemps (
charge pour le SGBD de fournir des performances acceptables). Enn, et peut-tre surtout, la rponse
doit tre able.
Une bonne partie du travail sur les SGBD consiste satisfaire ces besoins. le rsultat est ce que lon appelle
un langage de requtes, et constitue la fois un sujet majeur dtude et une caractristique essentielle de
chaque SGBD. le langage le plus rpandu lheure actuelle est SQL.
2.3 Optimisation
Loptimisation (dune requte) sappuie sur lorganisation physique des donnes. les principaux types
dorganisation sont les chiers squentiels, les index (denses, secondaires, arbres B) et le regroupement
des donnes par hachage.
Un module particulier du SGBD, loptimiseur, tient compte de cette organisation et des caractristiques
de la requte pour choisir le meilleur squencement des oprations.
2.4 Concurrence daccs
Plusieurs utilisateurs doivent pouvoir accder en mme temps aux mmes donnes. Le SGBD doit savoir :
Grer les conits si ces utilisateurs font simultanment des mises--jour.
Orir un mcanisme de retour arrire si on dcide dannuler des modications en cours.
Donner une image cohrente des donnes sur lun fait des requtes et un autre des mises--jour.
Le but est dviter des blocages tout en empchant des modications anarchiques.
3. Caractristiques de lapproche base de donnes
Abstraction des donnes : requtes en termes presque en langage naturel
Notion de vues
3.1 Architecture des SGBD et indpendance des donnes
Architecture en trois schmas
6 4 Le contexte
3.2 Persistance des donnes
3.3 Langage de requte
3.4 Partage des donnes
3.5 Fiabilit des donnes
3.6 Scurit des donnes
4. Le contexte
4.1 Pourquoi une Base de Donnes ?
Intgration de donnes
Moins de duplications
Partage de donnes
Fiabilit de donnes
Transactions, Reprises sur pannes, Tolrance de pannes
Scurit de donnes
Langages assertionnels de requtes
SQL, QBE
Interfaces conviviales
4-GL & Web
4.2 O trouve-ton des BD
4.2.1 Types de BDs
BDs personnelles
MsAccess etc.
10 KO 100 KO
BDs professionnelles typiques 100 KO 100 GO
BDs professionnelles trs grandes
Very Large Databases (VLDB)
> 100 GO
4.3 Applications rcentes et venir
4.4 Avantages lis lutilisation dun SGBD
4.5 Les acteurs en jeu dans lusage de SGBD
4.6 Historique des SGBD et types de SGBD
4.6.1 Historique
Moteur : volution des modles de donnes, elle-mme motive par lvolution des besoins.
1re gnration 1950 65
SGF, SGF gnraliss avec les langages boolens de manip.
2me gnration 1965 - 70
SGBD navigationnel
Hierarchique (IMS), Rseau (Codasyl), Pseudo-relationnel
3me gnration 1969 - . . .
Chapitre 1 Concepts fondamentaux 7
SGBD relationnel (DB2, Oracle, Informix, MsAcess. . .
SGBD OO 1990 - 1999
En pratique : une impasse (O2, Objectstore, Objectivity..)
SGBD relationnel objet (RO) 1993 - . . .
volution probable de tout SGBD relationnel
Il faut donc distinguer entre modles conceptuels, /em a priori indpendants des SGBD, et /em modles
logiques, caractristiques dune gnration de SGBD. Ces modles logiques sont eux-mmes dpendants
dorganisations physiques (placement et mthodes daccs) comme, par exemple, les graphes en arbres
ou en rseaux, seules structures oertes par la premire gnration de SGBD, celle des modles naviga-
tionnels, hirarchique et rseau.
Ces SGBD obligeaient "voir" - cest dire traduire - une base de donnes comme un ensemble
denregistrements, relis les uns aux autres par des ensembles de pointeurs. Cette organisation ge les
relations existant entre les dirents enregistrements de la base et impose un type de manipulation, la
navigation, qui consiste suivre, denregistrement en enregistrement, les chanes de pointeurs. En fait, il
serait prfrable de parler de modles daccs (physiques) plutt que de modles de donnes (logiques)
pour ces anciens SGBD. En eet leur organisation physique des donnes imposait la mthode daccs et,
au del, la nature des langages de manipulation.
4.6.2 Le modle hirarchique
Longtemps considr comme le seul modle permettant aux SGBD datteindre les performances exiges
en production, le modle hirarchique possde eectivement la capacit de traiter rapidement des in-
formations organises sous la forme dune hirarchie stricte mais, par contre, interdit tout autre type
de reprsentation, limitant ainsi considrablement la puissance dexpression du modle. Le SGBD le
plus connu dans cette catgorie est IMS, produit ancien de IBM, trs rpandu dans les applications de
production.
4.6.3 Le modle rseau
Ce modle a t introduit en 1961 par BACHMAN. Il propose une utilisation de structures de listes an de
relier smantiquement des entits. Il permet ainsi une meilleure reprsentation de la ralit que le modle
hierarchique. Un des intrts du modle fut lexistence dune proposition de normalisation mise par le
groupe DBTG (Data Base Task Group) du Comit CODASYL (COnference on DAta SYstem Language).
On parle ainsi souvent de modle CODASYL pour les systmes rseaux qui suivent ces recommandations.
Deux niveaux de recommandations ont t mis : lun, en 1971, conseillait la sparation dun niveau
de schma externe et dun niveau de schma interne/conceptuel ; le second, en 1978, prconisait les
trois niveaux de schma -interne, conceptuel, externe-. Seul le premier niveau de recommandations a t
rellement suivi par les produits. En 1978, il tait dj tard pour voir les produits prendre en compte
ces recommandations : lheure du relationnel avait dj sonn pour les investissements long terme ;
quasiment aucun SGBD rseau rellement nouveau na t conu depuis cette date. Mais lheure o les
SGBD relationnels sont leur tour ds par les nouveaux SGBD orients objets, il est encore intressant
de comprendre ce que les SGBD rseau avaient apport de plus novateur : lexpression des requtes sur les
donnes dans une logique de chemin (c..d. de navigation ). Parmi les SGBD construits selon ce modle,
encore largement utiliss, on peut citer IDS2 chez BULL, IDMS de CULLINET, TOTAL de CINCOM,
SOCRATE.
8 5 Objectifs du cours
5. Objectifs du cours
5.0.4 Que doit-on savoir pour utiliser un SGBD
5.0.5 Dnition du schma de donnes
5.0.6 Oprations sur les donnes
5.0.7 Optimisation
5.0.8 Concurrence daccs
5.0.9 Fonctionnement dun SGBD
5.0.10 Plan du cours
Chapitre 2
Mod` ele abstrait des bases de donn ees
Sommaire
1 Introduction : modlisation des donnes . . . . . . . . . . . . . . . . . . . . . 9
1.1 Gnralits sur la conception dune Base de Donnes . . . . . . . . . . . . . . . 9
1.2 Problmes dune conception sans prcautions . . . . . . . . . . . . . . . . . . . 10
1.3 Introduction une bonne mthode . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Le modle entit-association (E/A) . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Prsentation informelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Le modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Avantages et inconvnients du modle E/A . . . . . . . . . . . . . . . . . . . . 13
1. Introduction : modlisation des donnes
Ce chapitre prsente le modle Entit/Association (E/A) qui est utilis peu prs universellement pour
la conception de bases de donnes (relationnelles principalement). La conception dun schma correct est
essentielle pour le dveloppement dune application viable. Dans la mesure o la base de donnes est
le fondement de tout le systme, une erreur pendant sa conception est dicilement rcuprable par la
suite. Le modle E/A a pour caractristiques dtre simple et susamment puissant pour reprsenter des
structures relationnelles. Surtout, il repose sur une reprsentation graphique qui facilite considrablement
sa comprhension. En revanche, il admet certaines ambiguts.
La prsentation qui suit est dlibrement axe sur lutilit du modle E/A dans le cadre de la conception
dune base de donnes. Ajoutons quil ne sagit pas de concevoir un schma E/A (voir un cours sur les
systmes dinformation), mais dtre capable de le comprendre et de linterprter.
1.1 Gnralits sur la conception dune Base de Donnes
La ralisation dune Base de Donnes implique trois grandes tapes (voir gure ??) :
1. La dnition dun cahier des charges
2. La modlisation
3. Limplantation physique dans un systme informatique.
10 1 Introduction : modlisation des donnes
{
{
{
Cahier des
charges
Modlisation
Implantation
Fig. 2.1: Grandes tapes de la conception dune base de donnes.
Nous allons nous intresser ici la deuxime tape.
Dnition 2.1 (Modle des donnes)
Un modle des donnes ( data model ) est une description formelle et structure des donnes et de
leurs relations dans un systme dinformation.
Pour obtenir un modle des donnes, il faut trois grandes phases :
1. Modlisation / analyse des donnes
2. Construction dun modle entit-association
3. Conversion en un schma de base de donnes relationnelles.
Nous nous concentrons dans la suite sur la deuxime phases.
La mthode de conception permet de distinguer les entits qui constituent la base de donnes, et les
associations entre ces entits. Ces concepts permettent de donner une structure la base, ce qui savre
indispensable. Nous commenons par montrer les problmes qui surviennent si on traite une base rela-
tionnelle comme un simple chier texte, sans se soucier de lui donner une structure correcte.
1.2 Problmes dune conception sans prcautions
Les redondances (duplications) prsentes dans la table faite sans prcaution peut conduire plusieurs
types de problmes :
Erreurs possibles lors de linsertion
Erreurs possibles lors de la mise--jour
Chapitre 2 Modle abstrait des bases de donnes 11
Titre Anne nomMES PrnomMES AnneNaiss
Alien 1979 Scott Ridley 1943
Vertigo 1958 Hitchcock Alfred 1899
Psychose 1960 Hitchcock Alfred 1899
Kagemusha 1980 Kurosawa Akira 1910
Volte-face 1997 Woo John 1946
Pulp Fiction 1995 Tarantino Quentin 1963
Titanic 1997 Cameron James 1954
Sacrifice 1986 Taskovski Andrei 1932
Fig. 2.2: Une table de lms.
Si lon modie lanne de naissance dHitchcock pour Vertigo ...
Si destruction dun lm, on risque de supprimer le metteur en scne
1.3 Introduction une bonne mthode
Une bonne mthode vitant les anomalies ci-dessus consiste :
1. tre capable de reprsenter individuellement les lms et les ralisateurs, de manire ce quune
action sur lun nentrane pas systmatiquement une action sur lautre ;
2. dnir une mthode didentication dun lm ou dun ralisateur, qui permette dassurer que la
mme information est reprsente une seule fois ;
3. prserver le lien entre les lms et les ralisateurs, mais sans introduire de redondance.
Exemple Amlioration de la base de lms
A FAIRE
Ce gain dans la qualit du schma na pas pour contrepartie une perte dinformation. Il est en eet facile de
voir que linformation initiale (autrement dit, avant dcomposition) peut tre reconstitue intgralement.
En prenant un lm, on obtient lidentit de son metteur en scne, et cette identit permet de trouver
lunique ligne dans la table des ralisateurs qui contient toutes les informations sur ce metteur en scne.
Ce processus de reconstruction de linformation, disperse dans plusieurs tables, peut sexprimer avec
SQL.
La modlisation avec un graphique Entit/Association ore une mthode simple pour arriver au rsultat
ci-dessus, et ce mme dans des cas beaucoup plus complexes
2. Le modle entit-association (E/A)
Un schma E/A dcrit lapplication vise, cest--dire une abstraction dun domaine dtude, pertinente
relativement aux objectifs viss. Rappelons quune abstraction consiste choisir certains aspects de la
ralit perue (et donc liminer les autres). Cette slection se fait en fonction de certains besoins qui
doivent tre prcisment dnis.
Exemple Schma E/A pour la base de lms
A FAIRE
Voir gure 2.3.
12 2 Le modle entit-association (E/A)
Titre Anne idMES
Alien 1979 1
Vertigo 1958 2
Psychose 1960 3
Kagemusha 1980 4
Volte-face 1997 5
Pulp Fiction 1995 6
Titanic 1997 7
Sacrifice 1986 8
Id nomMES PrnomMES AnneNaiss
1 Scott Ridley 1943
2 Hitchcock Alfred 1899
3 Hitchcock Alfred 1899
4 Kurosawa Akira 1910
5 Woo John 1946
6 Tarantino Quentin 1963
7 Cameron James 1954
8 Taskovski Andrei 1932
Fig. 2.3: Table des lms et table des ralisateurs.
2.1 Prsentation informelle
Une entit est un objet concret ou abstrait
ayant une existence propre
fonction des besoins de modlisation
Exemple : Assur, Film, Contrat
Une association est un lien smantique entre entits
fonction des besoins de modlisation
Exemple : Raliser entre ralisateur et film.
Une proprit est une donne lmentaire :
ayant un sens
pouvant tre utilise de manire autonome
Ex : NomAssur, AnneSouscription, NbContrats
Servent dcrire les entits et les associations
= Attributs ou colonnes
prennent des valeurs appeles occurrences de la proprit
La modlisation conceptuelle est totalement indpendante de tout choix dimplantation. Cest la partie la
plus stable dune application. Elle vise se concentrer sur lessentiel : Que veut-on stocker dans la base ?
Le modle E/A a t conu en 1976 et est la base de la plupart des mthodes de conception. La syntaxe
est souvent celle dUML En France, on utilise parfois la syntaxe MERISE (quasi quivalente)
Les types dentits
Un type dentit est compos de :
son nom
la liste de ses attributs avec, optionnellement le domaine dans lequel lattribut prend ses valeurs :
les entiers, les chanes de caractres :
lindication du (ou des) attribut(s) premettant didentier lentit : ils constituent la cl.
Une entit e est une instance de son type E.
Un ensemble dentits e
1
, e
2
, ..., e
n
instances dun mme type E est une extension de E.
Dnition 2.2 (Cl)
Soit E un type dentit et A lensemble des attributs de E. Une cl de E est un sous-ensemble minimal
de A permettant didentier de manire unique une entit parmi nimporte quelle extension de E.
Exemple Les cls
Soit le type Internaute avec les attributs :
email
nom
prnom
Chapitre 2 Modle abstrait des bases de donnes 13
rgion
email peut tre une cl naturelle car cest un attrinut unique et discriminant pour chaque internaute.
nom ne peut pas tre une cl car plusieurs internautes peuvent avoir le mme nom.
(nom, prnom) est une cl possible, mais peut poser des problmes de performance et complique les
manipulations par SQL.
2.2 Le modle
2.2.1 Entits, attributs et identiants
2.2.2 Associations binaires
2.2.3 Entits faibles
2.2.4 Associations gnralises
2.3 Avantages et inconvnients du modle E/A
14 Chap.3 : Langages de bases de donnes
Chapitre 3
Langages de bases de donn ees
Sommaire
1 Le modle relationnel et ses rgles . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Un peu dhistoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Les notions de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Bases thoriques des langages relationnels : lalgbre relationnelle . . . . . 18
2.1 Une manipulation ensembliste des donnes . . . . . . . . . . . . . . . . . . . . 18
2.2 Les oprateurs de lalgbre relationnelle . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Expressions de requtes avec lalgbre . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Bien concevoir une base de donnes . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Les dpendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Dcomposition en formes normales . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Les contraintes dintgrit structurelles . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Passage dun schma E/A un schma relationnel . . . . . . . . . . . . . . . . 31
4 Le langage relationnel SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Les langages relationnels complets . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Le langage SQL : historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Le DML : Data Manipulation Language en SQL . . . . . . . . . . . . . . . . . 33
4.4 Le DDL (Data Description Language) en SQL . . . . . . . . . . . . . . . . . . 48
1. Le modle relationnel et ses rgles
Un modle de donnes dnit un mode de reprsentation de linformation selon trois composantes :
1. Des structures de donnes.
2. Des contraintes qui permettent de spcier les rgles que doit respecter une base de donnes.
3. Des oprations pour manipuler les donnes, en interrogation et en mise jour.
Les deux premires composantes relvent du Langage de Dnition de Donnes (DDL) dans un SGBD.
Le DDL est utilis pour dcrire le schma dune base de donnes. la troisime composante (oprations)
est la base du Langage de Manipulation de Donnes (DML) dont le reprsentant le plus clbre est SQL.
16 1 Le modle relationnel et ses rgles
Dans le contexte des bases de donnes, la principale qualit dun modle de donnes est dtre indpendant
de la reprsentation physique. Cette indpendance permet de sparer totalement les tches respectives
des administrateurs de la base, chargs de loptimisation de ses performances, et des dveloppeurs dap-
plication ou utilisateurs naux qui nont pas se soucier de la manire dont le systme satisfait leurs
demandes.
Le modle relationnel, venant aprs les modles hirarchique et rseau, ore une totale indpendance entre
les reprsentations logique et physique. Ce chapitre prsente la partie du modle relative la dnition
et la cration des tables, ce qui constitue lessentiel du schma relationnel.
1.1 Un peu dhistoire
Le modle relationnel a t introduit pour la premire fois par Ted Codd
1
du centre de recherche dIBM en
1970 dans un papier dsormais classique XXX, et attira immdiatement un intrt considrable en raison
de sa simplicit et de ses fondations mathmatiques. Le modle utilise le concept de relation mathmatique
qui est associe une table de valeurs comme primitive, et ses bases thoriques reposent sur la thorie
des ensembles et sur la logique du premier ordre.
Au dbut des annes 70, le modle relationnel fait son apparition [Codd 70]. La recherche se passionne :
impossible de nier les progrs apports concernant la reprsentation et la manipulation des donnes par les
systmes. Dix ans passent, les spcialistes dchantent : ce top-model engendre en dnitive des systmes
commerciaux bien moins performants que leurs concurrents fonds sur les modles rseau ou hirarchique.
Deux ans plus tard et voil que les produits relationnels peuvent prtendre relayer les "vieux" systmes.
Leurs apports sont fondamentaux : les nouvelles fonctionnalits permettent un confort dutilisation sans
prcdent. Les systmes commerciaux semparent des concepts de ce nouveau modle. Celui-ci, dsormais,
simpose.
Mais quels sont ces concepts, leurs avantages, leurs limites ? Certains sont dj bien rpandus. Ce sont
les notions de base que nous dtaillerons dans la premire partie : domaine, relation, attribut ; puis la
manipulation ensembliste des relations par les oprateurs de lalgbre relationnelle (deuxime partie) sur
lesquels sont construits des langages non procduraux comme SQL (chapitre 4 XXX) ; limportante base
thorique du modle enn fournit des mthodes pour la conception des bases de donnes (chapitre 5
XXX). Dautres concepts sont toutefois moins connus qui constituent pourtant un progrs essentiel : les
vues relationnelles permettent chaque utilisateur de personnaliser sa vision des donnes et les contraintes
dintgrit compltent la description de linformation (chapitre 6 XXX). Les sections suivantes prsentent
chacun des ressorts qui font du modle relationnel la rfrence oblige en matire de gestion de bases de
donnes.
1.2 Les notions de base
Dnition 3.1 (Domaine)
Un domaine D est un ensemble de valeurs (distinctes)
Exemple 1
boolen = {0, 1} ;
lensemble des entiers ;
{3, 5.7, 124} ;
(Jean, Paul, Louis, Arthur) ;
Dnition 3.2 (Produit cartsien)
Le produit cartsien dun ensemble de domaines D
1
, D
2
,. . ., D
n
, not D
1
D
2
. . . D
n
, est lensemble
de n-uplets (ou tuples) < v
1
, v
2
, . . . , v
n
> tels que v
i
appartient D
i
.
1
Codd introduisit aussi lalgbre relationnelle et posa les fondations thoriques pour le modle relationnel dans une srie
de papiers (Codd71, Codd72, Codd72a, Codd74). En 1979, il reut le Turing award, la plus grande rcompense de lACM
(Association for Computing Machinery), pour son travail sur le modle relationnel.
Chapitre 3 Langages de bases de donnes 17
Exemple 2
Le produit cartsien de D
1
= 0, 1 et de D
2
= rouge, vert, bleu est :
rouge 0
rouge 1
vert 0
vert 1
bleu 0
bleu 1
Dnition 3.3 (Relations)
Une relation (ou encore instance de relation) est un sous-ensemble du produit cartsien dune liste de
domaines.
Exemple 3
partir de D
1
et de D
2
, on construit la relation :
A
1
A
2
rouge 0
vert 1
bleu 0
bleu 1
La dnition dune relation comme un ensemble (au sens mathmatique) a quelques consquences impor-
tantes :
Lordre des lignes na pas dimportance car il ny a pas dordre dans un ensemble ;
On ne peut pas trouver deux fois la mme ligne car il ny a pas de doublon dans un ensemble ;
Il ny a pas de case vide dans la table, donc toutes les valeurs de tous les attributs sont toujours
connues.
Dans la pratique, cependant, les choses parfois un peu direntes.
Dnition 3.4 (n-uplet ou tuples)
Un n-uplet (lment) correspond une ligne dune relation.
Une autre faon de considrer une relation N domaines D
1
, D
2
,... D
N
est de reprsenter un espace
N dimensions. Dans cet espace, chaque domaine correspond lune des dimension et chaque n-uplet ou
tuple correspond un point de lespace.
Dnition 3.5 (Extension)
Lensemble des n-uplets est une extension possible de R.
Dnition 3.6 (Attributs)
Un attribut est le nom donn une colonne dun tableau reprsentant une relation. Un attribut est
toujours associ un domaine. Le nom dun attribut peut apparatre dans plusieurs schmas de relations.
Dnition 3.7 (Schma de relation)
Le schma dune relation est compos de son nom suivi du nom de ses attributs et de leurs domaine :
R(A
1
: D
1
, A
2
: D
2
, . . . , A
N
: D
N
). Lorsque le choix des domaines est vident, on simplie lcriture de
la faon suivante : R(A
1
, A
2
, . . . , N).
Dnition 3.8 (Cl dune relation)
L cl dune relation est le plus petit sous-ensemble des attributs qui permet didentier chaque ligne de
manire unique.
18 2 Bases thoriques des langages relationnels : lalgbre relationnelle
Dnition 3.9 (Base de donnes)
Une base de donnes relationnelle est constitue par lensemble des tuples de toutes les relations dnies
dans le schma de la base.
2. Bases thoriques des langages relationnels : lalgbre relation-
nelle
2.1 Une manipulation ensembliste des donnes
Nous avons tudi au chapitre prcdent les premiers modles de SGBD. Que ce soit le segment dans
le modle hirarchique ou larticle dans le modle rseau, la manipulation des informations seectue
enregistrement par enregistrement.
Dans un systme relationnel, les informations ne sont pas forcment repres individuellement ; on sait
appliquer le mme traitement un ensemble denregistrements caractriss, non par la liste des identiants
individuels, mais par le critre que vrie chacun des enregistrements qui composent lensemble. On dit
que la manipulation est ensembliste.
En particulier, pour rechercher des tuples, il sut de prciser un critre de slection ; le systme dtermi-
nera lensemble des tuples satisfaisant ce critre et rendra un rsultat. Les tuples de ce rsultat, extraits
de relations de la base, constituent eux-mme une relation quil sera ainsi ais de conserver, si ncessaire,
pour le plus grand confort de lutilisateur.
Par exemple, pour connatre les dates et dures des bains pris par Paul Coule ainsi que les noms des
plages, on obtient le rsultat suivant, qui est une relation RESULTAT trois attributs NOMP, DATE,
DUREE :
Typiquement, on peut classer les requtes en deux grandes catgories : la mise jour de tuples dans
une relation et la recherche de tuples vriant une certaine condition. Eventuellement, ces deux types de
requtes peuvent tre combins.
La manipulation ensembliste est trs utile en mise jour. Elle permet, par exemple, de modier di-
rectement la qualit de tous les nageurs ayant pris un bain sur la plage de Binic le 14 juillet 1989, sans
avoir dterminer pralablement la liste des nageurs qui prsentent cette caractristique. Cette puissance
dexpression explique largement le succs du relationnel.
Les insertions/suppressions sont ralises laide de relations temporaires internes et doprateurs ensem-
blistes dunion et de dirence (dtails au paragraphe suivant). La combinaison de ces oprateurs et des
oprateurs relationnels de slection sur des critres de recherche facilite sensiblement les oprations de
modication. Cest le cas en particulier des modications calcules, cest--dire des modications portant
sur un ensemble de tuples rsultant eux-mmes dune slection.
Exemple 4
insertion ou suppression de Paul Brasse, mauvais nageur, qui a pris un bain de 2 minutes le 14/07/1989 sur la
plage de sable trs pollue de Binic, en Bretagne.
recherche des noms des nageurs ayant pris des bains de plus dune minute en Bretagne.
suppression de tous les nageurs ayant pris, en fvrier, des bains de plus de 2 minutes en Bretagne (hydrocution ?).
Pour manipuler ces relations, nous avons besoin dun langage adapt dont la particularit est de savoir
manipuler aisment ces tableaux de donnes. Ce langage constitue lalgbre relationnelle.
Chapitre 3 Langages de bases de donnes 19
2.2 Les oprateurs de lalgbre relationnelle
Lalgbre relationnelle est le langage interne dun SGBD relationnel. Ce langage consiste en un ensemble
doprations qui permettent de manipuler des relations, considres comme des ensembles de tuples : on
peut ainsi faire lunion ou la dirence de deux relations, slectionner une partie de la relation, eectuer
des produits cartsiens ou des projections, etc.
Une proprit fondamentale de chaque opration est quelle prend une ou deux relations en entre, et
produit une relation en sortie. Cette proprit permet de composer des oprations : on peut appliquer
une slection au rsultat dun produit cartsien, puis une projection au rsultat de la slection et ainsi
de suite. En fait on peut construire des expressions algbriques arbitrairement complexes qui permettent
dexprimer des manipulations sur un grand nombre de relations.
Une requte est une expression algbrique qui sapplique un ensemble de relations (la base de donnes)
et produit une relation nale (le rsultat de la requte). On peut voir lalgbre relationnelle comme
un langage de programmation trs simple qui permet dexprimer des requtes sur une base de donnes
relationnelle. On parle de langage assertionnel car ils permettent de dnir les donnes que lon souhaite
sans dire comment y accder.
Cette algbre se compose doprateurs de manipulation des relations. Ces oprateurs sont regroups en
deux familles : les oprateurs ensemblistes et les oprateurs relationnels. Chacune de ces familles contient
quatre oprateurs.
2.2.1 Les oprateurs ensemblistes
Lunion : R S. Lexpression : R S, o R et S reprsentent deux relations de mme schma, cre
une relation comprenant tous les tuples existant dans lune ou lautre des relations R et S. Cet oprateur
permet de raliser linsertion de nouveaux tuples dans une relation.
Exemple 5
Soit la relation Club-de-Sport :
Club-de-Sport E# Nom Rue Ville de domicile
E1 Meier Rue Faucigny Fribourg
E7 Humbert Route des Alpes Bulle
E19 Savoy Avenue de la gare Romont
...
Et la relation Club-de-Photo :
Club-de-Photo E# Membre Rue Ville
E4 Brodart Rue du tilleul Fribourg
E7 Humbert Route des Alpes Bulle
...
Lunion Club-de-Sport Club-de-Photo est :
Club-de-Sport Club-de-Photo E# Nom Rue Ville de domicile
E1 Meier Rue Faucigny Fribourg
E7 Humbert Route des Alpes Bulle
E19 Savoy Avenue de la gare Romont
E4 Brodart Rue du tilleul Fribourg
Lintersection : RS. Lexpression : RS, o R et S reprsentent deux relations de mme schma,
cre une relation comprenant tous les tuples existant la fois dans lune et dans lautre des relations R
et S.
Exemple 6
Lintersection Club-de-Sport Club-de-Photo est :
20 2 Bases thoriques des langages relationnels : lalgbre relationnelle
Club-de-Sport Club-de-Photo E# Nom Rue Ville de domicile
E7 Humbert Route des Alpes Bulle
La dirence : R ` S. Lexpression : R ` S, o R et S reprsentent deux relations de mme schma,
cre une relation comprenant tous les tuples existant dans R et pas dans S. Cet oprateur permet de
raliser la suppression de tuples dans une relation.
Exemple 7
La dirence Club-de-Sport \ Club-de-Photo est :
Club-de-Sport \ Club-de-Photo E# Nom Rue Ville de domicile
E1 Meier Rue Faucigny Fribourg
E19 Savoy Avenue de la gare Romont
On peut noter que lintersection est une opration qui peut tre drive de la dirence entre deux tables :
R S = R ` (R ` S) .
Le produit cartsien : RS. Si R et S sont des relations de schmas respectifs (attR,1, attR,2,...,attR,N)
et (attS,1, attS,2,..., attS,M) contenant respectivement [R[ et [S[ tuples, alors la relation T = RS rsul-
tant du produit cartsien des deux relations a pour schma (attR,1, attR,2,...,attR,N, attS,1, attS,2,...,
attS,M) et contient [R[ [S[ tuples obtenus par concatnation des [R[ tuples de R et des [S[ tuples de S.
Exemple 8
Le produit cartsien (Club-de-Sport \ Club-de-Photo) Club-de-Photo est :
E# Nom Rue Ville de domicile E# Membre Rue Ville
E1 Meier Rue Faucigny Fribourg E4 Brodart Rue du tilleul Fribourg
E7 Humbert Route des Alpes Bulle E7 Humbert Route des Alpes Bulle
E19 Savoy Avenue de la gare Romont E4 Brodart Rue du tilleul Fribourg
E4 Brodart Rue du tilleul Fribourg E7 Humbert Route des Alpes Bulle
2.2.2 Les oprateurs relationnels
La slection :
F
(R). La slection
F
(R), o F exprime un prdicat sur une relation R, permet de ne
conserver dans la relation R que les tuples dont les attributs vrient une condition spcie par F.
La formule F contient un nombre dtermin dattributs ou de constantes lis par des oprateurs de
comparaison tels que >, < ou =, ou par des oprateurs logiques AND, OR et NOT.
Exemple 9
Soit la relation Employ :
Employ E# Nom Rue Ville Aectation
E19 Savoy Avenue de la gare Romont D6
E1 Meier Rue Faucigny Fribourg D3
E7 Humbert Route des Alpes Bulle D5
E4 Brodart Rue du tilleul Fribourg D6
La slection
V ille=Fribourg
(Employ) est :
Employ E# Nom Rue Ville Aectation
E1 Meier Rue Faucigny Fribourg D3
E4 Brodart Rue du tilleul Fribourg D6
La slection
Affectation=D6
(Employ) est :
Employ E# Nom Rue Ville Aectation
E19 Savoy Avenue de la gare Romont D6
E4 Brodart Rue du tilleul Fribourg D6
Chapitre 3 Langages de bases de donnes 21
La slection
V ille=FribourgANDAffectation=D6
(Employ) est :
Employ E# Nom Rue Ville Aectation
E4 Brodart Rue du tilleul Fribourg D6
La projection :
M
(R). La projection
M
(R) produit, partir dune table R, une sous-table dont les
attributs sont dnis dans M.
Exemple 10
Soit la relation Employ :
Employ E# Nom Rue Ville Aectation
E19 Savoy Avenue de la gare Romont D6
E1 Meier Rue Faucigny Fribourg D3
E7 Humbert Route des Alpes Bulle D5
E4 Brodart Rue du tilleul Fribourg D6
La projection
V ille
(Employ) est :
Ville
Romont
Fribourg
Bulle
La projection
Affectation,Nom
(Employ) est :
Aectation Nom
D6 Savoy
D3 Meier
D5 Humbert
D6 Brodard
La jointure : R
P
S. La jointure R
P
S de deux tables R et S daprs le prdicat P est une
combinaison de tous les tuples de R avec ceux de S qui satisfont le prdicat de jointure P. Le prdicat
de jointure contient un attribut de la table R et un attribut de S. Ces deux attributs sont lis par des
oprateurs de comparaison, <, > ou =, dnissant ainsi le critre de combinaison des tables R et S.
Si le prdicat de jointure contient loprateur de comparaison =, on parle dune qui-jointure ( equi-join
, en anglais).
Exemple 11
Soit la relation Employ :
Employ E# Nom Rue Ville Aectation
E19 Savoy Avenue de la gare Romont D6
E1 Meier Rue Faucigny Fribourg D3
E7 Humbert Route des Alpes Bulle D5
E4 Brodart Rue du tilleul Fribourg D6
Et soit la relation Dpartement :
D# Description
D3 Informatique
D5 Personnel
D6 Finances
Alors Employ
Affectation=D#
Dpartement :
E# Nom Rue Ville Aectation D# Description
E19 Savoy Avenue de la gare Romont D6 D6 Finances
E1 Meier Rue Faucigny Fribourg D3 D3 Informatique
E7 Humbert Route des Alpes Bulle D5 D5 Personnel
E4 Brodart Rue du tilleul Fribourg D6 D6 Finances
22 2 Bases thoriques des langages relationnels : lalgbre relationnelle
La division : R(Z)S(X). Z et X sont respectivement les ensembles dattributs associs aux relations
R et S, et X Z. Soit Y = Z `X (et donc Z = XY ) ; cest--dire soit Y lensemble des attributs de R
qui ne sont pas dans S. Le rsultat de la division est une relation T(Y ) contenant lensemble des tuples
t tels que t
R
apparat dans R avec t
R
[Y ] = t et tel que t
R
[X] = t
S
pour tous les tuples t
S
dans S.
En dautres termes, pour quun tuple t apparaisse dans le rsultat T de la division, les valeurs dans t
doivent apparatre en combinaison avec tous les tuples de S.
Remarque : le produit cartsien T S doit tre contenu dans la table R.
Exemple 12
Soit R la table dattribution des projets aux employs :
R E# Proj#
E1 P1
E1 P2
E1 P4
E2 P1
E2 P2
E4 P2
E4 P4
Et soit S la table de combinaison de projets :
S Proj#
P2
P4
On trouve tous les employs participants aux projets P2 et P4 par la division R = R S :
R E#
E1
E4
Il est possible dexprimer loprateur de division en fonction des oprateurs de projection, de dirence
et du produit cartsien. Pour cette raison, il gure parmi les oprateurs substituables de lalgbre rela-
tionnelle qui comprennent aussi les oprateurs dintersection et de jointure.
En rsum, cinq de ces huit oprateurs forment les oprateurs de base (ce sont lunion, la dirence, le
produit cartsien, la restriction et la projection) tandis que les trois autres, appels oprateurs drivs,
sobtiennent plus ou moins facilement par combinaison des oprateurs de base :
R S = R ` (R ` S) = (R S) ` ((R ` S) (S ` R))
R
P
S =
P
(R S)
R S =
Y
(R) `
Y
((S
Y
(R) ` R)
Les cinq oprateurs de base permettent de rpondre toutes les questions que lon peut poser avec la
logique du premier ordre (cest--dire sans les fonctions) : on dit que lalgbre relationnelle est complte.
En ralit, nous nutiliserons dans nos requtes que les oprateurs les plus maniables : ce sont lunion et
la dirence pour linsertion et la suppression de tuples dans la base et la restriction, la projection et la
jointure pour la recherche slective de tuples.
Les oprateurs de lalgbre relationnelle ne prsentent pas seulement un intrt sur le plan thorique. Leur
porte pratique est aussi importante. par exemple, nous en aurons besoin pour optimiser les requtes au
niveau du langage des systmes de bases de donnes relationnelles (voir section 2). En outre, ils trouvent
leur application dans la conception des ordinateurs de base de donnes : les oprateurs de lalgbre
relationnelle et leurs formes drives ny sont pas mis en uvre sous forme logicielle, mais implantes
directement dans des composants matriels de lordinateur.
Exercices
Dabord les exercices simples de [Buche] pp.87-88, puis 91-94
Exemple 13
On suppose que lon a le schma de bases de donnes suivant :
Emprunt(Personne, Livre, DateEmprunt, DateRetourPrevue, DateRetourEective)
Chapitre 3 Langages de bases de donnes 23
Retard(Personne), Livre, DateEmprunt, PnlitRetard)
crire en algbre relationnelle les requtes suivantes :
1. Quelles sont les personnes ayant emprunt tous les livres ?
Rponse :
Personne,Livre
(Emprunt)
Livre
(Emprunt)
2. Quelles sont les personnes ayant toujours rendu en retard les livres quelles ont emprunts ?
Rponse :
Personne
(Emprunt) \
Personne
[
Personne,Livre,DateEmprunt
(Emprunt)
\
Personne,Livre,DateEmprunt
(Retard)]
Exemple 14
On suppose que lon a le schma de bases de donnes suivant :
Location(Personne, Voiture, DateDbut, DateFin)
Accident(Personne, Voiture, Date)
crire en algbre relationnelle les requtes suivantes :
1. Quelles sont les personnes ayant mou toutes les voitures ?
Rponse :
Personne,V oiture
(Location)
V oiture
(Location)
2. Quelles sont les personnes ayant toujours eu des accidents avec les voitures quelles ont loues ?
Rponse :
Personne
(Location) \
Personne
[
Personne,V oiture
(Location) \
Personne,V oiture
(Accident)]
Poly Rigaux, pp.62-64
Ensuite les exos (corrigs) de [Elmasri et Navathe], pp.230-232 (xerox pp.204-205)
Puis lexo7.18 de [Elmasri et Navathe], pp.235 (xerox pp.204-205)
2.3 Expressions de requtes avec lalgbre
2.3.1 Slection gnralise
2.3.2 Requtes conjonctives
2.3.3 Requtes avec et
2.4 Conclusions
3. Bien concevoir une base de donnes
Nous tudions dans cette section comment bien concevoir une BD. Pour ce faire, partir dun mme
ensemble de connaissances ayant trait aux plages, nous proposons deux choix dorganisation des infor-
mations sous forme relationnelle. Nous tudions les qualits et les dfauts de ces dirents choix avant de
prsenter les rgles de "bonne" conception dune BD relationnelle.
Premier choix : BAINS (NN, NOM, PRENOM, QUALITE, DATE, DUREE, NP, NOMP, TYPE, RE-
GION, POLLUTION)
Deuxime choix :
NAGEUR (NN, NOM, PRENOM, QUALITE)
PLAGE (NP, NOMP, TYPE, REGION, POLLUTION)
BAIGNADE (NN, NP, DATE, DUREE)
NN et NP sont des numros permettant de distinguer respectivement les nageurs et les plages. NN est
lquivalent du numro de scurit sociale.
Nous constatons sur cet exemple lexistence de plusieurs faons de structurer un mme ensemble dinfor-
24 3 Bien concevoir une base de donnes
mations. Si nous privilgions instinctivement lune des deux solutions proposes, cest quelle correspond
davantage notre perception du monde rel, dans laquelle nous distinguons naturellement certaines
entits : les personnes, les plages, etc.
Ltape de conception est primordiale pour le bon fonctionnement dun SGBD. Elle fait partie des quelques
facteurs qui peuvent entraner des incohrences dans les rponses et une diminution inacceptable des
performances du systme ; cest pourquoi il est indispensable dy attacher une attention toute particulire.
Exemple 15
Soit R la relation des nageurs :
Nageurs N# Nom Prnom Qualit
100 Dupont Jean Mauvais
103 Marin Pierre Excellente
114 Palmier Jean Bonne
Soit S la table des plages :
Plages NP# NomP Type Rgion Pollution
110 Trgastel Sable Bretagne Absente
119 Nice Galets Cte dAzur Importante
107 Olron Sable Atlantique Moyenne
118 Binik Sable Bretagne Importante
Et soit S la table des baignades :
Baignades N# NP# Date Dure
103 118 14/07/89 2
103 118 15/07/89 10
114 119 12/07/89 120
Une solution "instinctive" nest pas susante pour concevoir le schma dune base importante. Il est
donc ncessaire disoler les critres de dcision et de formaliser des mthodes de conception des bases de
donnes. Tel est lobjet de cette section.
Les problmes les plus courants rencontrs dans des bases de donnes mal conues peuvent tre regroups
selon les critres suivants :
Redondance des donnes. Certains choix de conception entranent une rptition des donnes lors de
leur insertion dans la base. Cette redondance est souvent la cause danomalies provenant de la complexit
des insertions.
Cest, par exemple, le cas de la premire organisation propose : ds quune personne prend un nouveau
bain, on doit non seulement rpter son numro qui, par hypothse, sut le dterminer, mais aussi
toutes les informations lies ce numro (son nom, son prnom, sa qualit). Au contraire, dans le deuxime
choix, seul le numro indispensable la distinction dun nageur est rpt. La situation est identique pour
les plages.
Incohrence en modication. La redondance de linformation entrane galement des risques en cas
de modication dune donne rpte en dirents endroits : on oublie frquemment de modier toutes
ses occurrences (en gnral par simple ignorance des direntes places o gure linformation).
Par exemple, dans la premire organisation propose, si une personne change de nom (cas frquent lors de
mariages), il faut changer ce nom dans tous les tuples o apparaissent ses coordonnes. Dans la deuxime
organisation, un seul tuple est modi.
Anomalie dinsertion. Une mauvaise conception peut parfois empcher linsertion dun tuple, faute
de connatre la valeur de tous les attributs de la relation. Pour remdier ce problme, certains SGBD
implantent une valeur non type qui signie que la valeur dun attribut dun tuple est inconnue ou
indtermine. Cette valeur (appele usuellement NULL) indique rellement une valeur inconnue et non
une chane de caractres vide ou un entier gal zro (analogie avec un pointeur gal NIL en Pascal).
Chapitre 3 Langages de bases de donnes 25
Dans le premier schma propos, insrer une nouvelle plage o personne ne sest jamais baign est aussi
impossible.
Anomalie de suppression. Enn, une mauvaise conception peut entraner, lors de la suppression
dune information, la suppression dautres informations, smantiquement distinctes, mais regroupes au
sein dun mme schma. Cest ce qui se produit dans notre premier exemple, la suppression dune plage
entrane automatiquement la suppression de tous les nageurs ne stant baigns que sur cette plage.
De nombreux travaux ont permis de mettre au point une thorie de conception dune base de donnes
relationnelle : la thorie de la normalisation, que nous allons maintenant dvelopper.
Fig. 3.1: La normalisation dune base de donnes relationnelle.
3.1 Les dpendances fonctionnelles
Cette thorie est base sur les dpendances fonctionnelles (DF). Les dpendances fonctionnelles
traduisent des contraintes sur les donnes (par exemple, on dcide que deux individus dirents peuvent
avoir mme nom et prnom mais jamais le mme numro NN). Ces contraintes sont reprsentatives dune
perception de la ralit et imposent des limites la base.
Les dpendances fonctionnelles et des proprits particulires, dnissent une suite de formes normales
(FN). Elles permettent de dcomposer lensemble des informations en diverses relations. Chaque nouvelle
forme normale marque une tape supplmentaire de progression vers des relations prsentant de moins
en moins de redondance. Ces tapes traduisent une comprhension de plus en plus ne de la ralit.
Chacune de ces formes normales peut tre obtenue au moyen dalgorithmes de dcomposition. Le point
de dpart de ces algorithmes est la relation universelle, cest--dire la relation qui regroupe toutes les
informations stocker (dans notre exemple, le premier schma reprsente cette relation universelle) ;
le but est dobtenir, en sortie, une reprsentation canonique des donnes prsentant un minimum de
redondance lintrieur de chaque relation et un maximum dindpendance entre les direntes relations
.
3.1.1 Les dpendances fonctionnelles
Dnition 3.10 (Dpendance fonctionnelle)
On dit quun attribut B dpend fonctionnellement dun attribut A si, tant donn une valeur de A, il lui
correspond une unique valeur de B (quel que soit linstant t considr).
On note cette dpendance par : A B.
Plus gnralement, soit R(A
1
, A
2
, . . . , A
n
) un schma de relation, et X et Y deux sous-ensembles de
A
1
, A
2
, . . . , A
n
, on dit que Y dpend fonctionnellement de X ssi toute valeur de X correspond une
valeur unique de Y .
26 3 Bien concevoir une base de donnes
Exemple 16
La dpendance fonctionnelle NN NOM signie qu un numro est associ un nom unique (cest, par exemple,
le cas du numro de scurit sociale). Remarquons quune dpendance fonctionnelle nest gnralement pas sy-
mtrique, cest--dire que NN NOM ninterdit pas que deux personnes distinctes (correspondant deux NN
dirents) portent le mme nom.
Une dpendance fonctionnelle est une proprit dnie sur tous les tuples dune relation et pas seulement
sur un tuple particulier. Elle traduit une certaine perception de la ralit (par exemple, deux personnes
distinctes peuvent porter le mme nom). Elle correspond une contrainte qui doit tre vrie en per-
manence.
Les dpendances fonctionnelles sont parties intgrantes du schma dune BD. Elles doivent donc thori-
quement tre dclares par ladministrateur et contrles par le SGBD.
Exemple 17
Nous dnissons les proprits vries par notre base de baignades. Deux personnes distinctes peuvent, par
exemple, porter le mme nom, le mme prnom, et avoir la mme qualit de nage. Deux numros de nageur
dirent les distinguent lune de lautre. Les dpendances fonctionnelles que nous venons de dcrire sont donc NN
NOM, NN PRENOM, NN QUALITE Nous pouvons supposer galement que deux plages distinctes
ont toujours deux numros dirent ; ce qui implique : NP NOMP, NP REGION, que la pollution et le type
sont propres une plage : NP POLLUTION, NP TYPE, et que deux plages dune mme rgion ne peuvent
porter le mme nom : (NOMP, REGION) NP
3.1.2 Proprits des dpendances fonctionnelles
Les dpendances fonctionnelles obissent certaines proprits connues sous le nom daxiomes dArm-
strong.
Rexivit : Y X X Y
Augmentation : X Y XZ Y Z
Transitivit : X Y et Y Z X Z
Dautres proprits se dduisent de ces axiomes :
Union : X Y et X Z X Y Z
Pseudo-transitivit : X Y et Y W Z XW Z
Dcomposition : X Y et Z Y X Z
Lintrt de ces axiomes et des proprits dduites est de pouvoir construire, partir dun premier
ensemble de dpendances fonctionnelles, lensemble de toutes les dpendances fonctionnelles quelles g-
nrent. Lensemble des dpendances de dpart est alors appel dpendances fonctionnelles lmentaires.
3.1.3 Dpendance fonctionnelle totale
Dans le cas des cls composes, nous devons complter la notion de dpendance fonctionnelle par celle de
la dpendance fonctionnelle totale.
Dnition 3.11 (Dpendance fonctionnelle totale)
Une dpendance fonctionnelle X A est totale si
Chapitre 3 Langages de bases de donnes 27
A nest pas inclus dans X;
il nexiste pas X inclus dans X tel que X A.
La dpendance fonctionnelle totale exprime donc le fait que la totalit de la cl compose dtermine de
manire unique les attributs non cls.
Cette notion de dpendance fonctionnelle totale est primordiale car elle permet de construire une sorte
de famille gnratrice minimale (appele couverture minimale) des dpendances fonctionnelles utiles pour
structurer la base.
Exemple 18
Deux plages dune mme rgion ne peuvent pas porter le mme nom (contrairement deux plages de rgions di-
rentes) ; le degr de pollution dune plage dpend exclusivement de la plage et non de la rgion. On a alors (NOMP,
REGION) POLLUTION, mais on na aucunement : NOMP POLLUTION ni REGION POLLUTION
donc (NOMP, REGION) POLLUTION est une dpendance fonctionnelle lmentaire.
3.1.4 Graphe des dpendances fonctionnelles
Cest une reprsentation graphique permettant de visualiser aisment toutes les dpendances fonction-
nelles et disoler les principales (i.e. les DF lmentaires).
Exemple 19
Toutes les dpendances fonctionnelles cites prcdemment peuvent tre reprsentes comme sur la gure 3.2.
Fig. 3.2: Graphe de dpendances fonctionnelles.
3.1.5 Fermeture transitive
Dnition 3.12 (Fermeture transitive)
La fermeture transitive F
+
dun ensemble F de dpendances fonctionnelles est ce mme ensemble enrichi
de toutes les dpendances fonctionnelles dduites par transitivit.
On dira alors que F est quivalente F

ssi F
+
= (F

)
+
Exemple 20
De lexemple prcdent , on dduit par transitivit deux nouvelles dpendances fonctionnelles : (NOMP, REGION)
TYPE et (NOMP, REGION) POLLUTION qui enrichissent le graphe comme sur la gure 3.3.
3.1.6 Couverture minimale
Dnition 3.13 (Couverture minimale)
La couverture minimale, note Min(F) dun ensemble F de dpendances fonctionnelles est un sous
28 3 Bien concevoir une base de donnes
Fig. 3.3: Graphe de dpendances fonctionnelles enrichi.
ensemble minimum de dpendances fonctionnelles lmentaires permettant de gnrer toutes les autres.
On a les proprits suivantes :
Minimalit : Aucune DF de Min(F) nest redondante, i.e. (Min(F) f)
+
= (Min(F))
+
.
Exhaustivit : (Min(F))
+
= F
+
Exemple 21
Lensemble des dpendances fonctionnelles suivant : (NN NOM, NN PRENOM, NN QUALITE, NP
NOMP, NP REGION, (NOMP, REGION) POLLUTION, (NOMP, REGION) NP) est une couverture
minimale de lensemble des dpendances fonctionnelles.
Thorme 3.1
Tout ensemble de dpendances fonctionnelles admet une couverture minimale, en gnral non unique.
Exemple 22
Lensemble des dpendances fonctionnelles suivant : (NN NOM, NN PRENOM, NN QUALITE, NP
NOMP, NP REGION, NP POLLUTION, (NOMP, REGION) NP) est une autre couverture minimale
de lensemble des dpendances fonctionnelles.
La recherche de la couverture minimale dun ensemble de dpendances fonctionnelles est un lment
essentiel du processus de normalisation, dont le but est de dcomposer une relation en plusieurs relations
plus petites.
3.1.7 Cl dune relation
Dnition 3.14 (Cl dune relation)
Soit R(A
1
, A
2
, ..., A
N
) un schma de relation, soit F+ lensemble des dpendances fonctionnelles associes
R, soit X un sous-ensemble de A
1
, A
2
, . . . , A
N
, on dit que X est une cl de R si et seulement si
X A
1
, A
2
, . . . , A
N
;
il nexiste pas de sous ensemble Y inclus dans X tel que Y A
1
, A
2
, ..., A
N
.
Une cl dune relation est un ensemble minimum dattributs qui dtermine tous les autres.
Exemple 23
NN est cl de la relation PERSONNE (NN, NOM, PRENOM, QUALITE) ;
(NOMP, REGION) est cl de la relation (NP, NOMP, REGION, POLLUTION, TYPE).
Plusieurs cls peuvent tre candidates pour une mme relation.
Exemple 24
NP et (NOMP, REGION) sont deux cls candidates la relation (NP, NOMP, REGION, POLLUTION, TYPE).
Chapitre 3 Langages de bases de donnes 29
Dans lcriture des schmas de relations, on indique les cls en soulignant les attributs constitutifs, ou en
les mettant en gras.
Exemple 25
PLAGE (NP, NOMP, REGION, POLLUTION, TYPE)
3.2 Dcomposition en formes normales
Ltude des dpendances fonctionnelles et de certaines de leurs proprits permet daborder la smantique
des schmas de relation. On suppose quun ensemble de dpendances fonctionnelles et de cls primaires est
donn pour chaque relation. Ces informations utilises avec des conditions pour des formes dites normales
permettent de prescrire une procdure de normalisation.
Cest Codd ([?]) qui, le premier, a propos de soumettre un schma de relation une squence de tests
pour certier quil vrie une certaine forme normale. Initialement, Codd proposa trois formes normales :
les premire, deuxime et troisime formes normales (1NF, 2NF et 3NF). Une dnition plus forte de la
3NF, appele forme normale de Boyce-Codd (BCNF), fut propose plus tard par Boyce et Codd. Toutes
ces formes normales sont fondes sur lexploitation de dpendances fonctionnelles entre des attributs dune
relation. Une quatrime et une cinquime formes normales (4NF et 5NF) furent ensuite dnies, fondes
respectivement sur le concept de dpendances multivalues et sur celui de dpendance de jointure.
Le processus de normalisation peut ainsi tre vu comme comme une mthode danalyse des relations an
(1) den rduire la redondance et (2) de minimiser les anomalies dinsertion, de suppression et de mise
jour.
Les formes normales imposent des critres de plus en plus restrictifs aux tables normalises au fur et
mesure du passage dune forme normale la suivante, comme lvoque la gure 3.4.
Cinquime forme normale
(5FN)
Dpendance de jointure
triviale seulement
Quatrime forme normale (4FN)
Pas de dpendances multivalues
Forme normale Boyce-Codd (FNBC)
Seules les dpendances de cl sont admises
Troisime forme normale (3FN)
Il n'y a pas de dpendances transitives
Deuxime forme normale (2FN)
Les attributs non cls dpendent de la cl entire dans leur table
Premire forme normale (1FN)
Toutes les valeurs des attributs sont atomiques (pas de groupes rptitifs)
Tables non normalises
Fig. 3.4: Vue densemble des formes normales et de leurs proprits.
Les formes normales nont pas toutes la mme importance, et, dans la pratique, on se limite gnralement
aux trois premires formes normales, car les dpendances multivalues et les dpendances de jointure se
prsentent moins frquemment.
30 3 Bien concevoir une base de donnes
3.2.1 Dcomposition des relations
La thorie de la normalisation repose sur un principe de dcomposition des relations.
Dnition 3.15 (Dcomposition dune relation)
La dcomposition dun schma de relation R(A
1
, A
2
, ..., A
N
) est son remplacement par une collection de
schmas de relations (R
1
, R
2
, ..., R
i
) telle que : SCHEMA(R) = SCHEMA(R
1
) SCHEMA(R
2
)
. . . SCHEMA(R
i
)
Dnition 3.16 (Dcomposition sans perte)
Une dcomposition dune relation R en N relations R
1
, R
2
, . . . , R
N
est sans perte si et seulement si, pour
toute extension de R, on a : R = R
1
R
2
. . . R
N
Thorme 3.2 (Dcomposition sans perte)
Une dcomposition en deux relations est sans perte si lattribut de jointure de la recomposition est cl
dune au moins des deux relations.
Dnition 3.17 (Dcomposition prservant les dpendances fonctionnelles)
Une dcomposition (R
1
, R
2
, . . . , R
N
) de R prserve les dpendances fonctionnelles si la fermeture des
dpendances fonctionnelles de R est la mme que celle de lunion des dpendances fonctionnelles des
relations R
1
, R
2
, . . . , R
N
.
3.2.2 Premire forme normale (1FN)
Dnition 3.18 (Premire forme normale)
Une table satisfait la premire forme normale si les domaines de ses attributs sont constitus de valeurs
atomiques.
3.2.3 Deuxime forme normale (2FN)
Dnition 3.19 (Deuxime forme normale)
Une table satisfait la deuxime forme normale si elle est en premire forme normale et sil existe une
dpendance fonctionnelle totale reliant la cl chaque attribut non cl.
3.2.4 Troisime forme normale (3FN)
Dnition 3.20 (Troisime forme normale)
Une table satisfait la troisime forme normale si elle est en deuxime forme normale et quaucun
attribut non cl ne dpend dune cl quelconque par transitivit.
3.2.5 La forme normale de Boyce-Codd (FNBC) : les dpendances multivalues
Les deuxime et troisimes formes normales nous ont permis dliminer les redondances parmi les attributs
non cls. Cependant, la dtection des informations redondantes ne doit pas se limiter aux attributs non
cls, car les cls composes peuvent aussi tre redondantes.
3.2.6 Quatrime forme normale (4FN)
La prsence des dpendances multivalues dans une table entrane des redondances et des anomalies.
Pour les supprimer, il faut considrer une autre forme normale, dite quatrime forme normale.
Chapitre 3 Langages de bases de donnes 31
Dnition 3.21 (Quatrime forme normale)
Une table en quatrime forme normale ne doit pas contenir en mme temps deux dpendances multivalues
par paire dattributs.
3.2.7 Cinquime forme normale (5FN)
Il nest pas du tout vident de russir dcomposer une table en sous-tables sans perte dinformation. Cest
pourquoi des critres ont t dnis an de garantir une dcomposition de tables sans perte dinformation.
Plus prcisment, les informations originelles doivent se retrouver dans les nouvelles tables obtenues par
dcomposition (concept de dpendance de jointure).
La cinquime forme normale (5FN), appele aussi forme normale de projection-jointure, indique les cir-
constances dans lesquelles une table peut tre dcompose et, le cas chant, reconstruite, sans problme.
La dcomposition seectue laide de loprateur de projection, et la reconstruction laide de lopra-
teur de jointure.
3.3 Les contraintes dintgrit structurelles
Les contraintes dintgrit structurelles tablissent des rgles qui doivent sappliquer un schma de base
de donnes pour assurer sa cohrence. Dans le contexte des bases de donnes relationnelles, les contraintes
dintgrit structurelles sont classes en trois catgories :
Contrainte dunicit : chaque table possde une cl didentication (un attribut ou une combinaison
dattributs) qui sert direncier les tuples dans la table de manire unique ;
Contrainte de domaine : un attribut dans une table ne peut prendre que des valeurs appartenant un
domaine de valeurs prdnies ;
Contrainte dintgrit rfrentielle : chaque valeur dune cl trangre doit exister comme valeur de la
cl didentication correspondante dans la table rfrence.
3.4 Passage dun schma E/A un schma relationnel
La cration dun schma de base de donnes est simple une fois que lon a dtermin toutes les relations
qui constituent la base. En revanche, le choix de ces relations est un problme dicile car il dtermine en
grande partie les caractristiques et qualits de la base : performances, exactitude, exhaustivit, disponi-
bilit des informations etc. Un des aspects importants de la thorie des bases de donnes relationnelles
consiste prcisment dnir ce quest un bon schma et propose des outils formels pour y parvenir
(rgles de normalisation).
En pratique, on procde dune manire moins rigoureuse mais plus accessible, en concevant le schma
laide dun modle de donnes conceptuel (e.g. le modle Entit / Association), puis en transcrivant
le schma conceptuel obtenu en schma relationnel.
3.4.1 Rgles gnrales
3.4.2 Retour sur le choix des identiants
3.4.3 Dnormalisation du modle logique
4. Le langage relationnel SQL
4.1 Les langages relationnels complets
Les langages relationnels complets sont des langages qui permettent au moins dexploiter les possibilits
de traitement dcoulant de lalgbre relationnelle, ou dappliquer le calcul dit relationnel
2
qui est aussi
2
Qui est fond sur la logique des prdicats.
32 4 Le langage relationnel SQL
puissant que lalgbre relationnelle.
Dnition 3.22 (Langage relationnel complet)
Un langage dinterrogation de bases de donnes est relationnel complet au sens de lalgbre relationnelle
lorsquil permet au moins lemploi des trois oprateurs ensemblistes : union, dirence et produit cartsien,
et des deux oprateurs relationnels : la projection et la slection.
Cependant, pour quils soient utiles en pratique, une extension des langages relationnels complets simpose
en y incluant les fonctionnalits suivantes :
Le langage doit permettre de crer des tables, deectuer des oprations dinsertion, de modication et
de suppression.
Le langage doit inclure des fonctions dagrgation, permettant de calculer, par exemple, la somme, le
maximum, le minimum ou la moyenne des valeurs dans la colonne dune table.
Le langage doit permettre de formater et de prsenter les tables daprs dirents critres, tels que la
squence de tri ou les ruptures de squences par groupes.
Les langages de base de donnes relationnelles doivent absolument comporter des lments pour grer
les autorisations daccs et pour assurer la protection des bases de donnes.
Les langages de bases de donnes relationnelles doivent prendre en considration lenvironnement mul-
tiutilisateur et disposer de commandes pour garantir la scurit des donnes.
Il est avantageux de disposer dun langage de base de donnes relationnelles qui supporte des expressions
ou des calculs arithmtiques.
4.2 Le langage SQL : historique
SQL (Structured Query Language) est linterface de communication avec les SGBD relationnels.
Hier norme de fait, SQL est devenu une norme de droit quand lInternational Organization for Stan-
dardization la pris en compte en 86 [ISO 86] (SQL1 : normalisation ISO/CEI 9075 en 1989 ; SQL2 :
normalisation ISO/CEI 9075 NS739 en 1991 ; SQL3 : normalisation ISO/CEI 9075 : 1999 ; SQL2003 :
normalisation ISO/CEI 9075 : 2003). SQL est arriv maturit. Sa version normalise par lISO ge ses
dirents aspects : dnition des concepts, du vocabulaire, du langage de dnition de donnes (dclara-
tion du schma, des vues, du contrle des autorisations) et du langage de manipulation sont dsormais
stabiliss. Les procdures dintgration des appels SQL dans un langage hte (de type Cobol, Pascal, C,
Fortran. . .), regroupes sous le nom de "Embedded SQL", souvent not ESQL, sont galement dnies.
Presque tous les constructeurs proposent le langage SQL. Plus de 70 produits du march le fournissent,
sur des machines qui vont du PC au plus importants mainframes. Celui-ci tend mme sa perce vers des
produits micros qui, sans devenir de vritables SGBD relationnels complets, intgrent dj la partie de
SQL qui concerne la manipulation des donnes.
SQL est un facteur important de promotion du modle relationnel. Il apporte une vision unie et une
large communaut de concepts et de vocabulaire. Reposant sur une base thorique solide (la logique des
prdicats), il concerne la fois les administrateurs, les programmeurs dapplications, et les utilisateurs
nals pour la dnition et la manipulation des donnes.
La norme SQL comporte trois parties distinctes concernant :
la manipulation de linformation; le (DML : Data Manipulation Language) concerne lensemble
des requtes de recherche et de mise jour des informations : selection, insertion, modication et
suppression. Il est essentiellement destin lutilisateur nal ;
la dnition des structures de donnes ; le DDL (Data Denition Language) contient lensemble
des commandes de cration, de suppression, de modication des relations. Elle intgre la crations,
la suppressions de chemins daccs (index) et les commandes concernant la gestion des droits et des
autorisations. Elle est largement destine ladministrateur ;
laccs aux informations stockes dans le SGBD depuis un langage de programmation;
lEmbedded SQL dnit lensemble des interfaces, lutilisation des ordres SQL dans un langage de pro-
grammation, ainsi que lensemble des codes derreur renvoys par le SGBD au programme dapplication
dni. LEmbedded SQL est destin au programmeur dapplications.
SQL est un langage non procdural : on exprime ce que lon veut obtenir, non comment lobtenir.
Chapitre 3 Langages de bases de donnes 33
SQL permet :
de dnir le schma de la base de donnes (DDL)
de charger les tables relationnelles (DML)
de manipuler les donnes stockes dans la base (DML)
de grer la base de donnes (DDL : scurit, organisation physique).
La liste des avantages et inconvnients de la norme SQL telle quelle se prsente aujourdhui peut tre
rapidement dresse : son actif, citons sa simplicit, sa souplesse et ses fonctionnalits tendues ;
son passif, un manque de rigueur (il autorise - et encourage - certaines formulations procdurales), une
utilisation lourde (mot cls, pas dutilisation de moyens modernes dinterface homme/machine), le fait
quil constitue, comme toute norme, un frein la crativit des concepteurs de nouveaux systmes.
Rappelons enn quil sagit dun langage invent par IBM, argument stratgique dlicat placer dans les
qualits ou les dfauts du langage.
La normalisation de SQL, dont la premire version a t acheve en 86, conduit galement se poser
la question " qui peut servir la normalisation ?". En eet, si lon examine les direntes parties de la
norme, on constate que ladministrateur doit disposer doutils moins primitifs et plus spciques pour g-
rer convenablement son SGBD; lutilisateur nal a bien du mal utiliser directement SQL en interactif :
il utilise des interfaces spciques (menus, crans. . .) plus conviviales ; enn le programmeur dapplica-
tions est aujourdhui largement sollicit par les Langages de quatrime Gnration (L4G) qui, sans tre
normaliss, sont plus pratiques et procurent les mmes services de base que du Embedded SQL. Certaines
mauvaises langues en concluent donc que la normalisation ne sert quaux normalisateurs. . . Lapport de
la normalisation du SQL est cependant indiscutable pour les utilisateurs dsirant garantir la portabilit
de leurs applications dun systme SQL sur un autre. Cest linterface standard de tout vritable SGBD
relationnel. Il prcise, dautre part, un niveau dinterface prcis lorsquon envisage des systmes rpartis
et htrognes.
Les lments du langage SQL donns dans la suite se rfrent principalement la norme SQL2, et parfois
celle de SQL2003 (par exemple pour les triggers).
Verbes du DML (Data Manipulation Language) :
select : Rechercher une donne
insert : Insrer une ligne (ou plusieurs) dans une table
update : modier une ligne (ou plusieurs) dans une table
delete : supprimer une ligne (ou plusieurs) dans une table
Verbes du DDL (Data Description Language) :
create : Cration dun objet
alter : Modication dun objet
drop : Suppression dun objet
grant : Accorder une autorisation sur un objet
revoke : Supprimer une autorisation sur un objet
4.3 Le DML : Data Manipulation Language en SQL
Les requtes en SQL se font laide dune seule construction, le SELECT, dont la structure est la suivante :
SELECT nom_table.nom_colonne*
FROM nom_table*
[WHERE conditions_de_slection_sur_lignes*]
[GROUP by nom_colonne_de_regroupement*]
[HAVING conditions_de_slection_sur_groupe*]
[ORDER BY nom_colonne_tri*] ;
Notes : *= plusieurs occurrences possibles, [] = optionnel
Exemple 26
34 4 Le langage relationnel SQL
SELECT nomStation
FROM Station
WHERE region = Antilles ;
4.3.1 Requtes simples SQL
Exemple 27
Requte 1 : chercher la date de naissance et ladresse des employs dont le nom est John B. Smith.
SELECT bdate, address
FROM EMPLOYEE
WHERE fname = John AND minint = B AND lname = Smith ;
Cette requte nimplique que la relation EMPLOYEE qui apparat dans la clause SELECT. La requte slectionne les
tuples de la table EMPLOYEE qui satisfont aux conditions spcies dans la clause WHERE, puis projette le rsultat
sur les attributs bdate et address apparaissant dans la clause SELECT. Cette requte est similaire lexpression
suivante en algble relationnelle (sauf que les doublons peuvent exister en SQL contrairement ce qui se passe en
algbre relationnelle) :

bdate,address
(
fname=John AND minint=B AND lname=Smith
(EMPLOYEE))
Ainsi, une requte SQL simple avec un seul nom de relation dans la clause FROM est similaire une paire
select-project doprations en algbre relationnelle. La clause SELECT en SQL spcie les attributs de
projection, et la clause WHERE spcie les conditions de slection. La seule dirence tant que lon peut
obtenir des tuples dupliqus en SQL parce que la contrainte ensembliste nest pas assure.
Pour viter deux tuples identiques, on peut utiliser le mot-cl DISTINCT.
SELECT DISTINCT libelle
FROM Activit
Remarque
Llimination des doublons peut tre une opration coteuse.
Une slection est une restriction suivie dune projection. Une restriction est une combinaison boolenne
(or, and, not) de conditions lmentaires portant sur les colonnes dune table. Les prdicats de restric-
tion permettent la comparaison dune valeur porte par une colonne une valeur constante. Ils peuvent
sexprimer de direntes manires :
laide des oprateurs =, <>, <, >, <=, >= (cf Q1, Q2)
laide du prdicat dintervalle BETWEEN qui teste si la valeur de lattribut est compris entre deux
valeurs constantes. Lattribut doit porter une valeur numrique ou de type date (cf Q3).
laide du prdicat de comparaison de texte LIKE qui teste si un attribut de type chane contient une
ou plusieurs sous-chanes. Le caractre soulign _ remplace un caractre quelconque. Le caractre %
remplace une squence de caractres (cf Q4 et Q5).
laide du prdicat de test de nullit (attribut non renseign) NULL (cf Q7).
laide du prdicat dappartenance IN qui teste si la valeur de lattribut appartient une liste de
valeurs (cf Q6).
Exemple 28
Voici quelques exemples simples de requtes SQL.
(Q1) SELECT titre, genre FROM Livre WHERE auteur = Dumas ;
On recherche dans la table LIVRE le titre et le genre des ouvrages crits par DUMAS
(Q2) SELECT * FROM Livre WHERE auteur <> Dumas AND anne > 1835 ;
On recherche les ouvrages non crits par Dumas et postrieurs 1835
(Q3) SELECT auteur, lieu FROM Ecrivain WHERE n_en BETWEEN 1802 AND 1850 ;
On recherche le nom des auteurs ns entre 1802 et 1850 (ainsi que leur lieu de naissance).
(Q4) SELECT * FROM Ecrivain WHERE auteur LIKE B % ;
Chapitre 3 Langages de bases de donnes 35
On ltre les auteurs dont le nom commence par un B
(Q5) SELECT * FROM Ecrivain WHERE auteur LIKE _A % ;
On ltre les auteurs dont le nom contient un A en deuxime position
(Q6) SELECT auteur, titre, anne FROM Livre WHERE anne IN (1839, 1866, 1857) ;
On slectionne les ouvrages sortis en 1839, 1866 ou 1857.
(Q7) SELECT auteur, titre, anne FROM Livre WHERE anne NOT NULL ;
On slectionne les ouvrages pour lesquels on dispose de lanne de parution.
Tri du rsultat. Il est possible de trier le rsultat dune requte laide de la clause ORDER BY suivie
de la liste des attributs servant de critre au tri.
Exemple 29
SELECT *
FROM Station
ORDER BY tarif, nomStation
trie par ordre ascendant les stations par leur tarif, puis, pour un mme tarif, prsente les stations selon lordre
lexicographique.
Pour trier en ordre descendant, on ajoute le mot-cl DESC aprs la liste des attributs.
Fonctions sur les chanes de caractres.
LENGTH renvoie le nombre de caractres dune colonne
SUBSTR extrait une sous-chane dans une chane de caractres :
SUBSTR(NOM, 1, 15) extrait les 15 premiers caractres de la chane NOM.
SUBSTR(NOM, LENGTH(NOM)-2, 3) extrait les 3 derniers caractres de la chane NOM.
LIKE permet de rechercher un prol-type dans une chane
NOM LIKE %DE% recherche tous les noms contenant la sous-chane DE
REPLACE permet de remplacer une chane par une autre chane dans une colonne
UPDATE Ecrivain SET NOM=REPLACE(nom, Dupont, Dupond) ;
remplace dans la colonne nom de la table Ecrivain les occurrences de la chane Dupont par la
chane Dupond .
LTRIM et RTRIM permettent de supprimer les blancs parasites en dbut et en n de chane.
UPDATE Ecrivain SET nom=LTRIM(RTRIM(nom)) ;
UPDATE Ecrivain SET nom=LTRIM(nom, 1234567890) ;
supprime toutes les occurrences de ces caractres en dbut de chane.
LPAD et RPAD permettent de formatter une chane en justiant droite ou gauche. La chane est
complte par des blancs, par une chane constante ou le contenu dune colonne.
LPAD(nom, 20) justie droite sur 20 colonnes en compltant par des blancs
LPAD(nom, LENGTH(nom) + 5, nom : ) justie droite sur la longueur du nom + 5 caractres en
compltant par la chane Nom : Dupont Nom : Dupont
LPAD(NOM, LENGTH(NOM) + LENGTH(PRENOM) + 2, PRENOM || , ) justie droite sur la longueur
des 2 colonnes + 2 caractres Dupont, Jules Jules, Dupont
LOWER, UPPER, INITCAP permettent respectivement de mettre une chane en minuscules, majuscules
et le premier caractre de chaque mot en majuscule
36 4 Le langage relationnel SQL
DECODE permet de dnir le transcodage dune valeur numrique en chane de caractres.
SELECT NO_JOUR, DECODE(NO_JOUR, 1, LUNDI, 2, MARDI, 3, MERCREDI, 4, JEUDI, 5,
VENDREDI, 6, SAMEDI, 7, DIMANCHE) FROM MA_TABLE ;
6 SAMEDI si MA_TABLE ne contient quune seule ligne avec 6 dans la colonne NO_JOUR.
ASCII renvoie le code Ascii du premier caractre de la chane passe en paramtre.
Fonctions sur les dates.
SYSDATE retourne la date et lheure courante. SYSDATE ne peut pas tre utilis dans une contrainte
CHECK.
INSERT INTO Commande VALUES (COM01, SYSDATE) ;
TO_CHAR permet de convertir une date en chane de caractres.
SELECT TO_CHAR(SYSDATE, HH24, MI) FROM DUAL ;
TO_DATE permet de convertir une chane de caractres en date.
INSERT INTO Planning VALUES (TO_DATE(15 :30, HH24, MI)) ;
Fig. 3.5: Quelques lments de formats de date.
Fonctions de conversion entre types.
TO_CHAR permet de convertir des valeurs numriques en chane de caractres.
SELECT TO_CHAR(SALAIRE) FROM EMPLOYE ;
SELECT TO_CHAR(SALAIRE, 999999.99) FROM EMPLOYE ;
55 55.00
456 456.00
SELECT TO_CHAR(SURFACE, 9.9999EEEE) FROM POLYGONE ;
123 1.2300E+02
12345 1.2345E+04
Chapitre 3 Langages de bases de donnes 37
TO_NUMBER permet de convertir des chanes de caractres en valeurs numriques. Par exemple, si
ANNEE_DEB et ANNEE_FIN sont des chanes :
SELECT SUM(1000* TO_NUMBER(ANNEE_FIN) - TO_NUMBER(ANNEE_DEB)) FROM EMPLOYE_RECOMPENSE ;
4.3.2 Requtes sur plusieurs tables
Les requtes SQL dcrites dans cette section permettent de manipuler simultanment plusieurs tables et
dexprimer les oprations binaires de lalgbre relationnelle : jointure, produit cartsien, union, intersection
et dirence.
Expression des jointures. La syntaxe pour exprimer des jointures avec SQL est une extension directe
de celle tudie prcdemment dans le cas des slections simples : on donne la liste des tables concernes
dans la clause FROM, et on exprime les critres de rapprochement entre ces tables dans la clause WHERE.
Prenons lexemple de la requte suivante : donner le nom des clients avec le nom des stations o ils
ont sjourn. Le nom du client est dans la table Client, linformation sur le lien client/station dans la
table Sjour. Deux tuples de ces tables peuvent tre joints sils concernent le mme client, ce qui peut
sexprimer laide de lidentiant du client. On obtient la requte :
SELECT nom, station
FROM Client, Sjour
WHERE id = idClient ;
On peut remarquer quil ny a pas dans ce cas dambigut sur le nom des attributs : nom et id viennent
de la table Client, tandis que Station et idClient viennent de la table Sjour. Il peut arriver quun
mme nom dattribut soit partag par plusieurs tables impliques dans une mme jointure. Dans ce cas
on rsout lambigut en prxant lattribut par le nom de la table.
Exemple 30
Acher le nom dune station, son tarif hebdomadaire ; ses activits et leurs prix.
SELECT nomStation, tarif, libell, prix
FROM Station, Activit
WHERE Station.nomStation = Activit.nomStation
Comme il peut tre fastidieux de rpter intgralement le nom dune table, on peut lui associer un
synonyme et utiliser ce synonyme en tant que prxe. La requte prcdente devient par exemple :
SELECT nomStation, tarif, libell, prix
FROM Station S, Activit A
WHERE S.nomStation = A.nomStation ;
Il existe des situations dans lesquelles lutilisation des synonymes est indispensable : celles o lon souhaite
eectuer une jointure dune relation avec elle-mme.
Exemple 31
Soit la requte : Donner les couples de stations situes dans la mme rgion. Ici, toutes les informations ncessaires
sont dans la seule table Station, mais on construit un tuple dans le rsultat avec deux tuples partageant la mme
valeur pour lattribut Rgion.
Tout se passe comme si lon devait faire la jointure entre deux versions distinctes de la table Station. Technique-
ment, on rsout le problme en SQL en utilisant deux synonymes distincts.
SELECT s1.nomStation, s2.nomStation
FROM Station s1, Station s2
WHERE s1.rgion = s2.rgion ;
On peut imaginer que s1 et s2 sont deux curseurs qui parcourent indpendamment la table Station et
permettent de constituer les couples de tuples auxquels on applique la condition de jointure.
Voici dautres exemples de jointures :
Exemple 32
Une jointure sans qualication (sans clause WHERE) est le produit cartsien (cf Q1). Dans une jointure avec
qualication, le produit cartsien est restreint par une combinaison de prdicats de comparaison (cf Q2 Q5).
38 4 Le langage relationnel SQL
Enn, dans une jointure, il est possible de privilgier une table (cf Q6).
Voici les schmas de relation servant de support pour les exemples de requtes :
CREATE TABLE LIVRE
(AUTEUR CHAR (8),
TITRE CHAR (24),
ANNEE SMALLINT,
GENRE CHAR (8),
PRIX DECIMAL (5,2),
CONSTRAINT LIVRE_PK
PRIMARY KEY(AUTEUR, TITRE)) ;
CREATE TABLE ECRIVAIN
(AUTEUR CHAR (8)
CONSTRAINT ECRIVAIN_PK
PRIMARY KEY,
NE-EN SMALLINT,
LIEU CHAR (20),
RAYON SMALLINT ) ;
CREATE TABLE RAYON
(RAYON SMALLINT
CONSTRAINT RAYON_PK
PRIMARY KEY,
SALLE SMALLINT ) ;
Exemples de requtes :
(Q1) SELECT A.auteur, B.lieu
FROM Livre A, Ecrivain B ;
forme le produit cartsien des tables Livre et Ecrivain sur les attributs auteur de Livre et lieu de Ecrivain.
On peut associer un nom abrg (alias) aux noms de table pour allger lcriture des requtes.
(Q2) SELECT A.AUTEUR, A.TITRE, B.RAYON
FROM LIVRE A, ECRIVAIN B
WHERE A.AUTEUR = B.AUTEUR ;
Equi-jointure : liste le titre, lauteur et le rayon de rangement des ouvrages de la bibliothque.
Soit la table OUVRAGE dnie comme :
CREATE TABLE OUVRAGE
(AUTEUR CHAR (8),
TITRE CHAR (24),
NE-EN SMALLINT,
SALLE SMALLINT,
RAYON SMALLINT ) ;
(Q3) SELECT X.AUTEUR, X.TITRE, Y.NE_EN, Z.SALLE, Z.RAYON
FROM LIVRE X, ECRIVAIN Y, RAYON Z
WHERE X.AUTEUR = Y.AUTEUR AND Y.RAYON = Z.RAYON ;
reconstitue la table OUVRAGE partir des tables LIVRE, ECRIVAIN et RAYON.
(Q4) SELECT A.AUTEUR, A.TITRE, A.ANNEE, A.GENRE, A.PRIX, B.NE_EN, B.LIEU, B.RAYON
FROM LIVRE A, ECRIVAIN B
WHERE A.AUTEUR = B.AUTEUR ;
ralise une jointure naturelle.
(Q5) SELECT A.AUTEUR, A.NE_EN, B.AUTEUR
FROM ECRIVAIN A, ECRIVAIN B
WHERE A.NE_EN = B.NE_EN AND A.AUTEUR > B.AUTEUR ;
Chapitre 3 Langages de bases de donnes 39
Une jointure dune table sur elle-mme : liste le nom, la date de naissance des crivains ns la mme anne.
(Q6) SELECT A.RAYON, B.AUTEUR
FROM RAYON A, ECRIVAIN B
WHERE A.RAYON = B.RAYON (+) ;
ralise une jointure dans laquelle on privilgie la table Rayon. Cette jointure ache la liste de tous les rayons de
la bibliothque et les noms dauteurs qui y sont rangs si les rayons ne sont pas vides.
Union, intersection et dirence. Lexpression de ces trois oprations ensemblistes en SQL est
trs proche de lalgbre relationnelle. On construit deux requtes dont les rsultats ont mme arit (mm
nombre de colonnes et mmes types dattributs), et on les relie par un des mots-cls UNION, INTERSECTION
ou EXCEPT.
Exemple 33 (Union)
Donner tous les noms de rgions dans la base.
SELECT region FROM Station
UNION
SELECT region FROM Client ;
Exemple 34 (Intersection)
Donner tous les noms de rgions dans la base.
SELECT region FROM Station
INTERSECT
SELECT region FROM Client ;
Exemple 35 (Dirence)
Donner tous les noms de rgions dans la base.
SELECT region FROM Station
EXCEPT
SELECT region FROM Client ;
4.3.3 Requtes imbriques
On parle de requte imbrique lorsquune requte est faite dans la clause WHERE dune autre requte.
La premire utilisation des sous-requtes est dorir une alternative syntaxique lexpression de jointures.
Les jointures concernes sont celles pour lesquelles le rsultat est constitu avec les attributs provenant
dune seule des deux tables, lautre ne servant que pour exprimer des conditions.
Exemple 36
On veut les noms des stations o ont sjourn des clients parisiens. On peut obtenir ce rsultat avec la jointure
classique :
SELECT station
FROM Sejour, Client
WHERE id = idClient AND ville = Paris ;
Ici, le rsultat, station, provient de la table Sejour. Do lide de sparer la requte en deux parties : (1)
on constitue avec une sous-requte les ids des clients parisiens, puis (2) on utilise ce rsultat dans la requte
principale.
SELECT station
FROM Sejour
WHERE id = idClient IN (SELECT id FROM Client
WHERE ville = Paris) ;
Le mot-cl IN exprime clairement la condition dappartenance de idClient la relation forme par la requte
imbrique.
Voici les conditions que lon peut exprimer sur une relation R construite avec une requte imbrique.
1. EXISTS R. Renvoie TRUE si R nest pas vide, FALSE sinon.
40 4 Le langage relationnel SQL
2. t IN R o t est un tuple dont le type est celui de R. TRUE si t appartient R, FALSE sinon.
3. vcmp ANY R, O cmp est un comparateur SQL (<, >, =, etc.). Renvoie TRUE si la comparaison avec
au moins un des tuples de la relation unaire R renvoie TRUE.
4. vcmp ALL R, O cmp est un comparateur SQL (<, >, =, etc.). Renvoie TRUE si la comparaison avec
tous des tuples de la relation unaire R renvoie TRUE.
De plus, toutes ces expressions peuvent tre prxes par NOT pour obtenir la ngation. Voici quelques
exemples :
Exemple 37
1. O (station, lieu) ne peut-on pas faire de ski ?
SELECT nomStation, lieu
FROM Station
WHERE nomStation NOT IN (SELECT nomStation FROM Activite
WHERE libelle = ski) ;
2. Quelle station pratique le tarif le plus lev ?
SELECT nomStation
FROM Station
WHERE tarif >= ALL (SELECT tarif FROM Station) ;
3. Dans quelle station pratique-t-on une activit au mme prix qu Santalba ?
SELECT nomStation, libelle
FROM Activite
WHERE prix IN (SELECT prix FROM Activite
WHERE nomStation = Santalba)
Sous-requtes corrles .
Les exemples de requtes imbriques donns prcdemment pouvaient tre valus indpendamment de
la requte principale. Cela pourrait permettre au systme (sil le juge ncessaire) dexcuter la requte en
deux phases. Il peut arriver que la sous-requte soit base sur une ou plusieurs valeurs issues des relations
de la requte principale. On parle alors de requtes corrles.
Exemple 38
Quels sont les clients (nom, prnom) qui ont sjourns Santalba ?
SELECT nom, prenom
FROM Client
WHERE EXISTS (SELECT x FROM Sejour
WHERE Station = Santalba)
AND idClient = id)
Le id dans la requte imbrique nappartient pas la table Sejour mais la table Client rfrence dans le FROM
de la requte principale.
4.3.4 Agrgation
Toutes les requtes vues jusqu prsent pouvaient tre considres comme une suite doprations eec-
tues tuple tuple. De mme, le rsultat tait une collection de valeurs issues de tuples individuels. Les
fonctionnalits dagrgation de SQL permettent dexprimer des conditions sur des groupes de tuples, et
de constituer les rsultat par agrgation de valeurs au sein de chaque groupe.
La syntaxe SQL fournit donc :
1. Le moyen de partitionner une relation en groupes selon certains critres.
2. Le moyen dexprimer des conditions sur ces groupes.
3. Des fonctions dagrgation.
Il existe un groupe par dfaut : le relation toute entire. Sans mme dnir de groupe donc, on peut
utiliser les fonctions dagrgation.
Chapitre 3 Langages de bases de donnes 41
Fonctions dagrgation. Ces fonctions sappliquent une colonne, en gnral de type numrique. Ce
sont :
1. COUNT qui compte le nombre de valeurs non nulles.
2. MAX et MIN.
3. AVG qui calcule la moyenne des valeurs de la colonne.
4. SUM qui eectue le cumul.
Exemple 39
SELECT COUNT(nomStation), AVG(tarif), MIN(tarif), MAX(tarif)
FROM Station ;
Remarque importante : on ne peut pas utiliser simultanment dans la clause SELECT des fonctions dagr-
gation et des noms dattributs (sauf dans le cas dun GROUP BY, voir plus loin). Ainsi, la requte suivante
est incorrecte :
SELECT nomStation, AVG(tarif)
FROM Station ;
On peut faire des requtes complexes.
Exemple 40
SELECT SUM (nbPlaces)
FROM Client, Sejour
WHERE nom = Kerouac AND id = idClient ;
Plus gnralement, les fonctions de calcul permettent de raliser un calcul sur un ensemble de valeurs,
rsultat dune question avec ou sans partitionnement.
utilises dans un SELECT sans GROUP BY, le rsultat ne contient quune ligne de valeurs,
utilises dans un SELECT avec GROUP BY, le rsultat contient une ligne de valeurs par partition.
Les fonctions implantes sont :
AVG, STDDEV, VARIANCE : calculent respectivement la moyenne, lcart-type et la variance des valeurs
dune collection de nombres gurant dans une colonne
SELECT AVG (PRIX)
FROM LIVRE ;
donne le prix moyen des ouvrages de la table LIVRE
SUM calcule la somme des valeurs dune collection de nombres
SELECT SUM (PRIX)
FROM LIVRE
WHERE GENRE = ROMAN ;
donne la somme des prix des romans de la table LIVRE
MIN et MAX permettent dobtenir la valeur minimum (resp. maximum) dune collection de valeurs
SELECT MAX (PRIX), GENRE
FROM LIVRE
GROUP BY GENRE ;
donne le prix maximum des ouvrages de la table LIVRE pour chaque genre
COUNT permet de dnombrer une collection de lignes
SELECT COUNT (*)
FROM AUTEUR
WHERE LIEU = PARIS ;
compte le nombre dauteurs de la table AUTEUR ns Paris
42 4 Le langage relationnel SQL
SELECT COUNT (NE_EN)
FROM AUTEUR
WHERE LIEU = PARIS ;
compte le nombre dauteurs de la table AUTEUR ns Paris dont on connat la date de naissance (colonne
not null).
ROUND, TRUNC, FLOOR, CEIL pour arrondir et tronquer
ROUND(123.27, 1) ? 123.3
ROUND(123.22, 1) ? 123.2
ROUND(101.8) ? 102
ROUND(123.27, -2) ? 100
TRUNC(123.33) ? 123
TRUNC(123.567, 2) ? 123.56
TRUNC(123.567, -2) ? 100
FLOOR(128.7) ? 128 /* entier inf */
FLOOR(129.1) ? 129
CEIL (128.7) ? 129 /* entier sup */
CEIL(129.1) ? 130
La clause GROUP BY. Dans les requtes prcdentes, on appliquait la fonction dagrgation lensemble
du rsultat dune requte (donc ventuellement lensemble de la table elle-mme). Une fonctionnalit
complmentaire consiste partitionner ce rsultat en groupes, et appliquer la ou les fonction(s) chaque
groupe.
On construit les groupes en associant les tuples partageant la mme valeur pour une ou plusieurs colonnes.
Exemple 41
Acher les rgions avec le nombre de stations associes
SELECT region, COUNT(nomStation)
FROM Station
GROUP BY region ;
Donc, ici, on constitue un groupe pour chaque rgion. Puis on ache ce groupe sous la forme dun tuple
dans lequel les attributs peuvent tre de deux types :
1. les attributs dont la valeur est constante pour lensemble du groupe, soit prcisment les attributs
du GROUP BY. Dans lexemple prcdent, lattribut est region ;
2. le rsultat dune fonction dagrgation applique au groupe. Dans lexemple, COUNT(nomStation).
Bien entendu, il est possible dexprimer des ordres SQL complexes et dappliquer un GROUP BY dans la
clause select.
Exemple 42
On souhaite consulter le nombre de places rserves par client
SELECT nom, SUM(nbPlaces)
FROM Client, Sejour
WHERE id = idClient
GROUP BY id, nom ;
Chapitre 3 Langages de bases de donnes 43
Linterprtation est simple : (1) on excute dabord la requte SELECT ... FROM ... WHERE, puis (2) on
prend le rsultat et on le partitionne, enn (3) on calcule le rsultat des fonctions.
La clause HAVING Finalement, on peut faire porter des conditions sur les groupes avec la clause HAVING.
La clause WHERE ne peut exprimer des conditions que sur les tuples pris un un.
Exemple 43
On souhaite consulter le nombre de places rserves, par client, pour les clients ayant rserv plus de 10 places.
SELECT nom, SUM(nbPlaces)
FROM Client, Sejour
WHERE id = idClient
GROUP BY nom
HAVING SUM(nbPlaces) >= 10 ;
On voit que la condition porte ici sur une proprit de lensemble des tuples du groupe, et pas de chaque
tuple pris individuellement. La clause HAVING est donc toujours exprime sur le rsultat de fonctions
dagrgation.
4.3.5 Mises--jour
Les commandes de mise--jour (insertion, destruction, modication) sont plus simples que les requtes.
Insertion. Linsertion seectue laide de la commande INSERT dont la syntaxe est la suivante :
INSERT INTO R(A1, A2, ..., AN) VALUES (V1, v2, ..., vn)
R est le nom dune relation, et les A1, ..., An sont les noms des attributs dans lesquels on souhaite
placer une valeur. Les autres attributs seront donc NULL (ou la valeur par dfaut). Tous les attributs
spcis NOT NULL (et sans valeur par dfaut) doivent donc guer dans une clause INSERT.
Les v1, ..., vn sont les valeurs des attributs.
Exemple 44
Insertion dun tuple dans la table Client.
INSERT INTO Client (id, nom, prenom)
VALUES (40, Moriarty, Dean) ;
Donc, lissue de cette assertion, les attributs ville et region seront NULL.
Il est galement possible dinsrer dans une table le rsultat dune requte. Dans ce cas, la partie VALUES
... est remplace par la requte elle-mme.
Exemple 45
On a cr une table Sites(lieu, region) et on souhaite y copier les couples (lieu, region) dj existants dans
la table Station.
INSERT INTO Sites (lieu, region)
SELECT lieu, region FROM Station ;
Bien entendu, le nombre dattributs et le type de ces derniers doivent tre cohrents.
Destruction. La destruction seectue avec la clause DELETE dont la syntaxe est :
DELETE FROM R
WHERE condition ;
R est la table, et condition est toute la condition valide pour une clause WHERE. En dautres termes, si
on eectue, avant la destruction, la requte :
44 4 Le langage relationnel SQL
SELECT * FROM R
WHERE condition ;
on obtient lensemble des lignes qui seront dtruites par DELETE. Procder de cette manire est un des
moyens de sassurer que lon va bien dtruire ce que lon souhaite.
Exemple 46
Destruction de tous les clients dont le nom commence par M :
DELETE FROM Client
WHERE nom LIKE M% ;
Modication. La modication seectue laide de la clause UPDATE. La syntaxe est proche de celle
du DELETE :
UPDATE R SET A1=V1, A2=V2, ..., AN=VN
WHERE condition ;
R est la relation, les Ai sont les attributs, les vi les nouvelles valeurs et condition est toute condition
valide pour la clause WHERE.
Exemple 47
Augmenter le prix des activits de la station Passac de 10%.
UPDATE Activites
SET prix = prix * 1.1
WHERE nomStation = Passac ;
Remarque importante : toutes les mises--jour ne deviennent dnitives qu lissue dune validation par
commit. Entre temps, elles peuvent tre annules par rollback. Nous y reviendrons dans la section sur
la concurrence daccs ??.
Mise en pratique en utilisant PostgreSQL
Se crer un rpertoire BD : mkdir BD
Se placer dans ce rpertoire : cd BD
Utilisation de PostgreSQL
Manuel en ligne http://www.postgresql.org/docs/8.4/static/index.html
Cration dune base de donnes : $ createdb mydb
Si pas de message, cest que a marche.
Une fois quune base de donnes est cre, on peut y accder en utilisant :
lenvironnement de PostgreSQL, avec la commande psql
un environnement graphique comme pgAdmin ou un ODBC ou JDBC
Nous accdons la base mydb par : $ psql mydb.
Les lignes de commandes devraient alors commencer par : mydb=>
Pour avoir de laide sur les commandes PostgreSQL : mydb=> `h
Pour quitter PostgreSQL : mydb=> `q
Crer les tables dont le schma est en p.95 de [Elmasri et Navathe, Fr] -> Voir p.153
Remplir les tables avec les informations en p.97 de [Elmasri et Navathe, Fr]
Eectuer des requtes pour rpondre aux questions suivantes :
Requtes simples
Requte 1 : Chercher la date de naissance et ladresse de tous les employs dont le nom est Bernard
Schmidt.
Chapitre 3 Langages de bases de donnes 45
SELECT date_naiss, adresse
FROM Employe
WHERE Prenom = John AND Nom = Smith ;
Requte 2 : Extraire le nom et ladresse de tous les employs qui travaillent pour le service recherche.
SELECT Nom, adresse
FROM Employe, Service
WHERE Service.Nom_Sce = Recherche AND Service.No_Sce = Employe.NoSce ;
Noms dattributs ambigs
Requte 3 : Pour chaque employ, extraire son prnom et son nom ainsi que le prnom et le nom de
son suprieur immdiat.
SELECT E.Prenom, E.Nom, S.Prenom, S.Nom
FROM Employe AS E, Employe AS S
WHERE E.NoSSSUPER = S.NoSS ;
Clause WHERE non spcie et utilisation de lastrisque
Requte 4 : Slectionner tous les NoSS dans Employe.
SELECT NoSS
FROM Employe ;
Requte 5 : Slectionner toutes les combinaisons de NoSS dEmploye et de Noms dans Service dans la
base de donnes.
SELECT NoSS, Noms_Sce
FROM Employe, Service ;
Requte 6 : Rcuprer les valeurs de tous les attributs des Employe qui travaillent pour le service n5.
SELECT *
FROM Employe
WHERE NoSce = 5 ;
Requte 7 : Rcuprer les valeurs de tous les attributs de chaque Employe et Service pour lequel il
travaille pour tous les employs du service Recherche.
SELECT *
FROM Employe AS E, Service AS S
WHERE Nom_Sce = Recherche AND E.NoSce = S.NoSCE ;
Requte 8 : Engendrer le produit cartsien des relations Employe et Service.
SELECT *
FROM Employe, Service ;
limination des doublons : tables et ensembles
Requte 9 : Extraire le salaire de chaque employ.
SELECT ALL Salaire
FROM Employe ;
Requte 10 : Extraire toutes les valeurs distinctes des salaires des employs.
SELECT DISTINCT Salaire
FROM Employe ;
Requte 11 : Lister tous les numros des projets auxquels participe un employ dont le nom de famille
est Schmidt, que ce soit comme simple employ ou comme responsable du dpartement en charge du
projet.
46 4 Le langage relationnel SQL
(SELECT DISTINCT No_P
FROM Projet, Service, Employe
WHERE NumS = NoSCe AND NoSSDIR = NoSS AND Nom = Schmidt)
UNION
(SELECT DISTINCT NoP
FROM Projet, Travaille_Sur, Employe
WHERE Numero_Projet = No_Projet AND NoSS_Empl = NoSS AND Nom = Schmidt) ;
Slection de sous-chanes laide de motifs et oprateurs arithmtiques
Requte 12 : Extraire les noms et les prnoms de tous les employs qui habitent Les Ulis.
SELECT Prenom, nom
FROM Employe
WHERE Adresse LIKE %Les Ulis% ;
Requte 13 : Extraire les noms et les prnoms de tous les employs ns dans les annes 50.
SELECT Prenom, nom
FROM Employe
WHERE Date_Naiss LIKE __5_______ ;
Requte 14 : Acher les salaires des employs travaillant sur le projet ProduitX une fois augments
de 10%.
SELECT Prenom, nom, 1.1*Salaire as Augmentation
FROM Employe, Travaille_Sur, Projet
WHERE NoSS = NoSS_Empl AND Numero_Projet = No_Projet
AND Nom_Projet = ProduitX ;
Requte 15 : Extraire toutes les donnes relatives aux employs du service 5 dont le salaire est compris
entre 30000 et 40000 e.
SELECT *
FROM Employe
WHERE Salaire BETWEEN 30000 AND 40000 AND NoSce = 5 ;
Tri des rsultats dune requte
Requte 16 : Lister les employs et les projets sur lesquels ils travaillent en les classant par service et,
pour chaque service, en les classant selon lordre alphabtique de leur nom de famille puis de leur prnom.
SELECT Nom_Sce, Nom, Prenom Nom_projet
FROM Service, Employe, Travaille_Sur, Projet
WHERE NoSCE = NoSce AND NoSS=NoSS_Empl AND Numero_Projet = No_Projet
ORDER BY Nom, Prenom ;
Exercices sur les requtes en SQL
En utilisant les tables sur les employs et les projets.
Requte 1 : Chercher la date de naissance et ladresse de tous les employs dont le nom est John B.
Smith.
Requte 2 : Chercher le nom et ladresse de tous les employs qui travaillent pour le dpartement
recherche.
Requte 3 : Pour tous les projets situs Staord, chercher les numros de projet, le dpartement de
supervision et les nom, adresse et date de naissance des managers de ces dpartements.
Requte 4 : Pour chaque employ, chercher les prnoms et noms de cet employ et les prnom et nom
de son suprieur immdiat.
Requte 5 : Slectionner tous les EMPLOYEE SSNS de la base.
Requte 6 : Slectionner toutes les combinaisons de EMPLOYEE SSNS et DEPARTMENT DNAME de la base.
Chapitre 3 Langages de bases de donnes 47
Requte 7 : Chercher toutes les valeurs dattribut des tuples de EMPLOYEE qui travaillent dans le dpar-
tement 5.
Requte 8 : Slectionner tous les attributs dun EMPLOYEE et les attributs du DEPARTMENT pour lequel il
travaille, et ceci pour tous les employs du dpartement de recherche.
Requte 9 : Chercher le produit cartsien des relations EMPLOYEE et DEPARTMENT.
Requte 10 : Chercher le salaire de tous les employs.
Requte 11 : Chercher toutes les valeurs distinctes de salaires des employs.
Requte 12 : Chercher tous les numros de projets qui impliquent un employ dont le nom est Smith,
soit en tant que travailleur dans ce projet ou en tant que manager du dpartement qui contrle ce projet.
Requte 13 : Chercher tous les employs dont ladresse est Houston, Texas.
Requte 14 : Chercher tous les employs ns durant les annes 50.
Requte 15 : Donner le salaire rsultant dune hausse de 10% de tous les employs travaillant pour le
projet Product X.
Requte 16 : Chercher tous les employs dans le dpartement 5 dont le salaire est compris entre $30 000
et $40 000.
Requte 17 : Chercher les employs et les projets sur lesquels ils travaillent, tris par dpartement et,
lintrieur de chaque dpartement, tris par ordre alphabtique sur les noms et les prnoms.
Requte 18 : Reformuler la requte 12 en utilisant des requtes imbriques.
Requte 19 : Chercher les noms de tous les employs dont le salaire est plus grand que le salaire de tous
les employs dans le dpartement 5.
Requte 20 : Donner le salaire rsultant dune hausse de 10% de tous les employs travaillant pour le
projet Product X.
Requte 21 : Chercher le nom des employs qui ont un dependent de mme prnom et de mme sexe
que lui (ou elle).
Requte 22 : Chercher le nom des employs qui travaillent sur tous les projets superviss par le dpar-
tement 5.
Requte 23 : Reformuler la requte 21 : (Chercher le nom des employs qui ont un dependent de mme
prnom et de mme sexe que lui (ou elle)), en utilisant un EXISTS.
Requte 24 : Chercher le nom des employs qui nont pas de dependent.
Requte 25 : Chercher le nom des managers qui ont au moins un dependent.
Requte 26 : Chercher le numro de scurit sociale de tous les employs qui travaillent sur le projet 1,
2 ou 3.
Requte 27 : Chercher le nom des employs qui nont pas de suprieur.
Requte 28 : Trouver le somme des salaires de tous les employs, le salaire maximal, le salaire minimal
et le salaire moyen.
Requte 29 : Trouver le somme des salaires de tous les employs du dpartement de recherche, de mme
que le salaire maximal, le salaire minimal et le salaire moyen dans ce dpartement.
Requte 30 : Trouver le nombre total demploys dans la compagnie.
Requte 31 : Trouver le nombre total demploys dans le dpartement de recherche.
Requte 32 : Trouver le nombre de salaires distincts dans la base.
Requte 33 : Pour chaque dpartement, trouver le numro de dpartement, le nombre demploys dans
le dpartement et leur salaire moyen.
Requte 34 : Pour chaque projet, trouver le numro de projet, le nombre demploys travaillant sur ce
projet.
48 4 Le langage relationnel SQL
Requte 35 : Pour chaque projet sur lequel plus de deux employs travaillent, chercher le numro de
projet, le nom du projet, et le nombre demploys travaillant sur ce projet.
Requte 36 : Pour chaque projet, chercher le numro de projet, le nom du projet, et le nombre demploys
du dpartement 5 travaillant sur ce projet.
Requte 37 : Pour chaque dpartement qui a plus de 5 employs, trouver le numro du dpartement et
le nombre de ses employs gagnant plus que $40 000 par an.
4.4 Le DDL (Data Description Language) en SQL
On se place dans la situation dun informaticien connect une machine sur laquelle tourne un SGBD
grant une base de donnes.
Le principal lment dun tel environnement est le schma consistant principalement en un ensemble de
tables relatives une mme application. Il peut y avoir plusieurs schmas dans une mme base : par
exemple on peut trs bien faire coexister le schma Ociel des spectacles et le schma Agence de
voyages . Il faut donc distinguer linstance de schma de la base de donnes qui est un sur-ensemble.
Outre les tables, un schma peut comprendre des vues, des contraintes de dirents types, des triggers
( Rexes ) qui sont des procdures dclenches par certains vnements, enn des spcications de
stockage et/ou dorganisation physique (comme les index) qui ne sont pas traites dans ce chapitre.
4.4.1 Cration de schmas
Un schma est lensemble des dclarations dcrivant une base de donnes au niveau logique : tables, vues,
domaines, etc. On cre un schma en lui donnant un nom, puis en donnant les listes des commandes (de
type CREATE en gnral) crant les lments du schma. Voici par exemple le squelette de la commande
de cration du schma Agence de voyages .
CREATE SCHEMA agence_de_voyage
CREATE TABLE Station (...
CREATE TABLE Client (...
...
CREATE VIEW ...
...
CREATE ASSERTION ...
...
CREATE TRIGGER ...
...
Deux schmas dirents sont indpendants : on peut crer deux tables ayant le mme nom. Bien entendu,
on peut modier un schma en ajoutant ou en supprimant des lments. La modication a lieu dans le
schma courant, que lon peut modier avec la commande SET SCHEMA. Par exemple, avant de modier
la table FILM, on excute :
SET SCHEMA officiel_desspectacles
Quand on souhaite accder une table qui nest pas dans le schma courant (par exemple dans un ordre
SQL), il faut prxer le nom de la table par le nom du schma.
SELECT * FROM officiel_des_spectacles.film
La commande CREATE TABLE est utilise pour dnir une nouvelle relation en lui donnant un nom et en
spciant ses attributs et ses contraintes. Les attributs sont spcis en premier, et on leurs donne un
nom, un type de donnes pour spcier leur domaine et toutes contraintes attaches (par exemple NOT
NULL). Les cls, contraintes dentit et contraintes dintgrit rfrentielle peuvent tre spcies - dans
la commande CREATE TABLE - aprs la dclaration des attributs, ou bien elles peuvent tre ajoutes plus
tard en utilisant des commandes ALTER TABLE.
Chapitre 3 Langages de bases de donnes 49
Exemple 48
CREATE TABLE EMPLOYEE
(FNAME VARCHAR(15) NOT NULL
MINIT CHAR,
LNAME VARCHAR(15) NOT NULL,
SSN CHAR(9) NOT NULL,
BDATE DATE,
ADDRESS VARCHAR(30),
SEX CHAR,
SALARY DECIMAL(10,2)
SUPERSSN CHAR(9),
DNO INT NOT NULL,
PRIMARY KEY (SSN)
FOREIGN KEY (SUPERSSN) REFERENCES EMPLOYEE(SSN)
FOREIGN KEY (DNO) REFERENCES DEPARTMENT(DNUMBER)
Identicateurs. Ils doivent tre de longueur maximale de 30 caractres (Oracle).
Types de donnes et domaines en SQL. Les types de donnes disponibles incluent les nombres, les
chanes de caractres, les chanes de bits, la date et le temps.
Les types de nombres.
Ils incluent les entiers de direntes tailles (INTEGER ou INT, et SMALLINT), et les rels de prcisions va-
riables (FLOAT, REAL, DOUBLE PRECISION). Les nombres formats peuvent tre dclars par DECIMAL(i, j)
ou DEC(i, j) ou NUMERIC(i, j) o i, la prcision, est le nombre total de chires et j, lchelle, est le nombre
de chires aprs la virgule.
Les types chanes de caractres.
Ils sont soit de longueur xe - CHAR(n) ou CHARACTER(n)-, o n est le nombre de caractres, soit de
longueur variable - VARCHAR(n) ou CHAR VARYING(n) ou CHARACTER VARYING(n) -, o n est le nombre
maximal de caractres.
Les types chanes de bits.
Ils sont soit de longueur xe - BIT(n) -, o n est le nombre de bits, soit de longueur variable - BIT
VARYING(n) -, o n est le nombre maximal de bits. La valeur par dfaut pour n est de 1.
Les BLOBs (Binary Long Object).
Avec le dveloppement du multimdia, la plupart des SGBD propose un type de donnes qui permet
de stocker des objets binaires de grande taille (documents, image, son, vido, ...). Actuellement deux
stratgies sopposent :
1. On stocke dans la BD la rfrence du chier qui contient le BLOB.
2. On stocke lobjet directement dans une colonne de la BD.
La solution 1 fournit en principe un temps daccs plus rapide au BLOB.
La solution 2 a lavantage de la portabilit en cas de dplacement des chiers et/ou de changement de
plateforme.
Les types de donnes binaires (image, son) sont :
RAW (jusqu 2000 bytes),
LONG RAW (jusqu 2 giga bytes)
Le type date.
Oracle alloue 7 caractres pour un attribut de type DATE. Oracle utilise ce type pour stocker la date et
lheure. Le format par dfaut est : jj-mmm-aa (exemple : 01-JAN-94)
50 4 Le langage relationnel SQL
4.4.2 Contraintes et assertions
XXX A FAIRE
4.4.3 Vues
XXX A FAIRE
4.4.4 Triggers
XXX A FAIRE
4.4.5 Les droits daccs aux donnes
Laccs une base de donnes est restreint, pour des raisons de scurit, des utilisateurs connus du
SGBD et identis par un nom et un mot de passe. Chaque utilisateur se voit attribuer certains droits
sur les schmas et les tables de chaque schma.
La connexion se fait soit dans le cadre dun programme, soit interactivement par une commande du type :
CONNECT utilisateur
Suivies de lentre du mot de passe demand par le systme. Une session est alors ouverte pour laquelle
le SGBD connat lID de lutilisateur courant. Les droits de cet utilisateur sont alors les suivants :
1. Tous les droits sur les lments du schma comme les tables ou les vues des chmas que lutilisateur
a lui-mme cr. Ces droits concernent aussi bien la manipulation des donnes que la modication
ou la destruction des lments du schma.
2. Les droits sur les lments dun schma dont on nest pas propritaire sont accords par le propri-
taire du schma. Par dfaut, on na aucun droit.
En tant que propritaire dun schma, on peut donc accorder des droits dautres utilisateurs sur ce
schma ou sur des lments de ce schma. SQL2 dnit 6 types de droits. Les quatre premiers portent
sur le contenu dune table, et se comprennent aisment.
1. Insertion ((INSERT).
2. Modication (UPDATE).
3. Recherche (SELECT).
4. Destruction (DELETE).
Il existe deux autres droits :
1. REFERENCES donne le droit un utilisateur non propritaire du schma de faire rfrence une
table dans une contrainte dintgrit.
2. USAGE permet un utilisateur non propritaire du schma dutiliser une dnition (autre quune
table ou une assertion) du schma.
Les droits sont accords par la commande GRANT dont la syntaxe est :
GRANT <privilege>
ON <element du schma>
TO utilisateur>
[WITH GRANT OPTION] ;
Bien entendu, pour accorder un privilge, il faut en avoir le droit, soit parce que lon est propritaire de
llment du schma, soit parce que le droit a t accord par la commande WITH GRANT OPTION.
Exemple 49
Par exemple, pour permettre Marc de consulter les lms :
GRANT SELECT ON Film TO Marc ;
Chapitre 3 Langages de bases de donnes 51
On peut dsigner tous les utilisateurs avec le mot-cl PUBLIC, et tous les privilges avec lexpression ALL
PRIVILEGES.
Exemple 50
GRANT ALL PRIVILEGES ON Film TO Marc ;
On supprime un droit avec la commande REVOKE dont la syntaxe est semblable celle de GRANT.
Exemple 51
REVOKE SELECT ON Film FROM Marc ;
52 Chap.4 : Pratique des SGBD
Chapitre 4
Pratique des SGBD
Sommaire
1 Exemples de SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.1 Perspectives historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.2 ORACLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.3 Microsoft Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2 Techniques doptimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3 Techniques daccs partags : le contrle de concurrence . . . . . . . . . . . 54
3.1 Problmes potentiels et notions de base . . . . . . . . . . . . . . . . . . . . . . 54
3.2 Techniques de contrle de concurrence . . . . . . . . . . . . . . . . . . . . . . . 62
3.3 La gestion des transactions en SQL . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4 Le contrle de concurrence sous Oracle . . . . . . . . . . . . . . . . . . . . . . . 67
4 Techniques de rcupration derreur . . . . . . . . . . . . . . . . . . . . . . . 69
4.1 Les mcanismes utiliss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Les bancs de mesure des performances ("benchmarks") . . . . . . . . . . . 71
6 Scurit et autorisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7 Linterface C/SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1 Un exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2 Autres commandes SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8 Les environnements de programmation dapplications sur les bases de
donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1 La "programmation visuelle" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2 Langages de quatrime gnration . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.3 Les interfaces au standard SQL et la portabilit . . . . . . . . . . . . . . . . . . 80
8.4 Les ateliers de gnie logiciel (AGL / CASE) . . . . . . . . . . . . . . . . . . . . 81
54 1 Exemples de SGBD
1. Exemples de SGBD
1.1 Perspectives historiques
1.2 ORACLE
1.3 Microsoft Access
2. Techniques doptimisation
3. Techniques daccs partags : le contrle de concurrence
Les bases de donnes sont le plus souvent accessibles plusieurs utilisateurs qui peuvent rechercher, crer,
modier ou dtruire les informations contenues dans la base. Ces accs simultans des informations
partages soulvent de nombreux problmes de cohrence : le systme doit pouvoir grer le cas de deux
utilisateurs accdant simulatment une mme information en vue deectuer des mises jour. Plus
gnralement, on doit savoir contrler les accs concurrents de plusieurs programmes complexes eectuant
de nombreuses lectures/critures.
Un SGBD doit garantir que lexcution dun programme eectuant des mises jour dans un contexte
multi-utisateur seectue correctement . Bien entendu la signication du correctement doit tre
dnie prcisment, de mme que les techniques assurant cette correction : cest lobjet du contrle de
concurrence.
3.1 Problmes potentiels et notions de base
Commenons ds maintenant par un exemple illustrant le problme. Supposons que lapplication Ociel
des spectacles propose une rservation des places pour une sance. Voici le programme de rservation
(simpli) :
Algorithme 1 : Algorithme de rservation
Programme RESERVATION
Donnes : Une sance c
Le nombre de places souhait NbPlaces
Le client c
dbut
Lire la sance s
si (nombre de places libres > NbPlaces) alors
Lire le compte du client c
Dbiter le compte du client c
Soustraire NbPlaces au nombre de places vides
Ecrire la sance s
Ecrire le compte du client c
n Si
n
Du point de vue du contrle de concurrence, des instructions comme les tests, les boucles ou les calculs
nont pas vraiment dimportance. Ce qui compte, ce sont les accs aux donnes. Ces accs sont de deux
types
1. Les lectures, que lon notera partir de maintenant par r.
Chapitre 4 Pratique des SGBD 55
2. Les critures que lon notera w.
La nature des informations manipules est galement indirente : les rgles pour le contrle de la concur-
rence sont les mmes pour des lms, des comptes en banques, des stocks industriels, etc. Tout ceci mne
reprsenter un programme de manire simplie comme une suite de lectures et dcritures oprant sur
des donnes dsignes abstraitement par des variables (gnralement x, y, z, ...).
Le programme RESERVATION se prsente donc simplement par la squence :
r[s] r[c] w[c] w[s]
3.1.1 Excutions concurrentes : srialisabilit
On va maintenant sintresser aux excutions dun programme dans un contexte multi-utilisateur. Il
pourra donc y avoir plusieurs excutions simultanes du mme programme : pour les distinguer, on
emploie simplement un indice : on parlera du programme P
1
et du programme P
2
.
Exemple
Voici un exemple de deux excutions concurrentes du programme RESERVATION : P
1
et P
2
. Chaque
programme veut rserver des places dans la mme sance, pour deux clients distincts c
1
et c
2
.
r
1
(s) r
1
(c
1
) r
2
(s) r
2
(c
2
) w
2
(s) w
2
(c
2
) w
1
(s) w
1
(c
1
)
Donc on eectue dabord les lectures pour P
1
, puis les lectures pour P
2
, enn les critures pour P
2
et P
1
dans cet ordre.
1. Il reste 50 places libres pour la sance s.
2. P
1
veut rserver 5 places pour la sance s.
3. P
2
veut rserver 2 places pour la sance s.
Voici le droulement imbriqu des deux excutions P
1
(s, 5, c
1
) et P
2
(s, 2, c
2
), en supposant que la
squence des oprations est celle donne ci-dessus. On se concentre pour linstant sur les volutions
du nombre de places vides.
1. P
1
lit s et c
1
. Nb places vides : 50.
2. P
2
lit s et c
2
. Nb places vides : 50.
3. P
2
crit s avec nb places = 50 2 = 48.
4. P
2
crit le nouveau compte de c
2
.
5. P
1
crit s avec nb places = 50 5 = 45.
6. P
1
crit le nouveau compte de c
1
.
la n de lexcution, il y a un problme : il reste 45 places vides sur les 50 initiales alors que 7 places
ont eectivement t rserves et payes. Le problme est clairement issu dune mauvaise imbrication
des oprations de P
1
et P
2
: P
2
lit et modie une information que P
1
a dj lue en vue de la modier.
Ce genre danomalie est videmment fortement indsirable. Une solution brutale est dexcuter en
srie les programmes : on bloque un programme tant que le prcdent na pas ni de sexcuter.
Exemple Excution en srie de P
1
et P
2
r
1
(s) r
1
(c) w
1
(s) w
1
(c) r
2
(s) r
2
(c) w
2
(s) w
2
(c)
On est assur dans ce cas quil ny a pas de problme : P
2
lit une donne crite par P
1
qui a ni de
sexcuter et ne crera donc plus dinterfrence.
Cela tant cette solution de concurrence zro nest pas viable : on ne peut se permettre de bloquer tous
les utilisateurs sauf un, en attente dun programme qui peut durer extrmement longtemps. Heureusement
lexcution en srie est une contrainte trop forte, comme le montre lexemple suivant.
Exemple Excution imbrique de P
1
et P
2
56 3 Techniques daccs partags : le contrle de concurrence
r
1
(s) r
1
(c
1
) w
1
(s) r
2
(c
2
) w
2
(s) w
1
(c
1
) w
2
(c
2
)
Suivons pas pas lexcution :
1. P
1
lit s et c
1
. Nb places vides : 50.
2. P
1
crit s avec nb places = 50 5 = 45.
3. P
2
lit s. Nb places vides : 45.
4. P
2
lit c
2
.
5. P
2
crit s avec nb places = 45 2 = 43.
6. P
1
crit le nouveau compte du client c
1
.
7. P
2
crit le nouveau compte du client c
2
.
Cette excution est correcte : on obtient un rsultat strictement semblable celui issu dune excution
en srie. Il existe donc des excutions imbriques qui sont aussi correctes quune excution en srie
et qui permettent une meilleure concurrence. On parle dexcutions srialisables pour indiquer
quelles sont quivalentes des excutions en srie. Les techniques qui permettent dobtenir de telles
excutions relvent de la srialisabilit.
3.1.2 Transactions
Le fait de garantir une imbrication correcte des excutions de programmes concurrents serait susant
dans lhypothse o tous les programmes terminent normalement en validant les mises jour eectues.
Malheureusement ce nest pas le cas : il arrive que lon doive annuler les oprations dentres sorties
eectues par un programme. On peut envisager deux cas :
1. Un problme matriel ou logiciel entrane linterruption de lexcution.
2. Le programme choisit lui-mme dannuler ce quil a fait.
Imaginons que le programme de rservation soit interrompu aprs avoir excut les E/S suivantes :
r
1
(s) r
1
(c
1
) w
1
(s)
La situation obtenue nest pas satisfaisante : on a diminu le nombre de places libres, sans dbiter le
compte du client. Il y a l une incohrence regrettable que lon ne peut corriger que dune seule manire :
en annulant les oprations eectues.
Dans le cas ci-dessus, cest simple : on annule w
1
(s). Mais la question plus gnrale est : jusquo doit-on
annuler quand un programme a dj eectu des centaines, voire des milliers doprations ? Rappelons
que lobjectif, cest de ramener la base dans un tat cohrent. Or le systme lui-mme ne peut pas
dterminer cette cohrence.
Tout SGBD digne de ce nom doit donc orir un utilisateur ou un programme dapplication la
possibilit de spcier les suites dinstructions qui forment un tout, que lon doit valider ensemble ou
annuler ensemble (on parle datomicit).
En pratique, on dispose des deux instructions suivantes :
1. La validation ( commit en anglais). Elle consiste rendre les mises jour permanentes.
2. Lannulation ( rollback en anglais). Elle annule les mises jour eectues.
Ces instructions permettent de dnir la notion de transaction.
Chapitre 4 Pratique des SGBD 57
Dnition 4.1 (Transaction)
Une transaction est lensemble des instructions sparant un commit ou un rollback du commit ou du
rollback suivant.
1. Quand une transaction est valide (par commit), toutes les oprations sont valides ensemble, et on
ne peut plus en annuler aucune. En dautres termes les mises jour deviennent dnitives.
2. Quand une transaction est annule par rollback ou par une panne, on annule toutes les oprations
depuis le dernier commit ou rollback, ou depuis le premier ordre SQL sil ny a ni commit ni rollback.
Il est de la responsabilit du programmeur de dnir ses transactions de manire garantir que la base
est dans un tat cohrent au dbut et la n de la transaction, mme si on passe invitablement par des
tats incohrents dans le courant de la transaction. Ces tats incohrents transitoires seront annuls par
le systme en cas de panne.
Exemple
Les deux premires transactions ne sont pas correctes, la troisime lest (C signie commit, et R
rollback).
1. r(s) r(c) w(s) C w(c)
2. r(s) r(c) w(s) R w(c) C
3. r(s) r(c) w(s) w(c) C
Du point de vue de lexcution concurrente, cela soulve de nouveaux problmes qui sont illustrs ci-
dessous.
3.1.3 Interfrences possibles entre transactions
Il existe quatre types danomalies transactionnelles :
Lanomalie la plus grave est la lecture impropre (lecture sale ou dirty read) : elle se produit lorsquune
transaction lit des donnes qui nont pas encore t valides.
Est aussi grave lanomalie dcriture impropre (criture sale ou dirty write) : elle se produit lorsquune
transaction valide une criture dune autre transaction alors que celle-ci va lannuler par un rollback.
Suit lanomalie de lecture non rptable (non repeatable read) : deux lectures successive des mmes
donnes ne produisent pas le mme rsultat dans la mme ligne.
Enn la lecture fantme (phantom read) est une anomalie qui se produit lorsque des donnes nouvelles
apparaissent ou disparaissent dans des lectures successives.
Fig. 4.1: criture incohrente ( gauche). Lecture incohrente ( droite).
3.1.3.1 criture incohrente ( dirty write ). Une 1re transaction modie le crdit C dun
compte. Une 2me lit C dans ce nouvel tat, puis, constatant que la provision est susante, modie le
58 3 Techniques daccs partags : le contrle de concurrence
dbit D du compte. Mais la 1re fait un "rollback". La donne D a dsormais une valeur qui ne satisfait
plus la contrainte dintgrit D =< C cest dire que le solde est ngatif !
3.1.3.2 Lecture incohrente ( dirty read ). Une 1re transaction, pour faire un virement entre
deux comptes A et B, qui satisfait la contrainte dintgrit "somme A+B invariante", commence par
dbiter A. Juste ce moment une 2me lit A puis B et trouve A+B diminu !
Exemple de lecture impropre
Lutilisateur 1 ajoute 10 places et annule sa transaction, tandis que lutilisateur 2 veut 7 places si elles
sont disponibles...
Fig. 4.2: Exemple de lecture impropre.
Et les donnes qui sont manipules : voir gure 4.3.
Fig. 4.3: Donnes manipules lors des transactions avec lecture impropre.
Le temp dun update avort, la transaction 2 a lu des informations quelle naurait jamais d voir et en
a tir la conclusion quelle pouvait servir les places... Conclusion surbooking !
3.1.3.3 Exemple de lecture non rptable Cas o notre oprateur dsire toutes les places dun vol
si il y en plus de 4...
Et les donnes qui sont manipules : voir gure 4.5.
Notre utilisateur 2 voulait au moins 4 places et en reu 2... Conclusion, vous avez perdu un client !
3.1.3.4 Exemple de lecture fantme Notre utilisateur 2, dsire nimporte quel vol pas cher pour
emmener son quipe de foot (soit 11 personnes) une destination quelconque.
Et les donnes qui sont manipules : voir gure 4.7.
Chapitre 4 Pratique des SGBD 59
Fig. 4.4: Exemple de lecture non rptable.
Fig. 4.5: Donnes manipules lors des transactions avec lecture non rptable.
Fig. 4.6: Exemple de lecture fantme.
11 places ont t volatilis du vol AF 111 et cest comme cela quun certain t, des avions dAir France
volaient vide avec toutes les places rserves ! ! ! (Histoire hlas vridique due un bug du service
informatique de rservation ! ! !)
3.1.4 Excutions concurrentes : recouvrabilit
Revenons maintenant la situation o plusieurs utilisateurs accdent simultanment aux mmes donnes
et considrons limpact de la possibilit qua chaque utilisateur de valider ou dannuler ses transactions.
A nouveau, plusieurs problmes peuvent survenir. Le premier est li la recouvrabilit des transactions
60 3 Techniques daccs partags : le contrle de concurrence
Fig. 4.7: Donnes manipules lors des transactions avec lecture fantme.
et illustr par lexemple suivant :
Exemple Excution recouvrables
r
1
(s) r
1
(c
1
) w
1
(s) r
2
(s) r
2
(c
2
) w
2
(s) w
2
(c
2
) C
2
w
1
(c
1
) R
1
Consquence sur lexemple : le nombre de places disponibles a t diminu par T
1
et repris par T
2
,
avant que T
1
nannule ses rservations. Le nombre de siges rserv sera plus grand que celui des
clients ayant valid leur rservation.
Le problme ici vient du fait que la transaction T
1
est annule aprs que la transaction T
2
a lu une
information mise jour par T
1
, manipul cette information et eectu des MAJ pour son propre compte,
puis valid. On parle de lectures sales ( dirty read , en anglais) pour dsigner laccs par une
transaction des MAJ non encore valides dune autre transaction. Ici le problme est de plus agrav
par le fait que T
1
annule la MAJ qui a fait lobjet dune lecture sale .
Pour annuler proprement T
1
, il faudrait annuler en plus les mises jour de T
2
, ce qui nest pas possible
puisque un commit a t fait par cette dernire : on parle alors dexcution non recouvrable.
Une excution non-recouvrable est viter absolument puisquelle introduit un conit insoluble entre les
rollback eectus par une transaction et les commit dune autre. On pourrait penser interdire une
transaction T
2
ayant eectu des dirty read dune transaction T
1
de valider avant T
1
. On accepterait alors
la situation suivante :
Exemple Annulations en cascade
r
1
(s) r
1
(c
1
) w
1
(s) r
2
(s) r
2
(c
2
) w
2
(s) w
2
(c
2
) w
1
(c
1
) R
1
Ici, le rollback de T
1
intervient sans que T
2
nait fait sa validation. Il faut alors imprativement
que le systme eectue galement un rollback de T
2
pour assurer la cohrence de la base : on parle
dannulations en cascade (noter quil peut y avoir plusieurs transactions annuler).
Quoique acceptable du point de vue de la cohrence de la base, ce comportement est dicilement envi-
sageable du point de vue de lutilisateur qui voit ses transactions interrompues sans aucune explication
lie ses propres actions. Donc il faut tout simplement interdire les dirty read.
Cela laisse encore une dernire possibilit danomalie qui fait intervenir la ncessit dannuler les critures
eectues par une transaction. Imaginons quune transaction T ait modif la valeur dune donne d, puis
quun rollback intervienne. Dans ce cas il est ncessaire de restaurer la valeur quavait d avant le dbut de
la transaction : on parle dimage avant pour cette valeur. Outre le problme de connatre cette image
avant, cela soulve des problmes de concurrence illustr ci-dessous.
Chapitre 4 Pratique des SGBD 61
Exemple Excution non stricte
r
1
(s) r
1
(c
1
) r
2
(s) w
1
(s) w
1
(c
1
) r
2
(c
2
) w
2
(s) C
1
w
2
(c
2
) R
2
Ici il ny a pas de dirty read, mais une criture sale (dirty write). En eet, T
1
a valid aprs que
T
2
ait crit dans s. Donc la validation de T
1
enregistre la mise jour de T
2
alors que celle-ci sapprte
annuler ses mises jour par la suite.
Au moment o T
2
va annuler, le gestionnaire de transaction doit remettre la valeur du tuple s connue
au dbut de la transaction : ce qui revient annuler la mise jour de T
1
.
Autre exemple :
Exemple
Cette fois, cest T
1
qui annule et T
2
qui valide.
r
1
(s) r
1
(c
1
) r
2
(s) w
1
(s) w
1
(c
1
) r
2
(c
2
) w
2
(s) R
1
w
2
(c
2
) C
2
Que se passe-t-il au moment de lannulation de T
1
? On devrait restaurer limage avant connue de T
1
,
mais cela revient annuler la mise jour de T
2
.
En rsum, on distingue trois niveaux de recouvrabilit selon le degr de contrainte impos au systme :
1. Recouvrabilit : on ne doit pas avoir annuler une transaction dj valide.
2. Annulation en cascade : un rollback sur une transaction ne doit pas entraner lannulation
dautres transactions.
3. Recouvrabilit stricte : deux transactions ne peuvent pas accder simultanment en criture
la mme donne, sous peine de ne pouvoir utiliser la technique de rcupration de limage avant.
On peut avoir des transactions srialisables et non recouvrables et rciproquement. Le niveau maximal
de cohrence oert par un SGBD assure la srialisabilit des transactions et la recouvrabilit stricte. Cela
dnit un ensemble de bonnes proprits pour une transaction qui est souvent dsign par lacronyme
ACID.
3.1.5 Le cahier des charges : une base ACID
Cela dnit un ensemble de bonnes proprits pour une transaction, qui est souvent dsigne par
lacronyme ACID, pour :
Atomicit. Soit toutes les actions dune transaction sont excutes, soit aucune ne lest.
Lutilisateur ne doit pas avoir grer les cas dinterruption dune transaction quelque soit sa cause :
erreur, panne, ...
Cohrence. Une transaction est un ensemble de mises jour entre deux tats cohrents de la base par
rapport des contraintes dintgrit.
Le programmeur dapplication est essentiellement le garant de cette proprit.
Isolation. Le rsultat dune transaction doit tre comparable celui produit dans un environnement
mono-utilisateur.
Lutilisateur ne doit pas avoir prendre en compte les interactions avec dautres programmes pour
crire ses procdures de traitement.
Durabilit. Une fois quune transaction est termine, ses eets doivent persister malgr les pannes ou
les tout autre problme rencontr par le SGBD.
Lutilisateur ne doit pas avoir prendre en compte ce qui peut se passer aprs la n (normale) dune
transaction.
Il reste maintenant tudier les techniques mises en uvre pour assurer ces bonnes proprits.
62 3 Techniques daccs partags : le contrle de concurrence
3.2 Techniques de contrle de concurrence
Le contrle de concurrence est la partie de lactivit dun SGBD qui consiste ordonner lexcution
des transactions de manire viter les anomalies prsentes prcdemment.
Il existe deux types de mthodes pour contrler la concurrence :
1. Contrle continu : on vrie au fur et mesure de lexcution des oprations que le critre de
srialisabilit est bien respect. Ces mthodes sont dites pessimistes : elles reposent sur lide que
les conits sont frquents et quil faut les traiter le plus tt possible.
2. Contrle par certication : cette fois, on se contente de vrier la srialisabilit quand la tran-
saction sachve. Il sagit dune approche dite optimiste : on considre que les conits sont rares
et que lon peut accepter de r-excuter les quelques transactions qui posent problmes.
La premire approche est la plus frquente. le mcanisme adopte est celui du verrouillage. Le principe
est simple : on bloque laccs une donne ds quelle est lue ou crite par une transaction ( pose de
verrou ) et on libre cet accs quand la transaction se termine par commit ou rollback ( libration du
verrou ).
Si tout accs en lecture ou en criture pose un verrou bloquant les autres transactions, les anomalies ne
peuvent se produire. Cependant, le blocage systmatique des transactions est une contrainte trop forte
qui bloque sans ncessit des transactions inoensives. Il faut donc trouver une solution plus souple. On
peut en fait considrer deux critres : le degr de restriction et la granularit du verrouillage (i.e. le niveau
de la ressource laquelle il sapplique : tuple, page, table, etc.). Il existe essentiellement deux degrs de
restriction :
1. Le verrou partag ( shared lock ) est typiquement utilis pour permettre plusieurs transactions
concurrentes de lire la mme ressource.
2. Le verrou exclusif ( eXclusive lock ) rserve la ressource en criture la transaction qui a pos
le verrou.
Ces verrous sont poss de manire automatique par le SGBD en fonction des oprations eectues par les
transactions ou les utilisateurs. Mais il est galement possible de demander explicitement le verrouillage
de certaines ressources.
Il est important dtre conscient dune part de la politique de verrouillage pratique par un SGBD, dautre
part de limpact du verrouillage explicite dune ressource. Le verrouillage inuence considrablement les
performances dune BD soumises un haut rgime transactionnel.
3.2.1 Une approche pessimiste : le verrouillage deux phases
Un protocole de verrouillage sans aucune contrainte sur lallocation des verrous, ne permet pas de garantir
la proprit de srialisabilit. De nombreux protocoles ont t proposs, le plus classique tant le protocole
de verrouillage deux phases.
Le protocole de verrouillage deux phases peut essentiellement se rsumer : pour une transaction,
aucune action de verrouillage ne peut succder une libration de verrou.
Le verrouillage deux phases est le protocole le plus rpandu pour assurer des excutions concurrentes
correctes. On utilise des verrous en lecture qui seront nots rl (comme read lock) dans ce qui suit, et des
verrous en critures nots wl (comme write lock). Donc rl
i
[x] indique par exemple que la transaction i
a pos un verrou en lecture sur la ressource x. On notera de mme ru et wu le relchement des verrous
(read unlock et write unlock).
Le principe de base est de surveiller les conits entre deux transactions sur la mme ressource.
Dnition 4.2 (Conit)
Deux verrous pl
i
[x] et ql
j
[y] sont en conit si x = y et pl ou ql est un verrou en criture.
Le respect du protocole est assur par un module dit ordonnanceur ( scheduler , en anglais) qui reoit
les oprations mises par les transactions et les traite selon lalgorithme suivant :
Chapitre 4 Pratique des SGBD 63
Rgle 1. Lordonnanceur reoit p
i
[x] et consulte le verrou dj pos sur x, ql
j
[x], sil existe.
si pl
i
[x] est en conit avec ql
j
[x], p
i
[x] est retarde et la transaction T
i
est mise en attente.
sinon, T
i
obtient le verrou pl
i
[x] et lopration p
i
[x] est excute.
Rgle 2. Un verrou pour p
i
[x] nest jamais relch avant la conrmation de lexcution par un autre
module, le gestionnaire de donnes.
Rgle 3. Ds que T
i
relche un verrou, elle ne peut plus en obtenir dautre.
Le terme verrouillage deux phases sexplique par le fait quil y a dabord accumulation de verrous
pour une transaction T, puis libration des verrous.
Thorme 4.1
Toute excution obtenue par un verrouillage deux phases est srialisable.
Preuve faire en exercice (indication : dmonstration par labsurde en supposant que les transactions
sont 2 phases et quil existe un circuit dans le graphe de prcdence). Attention, la rciproque nest pas
vraie. En exercice, trouver une excution de transactions srialisable mais qui ne soit pas deux phases.
De plus, on obtient une excution stricte en ne relchant les verrous quau moment du commit ou du
rollback. Les transactions obtenues satisfont les proprits ACID.
Il est assez facile de se convaincre que ce protocole garantit quen prsence de deux transactions en conit
T
1
et T
2
, la dernire arrive sera mise en attente de la premire ressource conictuelle et sera bloque
jusqu ce que la premire commence relcher ses verrous (rgle 1). ce moment l, il ny a plus de
conit possible puisque T
1
ne demandera plus de verrou (rgle 3). La rgle 2 a principalement pour but
de sassurer de la synchronisation entre la demande dexcution dune opration et lexcution eective
de cette opration. Rien ne garantit en eet que les excutions vont se faire dans lordre dans lequel elles
ont t demandes.
Le verrouillage deux phases (avec des variantes) est utilis dans tous les SGBD. Il permet en eet une
certaine imbrication des oprations.
Exemple 52 (Un exemple)
XXX A FAIRE
Le problme des interblocages ou encore verrous mortels ( deadlock )
Le principal dfaut du verrouillage deux phases est dautoriser des interblocages : deux transactions
concurrentes demandent chacune un verrou sur une ressource dtenue par lautre.
Exemple
Soient les deux transactions suivantes :
T
1
: r
1
[x] w
1
[y] c
1
T
2
: r
2
[x] w
2
[y] c
2
Considrons maintenant que T
1
et T
2
sexcutent en concurrence dans le cadre dun verrouillage
deux phases :
rl
1
[x] r
1
[x] rl
2
[y] r
2
[y] wl
1
[y] T
1
en attente wl
2
[x] T
2
en attente
T
1
et T
2
sont en attente lune de lautre : il y a interblocage.
Cette situation ne peut pas tre vite et doit donc tre gre par le SGBD. Une solution est que ce dernier
maintienne un graphe dattente des transactions et teste lexistence de cycles dans ce graphe. Si cest
le cas, cest quil y a interblocage et une des transactions doit tre annules et r-excute. Une autre
solution, utilise par exemple dans Oracle, consiste tester le temps dattente et annuler les transactions
qui dpassent une limite pr-xe.
Notons que le problme vient dun accs aux mmes ressources, mais dans un ordre dirent : il est donc
bon, au moment o lon crit les programmes, dessayer de normaliser lordre daccs aux donnes.
Mthodes de dtection :
64 3 Techniques daccs partags : le contrle de concurrence
Pour se faire, lordonnanceur va maintenir un graphe des attentes et reprer si un circuit se forme dans le
graphe des attentes. Pour comprendre le principe de construction du graphe dattente par lordonnanceur,
prenons lexemple suivant. Soit T
i
et T
j
deux transactions. Lordonnanceur reoit de T
i
une demande de
verrou en lecture sur la donne x mais retarde son accord car T
j
a dj pos un verrou en criture. Alors,
lordonnanceur peut rajouter un arc (T
i
, T
j
) dans le graphe dattente. Ensuite, T
j
supprime son verrou
en criture et lordonnanceur peut donc satisfaire T
i
et retirer larc (T
i
, T
j
).
Pour maintenir le graphe dattente, lordonnanceur va ajouter un arc (T
i
, T
j
) au graphe dattente chaque
fois quune demande de pose de verrou de T
i
est bloque par un conit avec un verrou appartenant T
j
.
Un arc (T
i
, T
j
) est supprim du graphe dattente chaque fois que lordonnanceur supprime le dernier
verrou appartenant T
j
qui constituait un blocage pour lattribution dun verrou T
i
.
Fig. 4.8: Exemple de graphe dattente.
Au niveau de la gestion de la dtection de circuit dans le graphe dattente, lordonnanceur peut vrier
chaque ajout darc si le graphe contient un circuit, ce qui semble coteux ou bien dcider de faire des
dtections de temps autre . Dans tous les cas, chaque fois quun circuit existe, il sera dtect.
Lorsquil dtecte un circuit, lordonnanceur doit briser la situation dinterblocage en annulant une tran-
saction. Cette annulation va supprimer un nud dans le graphe dattente et par consquent le circuit.
La transaction choisie pour tre annule sappelle la victime. Parmi toutes les transactions candidates,
lordonnanceur choisit la victime pour laquelle lannulation est la moins coteuse. Les facteurs de cot
les plus communs sont :
La quantit deort dj investie dans la transaction. Cet eort serait perdu si la transaction est annule.
Le cot de lannulation de la transaction. Ceci dpend du nombre de mises jour dj eectues par
la transaction.
La quantit deort investir pour terminer la transaction. Lide est que lordonnanceur devrait
viter dannuler une transaction presque acheve en essayant de prvoir le comportement futur de la
transaction (par exemple en se basant sur le type de la transaction).
Le nombre de circuits qui contient la transaction.
Il faut noter quune transaction peut intervenir successivement dans plusieurs interblocages. Dans chaque
interblocage, la transaction est choisie comme victime, est annule et relance pour tre implique encore
dans un interblocage. An dviter une telle situation, le choix de la victime doit aussi prendre en compte
le nombre de fois que la transaction candidate a t annule cause dun interblocage. Si ce nombre est
lev alors elle ne deviendra victime que si lon a pas dautre choix.
3.2.2 Le contrle par estampillage
Le mcanisme de gestion des concurrences par verrouillage deux phases dtecte a posteriori des attentes
entre transactions. Des mcanismes de prvention bass sur un ordonnancement a priori des actions
composantes des transactions peuvent tre aussi envisags.
Lestampillage est un mcanisme du type prvention. Les transactions T reoivent de lordonnanceur
leur dbut - Begin Of Transaction - une estampille qui est un numro dordre de prsentation en entre de
lordonnanceur. Chaque granule G de donnes note lestampille de la dernire transaction qui y a accd.
Un granule naccepte un nouvel accs que sil est demand par une transaction "plus jeune", cest--dire
de numro destampille plus grand.
Procdure LIRE (T,G,X) Procdure ECRIRE (T, G, X)
Si Estampille(T) >= Estampille(G) alors Si Estampille(T) >= Estampille(G) alors
X lecture(G) criture(G) X
Estampille(G) := Estampille(T) Estampille(G) := Estampille(T)
Sinon rollback(T) Sinon rollback(T)
La transaction rejete est reprise par lordonnanceur aprs avoir reu de lui une nouvelle estampille.
Chapitre 4 Pratique des SGBD 65
Un tel algorithme dordonnancement total conduit souvent de nombreuses reprises en cascades, parfois
par excs de prudence. Aussi a-t-on conu des algorithme dordonnancement partiel qui distinguent pour
chaque granule un compteur pour les estampilles des transactions accdant en lecture et un compteur pour
les estampilles des transactions accdant en criture, ou mieux qui distinguent des versions et les couples
destampilles correspondantes pour chaque granule. Sils amliorent clairement le dbit transactionnel
leur cot en critures et en place mmoire nest toutefois pas ngligeable.
3.2.3 Granules et gestionnaire de transactions
Direntes granularits de contrle de la concurrence sont possibles :
valeur dun attribut de n-uplet,
un n-uplet,
une page ou bloc,
une relation,
une base.
Plus la granularit est petite, plus le niveau de concurrence augmente. Par contre le niveau de complexit
de gestion des verrous augmente et les performances baissent.
A priori le choix est dpendant du type des transactions (nature des informations manipules). La plupart
du temps dans les systmes commerciaux la granularit est xe (sauf indique explicitement). Certains
systmes font du verrouillage adaptatif en tenant compte de la hirarchie des objets (plutot que de bloquer
tous les attributs dun n-uplet il vaut mieux bloquer le n-uplet et ainsi de suite). Dans les systmes actuels
le niveau oert est celui du n-uplet.
Dans le modle physique les tuples sont des structures adressables doctets. Un gestionnaire de
donnes les charge dans un espace de la mmoire principale ou les en dcharge, par des oprations
lmentaires de lecture/criture de pages - ou blocs - de donnes, pouvant contenir plusieurs
tuples , depuis ou vers des chiers sur disque. Ainsi ladresse physique de stockage dun tuple est de
la forme <chier>,<page>,<oset>.
Le granule de concurrence le plus souvent gre par les SGBD est la page ou la page et loset - cest
dire le tuple.
Le gestionnaire de transaction enchane deux fonctions : (1) il dcoupe les transactions en actions l-
mentaires au niveau physique o est gre la concurrence, puis (2) il ordonnance ces actions. Cet or-
donnancement ncessite le calcul et le maintien dun graphe de prcdences a priori et/ou dun graphe
dattentes a posteriori, puis le choix des squences dexcution selon le niveau disolation demand et enn
la supervision de lexcution. Un pr-processeur alimente lordonnanceur en ux parallles dactions. Ce
dernier alimente le gestionnaire de donnes action par action et rend compte au pr-processeur de ltat
instantan de chaque transaction : encours, suspendue, rejete, valide.
3.3 La gestion des transactions en SQL
Il est possible en SQL de choisir explicitement le niveau de protection que lon souhaite obtenir contre les
incohrences rsultant de la concurrence daccs. Le comportement par dfaut est dassurer sria-
lisabilit et recouvrabilit stricte, mais ce mode a linconvnient de ralentir le dbit transactionnel
pour des applications qui nont peut-tre pas besoin de contrles aussi stricts.
1- La premire option disponible est de spcier quune transaction ne fera que des lectures.
Dans ces conditions, on peut garantir quelle ne soulvera aucun problme de concurrence et le SGBD
peut spargner la peine de poser des verrous. La commande SQL est :
SET TRANSACTION READ ONLY ;
Il devient alors interdit deectuer des ordres UPDATE, INSERT ou DELETE jusquau prochain commit ou
rollback : le systme rejette ces instructions. Le double avantage de cette option est (i) dtre sr de ne
jamais tre bloqu, et (ii) daugmenter le dbit transactionnel global.
Une consquence insidieuse est que deux lectures successives avec le mme ordre SELECT peuvent donner
des rsultats dirents : entre temps une autre transaction a pu mettre jour les donnes.
66 3 Techniques daccs partags : le contrle de concurrence
2- Loption par dfaut est quune transaction peut lire et crire. On peut spcier ce mode explicitement
par :
SET TRANSACTION READ WRITE ;
Quen est-il maintenant des bonnes proprits des excutions concurrentes ?
La norme SQL2 spcie que ces excutions doivent tre srialisables : il sagit l du mode par dfaut.
Un verrouilage strict doit alors tre assur par le SGBD. Il peut arriver que certaines applications ne
demandent pas une scurit aussi stricte et soient pnalises par le surcot en temps induit par la gestion
du verrouillage. SQL2 propose des options moins fortes, explicites par la commande
SET TRANSACTION ISOLATION LEVEL option
Voici la liste des options, sachant que tous les sytmes ne les proposent pas intgralement.
1. READ UNCOMMITTED. Cest le mode qui ore le moins disolation : on autorise les lectures sales ,
i.e. les lectures de tuples crits par dautres transactions mais non encore valides.
2. READ COMMITED. On ne peut lire que les tuples valids, mais il peut arriver que deux lectures
successives donnent des rsultats dirents.
En dautres termes, un lecteur ne pose pas de verrou sur la donne lue, ce qui vite de bloquer les
crivains. Cest le mode par dfaut dans ORACLE par exemple.
3. REPEATABLE READ. Le nom semble indiquer que lon corrige le dfaut de lexemple prcdent. En
fait ce mode garantit quun tuple lu au dbut de la transaction sera toujours visible ensuite, mais
des tuples peuvent apparatre sils ont ts insrs par dautres transactions (on parle de tuples
fantmes ).
4. SERIALIZABLE. Le dfaut. Ce mode garantit les bonnes proprits (srialisabilit et recouvrabilit)
des transactions telles que prsentes prcdemment, mais de plus on garantit que plusieurs lectures
avec le mme ordre SQL donneront le mme rsultat, mme si des insertions ou mises jour valides
ont eu lieu entretemps.
Tout se passe alors comme si on travaillait sur une image de la base de donnes prise au dbut
de la transaction.
Lobjectif de ces relchements de contraintes plus ou moins importants est videmment daugmenter
le paralllisme apparent et le dbit en transactions.
Il est important de noter que le standard SQL ne dit pas comment choisir ces niveaux. Chaque SGBD a
donc sa propre politique en la matire, y compris de ne pas en avoir, cest--dire de nimplanter que lun
de ces niveaux (qui peut ventuellement tre le plus laxiste).
Le tableau ci-dessous rsume les dirents niveaux disolation praticables et les anomalies quils doivent
interdire :
Fig. 4.9: Tableau rcapitulatif des niveaux disolation dans SQL2.
Les stratgies dimplantation des verrous portent sur :
1. Les entits verrouilles : lignes, prdicats, pages, ...
2. Les modes de verrouillages : read et write
3. La dure des verrouillages :
courts : les verrous acquis pour lexcution dune requte sont relchs ds que la requtes est
termine.
Longs : les verrous acquis pour lexcution dune requte sont relchs seulement lorsque la tran-
saction dont elle fait partie est termine.
Moyens : solution intermdiaire.
Chapitre 4 Pratique des SGBD 67
Les verrous en criture ( write locks , en anglais) sont traits de la mme manire dans tous les
niveaux disolation. Ils sont associs aux requtes : UPDATE, DELETE et INSERT.
Les verrous en lecture sont traits diremment suivant les niveaux disolation.
READ UNCOMMITTED : pas de verrou en lecture. Ainsi une transaction peut lire un objet verrouill en
criture !
READ COMMITTED : verrou de courte dure sur les lignes retournes par SELECT.
REPEATABLE READ : verrou de longue dure sur les lignes retournes par SELECT.
SERIALIZABLE : verrou de longue dure sur les prdicats spcis dans la clause WHERE du SELECT.
Signalons enn que certains systmes permettent de poser explicitement des verrous. Cest le cas de
ORACLE qui propose par exemple des commandes telles que :
LOCK TABLE ... IN EXCLUSIVE MODE
3.4 Le contrle de concurrence sous Oracle
3.4.1 Niveaux disolation dune transaction
Le niveau Read Commited est le niveau de transaction par dfaut. Une requte voit les valeurs
committes par les autres transactions avant le dmarrage de lexcution de la requte.
Une requte ne lit jamais de donnes salies et non committes par une autre transaction.
Une donne peut avoir t modie par une autre transaction entre deux excutions de la mme requte.
Il est donc possible quune lecture soit non rptable et que des donnes fantmes apparaissent.
Le niveau Read Only voit seulement les modications committes avant le dmarrage de la transaction.
Ce niveau garantie donc les lectures consistantes.
On ne peut pas faire dInsert, Update et Delete dans une transaction en mode Read Only.
Le paramtrage du mode disolation se fait au niveau transaction :
set transaction read write ; (par dfaut)
set transaction read only ;
3.4.2 Mcanisme de verrouillage
Pour grer les conits daccs concurrents aux donnes, Oracle a mis en place un systme automatique
de contrle par verrouillage. Le verrouillage est ralis au niveau ligne.
Un verrou exclusif est automatiquement pos sur une donne lorsque lon excute un ordre SQL SELECT
... FOR UPDATE, INSERT, UPDATE, DELETE.
De cette manire, aucune autre transaction ne peut modier cette donne tant que le verrou est pos.
La dure du verrou est celle de la transaction.
Le verrou est relch sur lexcution dun Commit ou dun Rollback.
Oracle dtecte automatiquement les situations de verrou mortel (deadlock). Lune des transactions par-
ticipant au deadlock est dfaite par Oracle.
3.4.3 Les dirents types de verrous utiliss par Oracle
Les ordres SQL de manipulation de donnes peuvent acqurir des verrous deux niveaux :
niveau ligne (TX)
niveau table (TM)
Lorsquune transaction acquire un verrou sur la ligne quelle veut modier, elle obtient galement un
verrou sur la table toute entire.
Ceci empche toute autre transaction dexcuter un ordre DDL (data description language) tant que
le verrou nest pas relch.
68 3 Techniques daccs partags : le contrle de concurrence
Par exemple, une autre transaction peut vouloir supprimer (DROP) la table ou en modier sa structure
(ALTER) alors que la modication apporte par la transaction nest pas committe.
Les verrous sur tables sont de type :
RS (Row Share) : il est pos sur la table par une transaction qui a pos des verrous sur des lignes dans
lintention de les modier. Ce verrou empche toute autre transaction de verrouiller la table en mode
exclusif.
S (Share) : ce verrou est pos manuellement par linstruction LOCK TABLE table IN SHARE MODE ;. Il
empche toute autre transaction de modier le contenu de la table verrouille. Seule la transaction qui
a pos le verrou Share peut modier le contenu de la table dans le cas o elle est la seule dtenir ce
type de verrou. Dans le cas contraire, aucune des transactions dtenant le verrou Share ne peut modier
le contenu de la table tant que les autres nauront pas librer leur verrou. Ce verrou ne garantit donc
pas un accs exclusif en criture.
SRX (Share Mode Exclusif) : ce verrou est pos manuellement. Mme eet que les verrous Share mais
il ne peut tre pos que par une seule transaction.
RX (Row Exclusive) : ce verrou est en gnral pos sur la table par une transaction qui a ralis une
ou plusieurs mises jour sur des lignes de la table. Il est plus restrictif que le verrou Row Share pour
les autres transactions. Il empche les verrouillages en mode Share (S) et Exclusive (X)
X (Exclusive) : ce verrou ne peut tre obtenu que par une seule transaction. Il lui confre un droit
dcriture exclusif dans la table. Il nautorise aux autres transactions quun accs en lecture. Les ordres
DDL de dnition du schma drop table et alter table posent implicitement un verrou X sur la table.
Les ordres DDL sont automatiquement commits.
Fig. 4.10: Tableau rcapitulatif des verrous table poses automatiquement lexcution dun
ordre SQL. Les oui* reprsentent des verrouillages table compatibles. Mais, sil y a conit
sur le verrouillage ligne, la transaction qui veut poser le verrou doit quand mme attendre.
Chapitre 4 Pratique des SGBD 69
4. Techniques de rcupration derreur
Dans cette section, nous voyons comment garantir lintgrit physique des donnes valides en assurant
une reprise correcte dans tous les cas de panne du systme.
Une panne est un vnement logique ou physique qui provoque une n anormale de transaction - hors du
cas normal dabandon "conscient". On peut classer les pannes en :
Panne de transaction due la la transaction elle-mme (si elle demande une action illgale : une
division par zro ou une modication violant une contrainte dintgrit) ou du fait du SGBD (si il ne
peut rsoudre un "dead-lock" dans la concurrence de deux transactions). Dans les deux cas, un rollback
de la transaction peut tre automatiquement dclench et compltement eectu.
Panne de systme ou de mmoire principale, qui malheureusement est toujours "volatile" : le
systme a en quelque sorte "perdu la mmoire" ou ne sait plus la relire correctement. Une des parties
de la mmoire consacre soit aux donnes, soit aux journaux, soit aux codes des gestionnaires eux-
mmes, est devenue illisible. Le systme doit redmarrer " chaud" partir du dernier point de reprise
("checkpoint") qui correspond une criture en mmoire secondaire de toutes les pages mises jour
en mmoire principale.
Panne de mdia ou de mmoire secondaire : un volume de disque ou un chier ou certains blocs
dun chier ne sont plus accessibles ou ne sont plus corrects. Sils ne concernent que la base de donnes,
on peut les reconstituer partir du dernier "backup" (sauvegarde) qui correspond une criture sur un
autre disque, ou sur une bande, de tout ou partie de la base de donnes physique et des journaux. Cest
un redmarrage " froid". Sils concernent la base et tout ou partie des journaux depuis la dernire
sauvegarde, la panne est dite "catastrophique" et seule une rparation manuelle par ladministrateur
de la base est envisageable.
4.0.4 Les redondances ncessaires
4.0.5 Mmoires "sres" et mmoires "ables" (ou " haute disponibilit")
Les mmoires sres supposent que lcriture physique dune unit denregistrement ("page" ou "bloc")
soit atomique, cest--dire ou totalement et correctement excute ou pas excute du tout. Les mmoires
ables sont dabord sres et, de plus, se corrigent le plus souvent elles-mmes des dfaillances physiques,
grce une redondance et des comparaisons systmatiques.
Les mmoires secondaires ables les plus rpandues aujourdhui utilisent la technologie RAID : Redundant
Array of Inexpensive Disks.
4.0.6 Base de donnes, journaux, sauvegardes et archives
Les mmoires secondaires doivent tre de abilit croissante : si la base de donnes physique est non sre,
les journaux doivent tre srs et les sauvegardes doivent tre ables . Mais, bien sr, augmenter la abilit
de toutes les mmoires secondaires amliore la disponibilit (une reprise froid ncessite - sauf dans le
cas de dispositifs de mmoires en miroir - un arrt dexploitation). Dans tous les cas, on minimise les
risques en utilisant au moins des disques dirents pour la BD dune part et les journaux et sauvegardes
dautre part.. Les archives sont soit des sauvegardes anciennes conserves pour usage historique, soit
des dchargement partiels des parties les moins souvent accdes de la base de donnes, soit enn des
dchargements partiels ou des duplications partielles des journaux quand ils deviennent trop longs.
4.1 Les mcanismes utiliss
Ils sont tous bass sur le couple base de donnes et journaux. La base de donnes est toujours considre
sous son aspect physique. Parmi ses tats successifs, deux sont des repres essentiels : ceux correspondant
une sauvegarde (duplication physique sur un autre volume de mmoire secondaire) et ceux correspondant
un point de reprise (recopie des pages mises jour en mmoire principale vers la mmoire secondaire
- "ush", faite si possible dans un temps mort transactionnel, cest--dire sans transaction en cours).
Le ou les journaux peuvent tre conus logiquement ou physiquement selon que lon conserve la trace
70 4 Techniques de rcupration derreur
des transactions (pour dfaire ou refaire) ou la trace des donnes modies (images avant ou aprs les
transactions).
Fig. 4.11: Principe de gestion des reprises aprs panne.
4.1.1 "do-redo-undo" (faire-refaire-dfaire)
Logiquement "faire" lexcution dune transaction, comme dun ux de transactions, cest lire et crire
des donnes dans le cache prvu cet eet dans la mmoire principale puis crire sur le ou les journaux en
mmoire sre secondaire. Quelques soient les stratgies de transfert des pages de donnes de la mmoire
principale vers la mmoire secondaire (criture laisse linitiative du gestionnaire de cache, criture force
au commit, criture dire jusquau prochain point de reprise automatique - en gnral dclenche par
le constat dun journal assez long) deux rgles doivent tre respectes :
1. REFAIRE toujours possible : les IMAGES APRS mise jour doivent tre inscrites DANS LA
MMOIRE SECONDAIRE (journal et ventuellement base de donne) AVANT la n de transaction
EOT
2. DFAIRE toujours possible : les IMAGES AVANT mise jour doivent tre inscrites dans le journal
correspondant AVANT que les IMAGES APRS soient transfres dans la base de donnes.
4.1.2 Stratgies
Elles sont logiquement quatre, mais les trois premires seulement sont pratiquement envisageables, selon
quaprs une panne REFAIRE et DFAIRE sont ncessaires, REFAIRE seul ou DFAIRE seul est
ncessaire, ni lun ni lautre ne sont ncessaires.
Considrons dabord le cas o le dernier point de reprise correspond un point mort hors transactions.
Une panne non catastrophique de media est reprise froid par rechargement de la dernire sauvegarde
et droulement du journal des IMAGES APRS - ou du REDO log - jusquau dernier point de reprise.
Ensuite on est dans le mme cas quune reprise chaud qui correspondrait une panne systme intervenue
aprs ce point. Il y a deux catgories de transactions considrer alors, toutes ayant commenc aprs le
point de reprise : celles qui avaient t valides avant, celles qui ntaient pas encore valides. Comme en
gnral on ne sait pas quelles pages mises jour par le gestionnaire de cache a ou na pas dj transfr
sur la base en mmoire secondaire, il faut dabord DFAIRE les transactions non valides - en remontant
Chapitre 4 Pratique des SGBD 71
le journal des IMAGES AVANT - jusqu leur dbut BOT, puis REFAIRE les transactions valides - en
redescendant le journal des IMAGES APRS - jusqu leur n EOT.
Considrons maintenant le cas o le dernier point de reprise avait eu lieu alors que des transactions
taient en cours : la mthode de reprise chaud ne dire que par ltendue de la relecture des journaux
car il faut remonter au dbut BOT de la plus ancienne transaction interrompue par la panne ou commise
aprs le point de reprise mais avant la panne, ce qui pouvait tre bien avant le point de reprise ; la reprise
froid elle devra cette fois-ci ncessairement tre suivie dune reprise chaud. Ainsi, pour garantir un
redmarrage depuis une base cohrente, quelque ait pu tre la cause de larrt, tous les SGBD font toujours
une reprise chaud aprs le "startup".
5. Les bancs de mesure des performances ("benchmarks")
La question des performances transactionnelles a t dj un peu voque ci-dessus en termes de temps
de rponse et de "dbit" de transactions. Dnissons un peu plus prcisment les grandeurs mesurer :
N = nombre dutilisateurs actifs simultanment prsents : dans une exploitation normale les utilisateurs
ouvrent des sessions au cours desquelles ils eectuent des transactions successives. Du point de vue du
SGBD, celles-ci sont seulement interrompues par les temps de lecture, de rexion et de frappe de
lutilisateur (temps dinactivit TI pour le systme). Si les utilisateurs sont actifs, les sessions comme
les transactions sont tout instant N en parallle.
TR = temps de rponse moyen par transaction : supposons que la transaction est prpare par remplis-
sage dun cran qui est transmis en bloc au systme, le cycle vcu par chaque utilisateur est un alternat :
TI = utilisateur actif et systme inactif, TR = utilisateur inactif et systme actif. Cest ce deuxime qui
constitue le temps rponse du systme. La somme TI + TR reprsente un cycle transactionnel complet.
TPS = dbit de transaction (par unit de temps) : si lon considre le ux global de toutes les transac-
tions, quelque soit lutilisateur responsable, on peut en mesurer le dbit travers le systme par unit
de temps gnralement la seconde, do le nom Transaction(s)_Par_Seconde. Ce dbit est dautant
plus grand que le "taux darrive" est grand et le "temps de service" court.
Il est facile de vrier que ces trois grandeurs sont lies par la formule de Little : TPS = N/(TI + TR)
qui donne prcisement la dnition du dbit dun SGBD : nombre de transactions en cours divis par
temps de cycle moyen dune transaction.
5.0.3 Mesures synthtiques et mesures analytiques
Le point de vue de lutilisateur est toujours externe au systme "derrire" le terminal et synthtique :
il ne sintresse qu des performances globales moyennes ou extrmes (le "pire cas") qui tiennent
compte de tous les besoins : dispersion gographique des utilisateurs et des donnes, volume et distribution
statistique des donnes, complexit du schma et des requtes, abilit des composants, etc... Lutilisateur
doit prendre une dcision dachat et son cahier des charges spcie en gnral une conguration pour
une application type avec un volume minimum de donnes, des contraintes dextrmes sur les temps de
rponse et la disponibilit. Il demande nalement des performances - et des rapports prix/performance -
pour ce volume et pour plusieurs fois ce volume (dans le cas trs probable o sa BD devra grandir avec
le temps).
Le point de vue du constructeur est toujours interne au systme et analytique du fonctionnement de chacun
de ses composants. Pour lui, la performance globale nest que le rsultat de la performance combine des
sous-systmes de gestion des mmoires, des reprises, dordonnancement des transactions, doptimisation
des plans dexcution des requtes et des "piles" de protocoles de communication pour ne citer que les
principaux. Pour les caractriser et pouvoir les prdire en exploitation il est amen construire des bancs
de test o, tous les autres sous-systmes ayant des performances connues par ailleurs, un sous-systme est
soumis un vritable plan exprimental. Il sagira, pour lui, plus didentier les coecients de formules
72 5 Les bancs de mesure des performances ("benchmarks")
de cots que de mesurer les cots les plus avantageux pour une charge de travail idale.
Quelque soit le point de vue, les qualits attendues des bancs pour raliser la mesure de ces performances
les "benchmarks" - sont les mmes :
pertinence : le benchmark doit bien spcier le domaine et la signication de la performance quil
entend mesurer ; il doit tre reproductible, talonnable et le plus prcis possible.
portabilit : on doit pouvoir lappliquer une grande varit de congurations, pour comparer les
rsultats de plates-formes direntes sous un mme SGBD, de SGBD dirents sur une mme plate-
forme.
dimensionnabilit : on doit pouvoir lappliquer, pour une conguration donne, des tailles variables
de BD et avec des quantits variables de ressources CPU et/ou disques, an de tester les linarits per-
formance/volume BD ressources constantes, performance/ressources volume BD constant, volume
BD/ressources performance constante.
simplicit : malgr les trois prcdentes exigences, le benchmark doit rester simple comprendre
au moins pour les "spectateurs" et pas trop coteux implmenter pour les participants la
comptition !
5.0.4 Les benchmarks du Transaction Processing Council (TPC)
A n des annes 80, un "benchmark" pour les systmes transactionnels tait de plus en plus utilis et
ses rsultats discuts tant par les utilisateurs et les journalistes spcialiss que par les constructeurs. Il
tait issu des propositions dun article de Anon et al. de 1985 dans DATAMATION pour la mesure du
"transaction processing power" des systmes et portait le nom de "dbit-crdit" ou "TP1".
Devant la bataille des chires sans juge ni arbitre qui t rage alors, la plupart des grands constructeurs
une cinquantaine ce jour ont prfr se runir en "concile" pour stabiliser, dans des spcications
longuement discutes et prcises dans le dtail, et nalement soumises un vote formel en 1990, les
dnitions de deux benchmarks inspirs du TP1 : les TPC-A et B. Ces benchmarks bien que ne repr-
sentant quune application trs simple un guichet automatique de banque ne faisant que des retraits
ou des dpts ont t considrs comme des rfrences obliges par presque tous les diteurs de SGBD
et ont eu une grande inuence sur leur comptition. Les tps-A ou B, dbits exprims en transactions par
seconde conformment aux spcications des benchmarks TPC-A ou B, et les rapports prix/performance
exprims en milliers de US$ par tps-A ou B, ont fourni les chires de palmars largement diuss par
la presse, bien que tout le monde saccordait dj pour trouver lapplication "dbit-crdit" comme trs
peu reprsentative des applications relles des utilisateurs professionnels : laccs exclusivement article
par article ne donne aucun avantage aux SGBD relationnels par rapport aux SGBD rseaux ni ces der-
niers par rapport aux SGF squentiels indexs traditionnels. Ainsi ces benchmarks sont vite apparus plus
dpendants d aspects systme gnraux multiplexage des terminaux pour le TPC-A, rapidit et/ou
paralllisation des accs disques pour le TPC-B que daspects proprement SGBD optimisation et
gestion transactionnelle des donnes.
Cest pourquoi le TPC a mis en chantier deux autres spcications lune pour le "business transaction
processing" avec le TPC-C (1992), lautre pour le "decision support" avec le TPC-D (1995). Toutes
deux orent un schma et des requtes plus complexes et plus reprsentatifs des applications relles.
Leur smantique commune est inspire des applications de gestion de clients, commandes et stocks. Les
mtriques en sont respectivement des tpm-C (transactions par minute pour le TPC-C) et des qph-D
(requtes queries par heure pour le TPC-D). Dautres spcications ciblant plus particulirement
les gros serveurs BD et les congurations clients-serveurs sont en cours de discussion.
5.0.5 Le rglage ( "tuning") des applications/SGBD relles
Obtenir les meilleures performances dune conguration complte terminaux, systme de communica-
tion, SGBD, OS, plate-forme mono ou multiprocesseurs, batterie de disques est un art dexpert quand
il sagit des benchmarks de comptition, cest un mtier encore relativement complexe quand il ne sagit
"que" dadministrer des systmes de bases de donnes relles. Outre une excellente connaissance de la
mtabase le "schma des schmas" et des outils de surveillance et contrle en cours dexploitation
"monitoring" il faut ladministrateur des rgles et une stratgie pour les optimisations locales
Chapitre 4 Pratique des SGBD 73
aux applications et globale au systme le fameux "dbit". Ce qui ncessite un apprentissage lourd,
dautant plus quil nexiste pas de modles de simulation et de prvision qui soient la fois universels et
dtaills.
Les diteurs de SGBD eux-mmes, ou des socits indpendantes dingnierie du logiciel, proposent des
interfaces ddies aux administrateurs de SGBD qui varient de la simple manipulation visuelle des donnes
de la mtabase de vritables systmes-experts dont la base de modles et de rgles peut tre trs riche
- et chre !
6. Scurit et autorisations
Les fonctions qui oprent sur les tables doivent tre dnies par catgories dutilisateurs. cette n, les
commandes SQL GRANT et REVOKE permettent de grer les droits dutilisateurs.
Les privilges accords lutilisateur par GRANT peuvent lui tre retirs par REVOKE :
GRANT privilege ON relation TO user ;
REVOKE privilege ON relation FROM user ;
La commande GRANT met jour la liste des privilges pour que layant droit puisse lire, insrer ou
supprimer les donnes dans des tables ou des vues spciques. linverse, la commande REVOKE permet
de retirer lutilisateur un privilge qui lui a t accord.
Par exemple, si nous seulement autoriser la lecture de la vue Employe :
GRANT SELECT ON Employe TO PUBLIC ;
/* droit de lecture accord tout le monde */
En spciant PUBLIC au lieu dune liste dutilisateurs, nous accordons le droit de lecture tous sans
aucune restriction.
Les privilges peuvent tre accords de manire slective. dans lexemple suivant, le droit de mise jour
de la table Service est accorde exclusivement un responsable du personnel identi par le numro
dutilisateur ID37289 :
GRANT UPDATE ON Service TO ID37289 WITH GRANT OPTION ;
Lutilisateur ID37289 peut alors modier la table Service. En outre, avec GRANT OPTION, il a la comptence
de transmettre ce privilge ou un droit de lecture restreint aux autres utilisateurs, et aussi de les retirer
ultrieurement. Cela permet de dnir et de grer linterdpendance des droits.
7. Linterface C/SQL
Cette section prsente lintgration de SQL et dun langage de programmation classique, ici C. Lutilit
de lutilisation conjointe de deux langages rsulte de linsusance de SQL en matire de traitement de
donnes : boucles, tests, etc. On utilise donc SQL pour extraire les donnes de la base, et le langage
de programmation pour manipuler les donnes. La dicult principale consiste transcrire des donnes
stockes selon des types SQL en donnes manipulables par le langage de programmation.
Dans la suite, nous donnons un exemple complet dun petit programme avec des commentaires expliquant
les aspects lis linterfaage avec C.
74 7 Linterface C/SQL
7.1 Un exemple complet
On suppose quil existe dans la base une table Film dont voici le schma :
CREATE TABLE film (ID_film NUMBER(10) NOT NULL,
Titre VARCHAR (30),
Annee NUMBER(4),
ID_Realisateur NUMBER(10)) ;
On donne dans la suite un programme qui se connecte et recherche le lm did l. Les numros gurant
en n de ligne servent de rfrence aux commentaires.
#include <stdio.h>
EXEC SQL INCLUDE sqlca; (1)
typedef char asc31[31] ; (2)
int main (int argc, char* argv[])
{
EXEC SQL BEGIN DECLARE SECTION ; (3)
EXEC SQL TYPE asc31 IS STRING(31) REFERENCE ; (2)
int ora_id_mes, ora_annee ;
char user_id = / ;
asc31 ora_titre ; (2)
short vi1, vi2, vi3 ; (4)
EXEC SQL END DECLARE SECTION ; (3)
EXEC SQL WHENEVER SQLERROR goto sqlerror ; (5)
EXEC SQL CONNECT :user_id ; (6)
ora_id_film = 1; (7)
ora_id_mes = 0; ora_annee = 0;
strcpy (ora_titre,"");
EXEC SQL SELECT titre, annee, id_realisateur (8)
INTO :ora_titre:vi1, ora_annee:vi2,
:ora_id_mes:vi3
FROM film
WHERE id_film = 1;
printf ("Titre : %s Annee : % Id mes %d `n",
ora_titre, ora_annee, ora_id_mes);
sqlerror: if (sqlca.sqlcode != 0) (9)
fprintf (stderr, "Erreur NO %d : %s `n",
sqlca.sqlcode, sqlca.sqlerrm.sqlerrmc);
}
Il reste prcompiler ce programme : le SGBD remplace alors tous les EXEC SQL par des appels ses
propres fonctions C; compiler le .c rsultant de la prcompilation, et faire ldition de liens avec les
librairies impliques.
On donne ci-dessous les commentaires correspondant au programme dcrit plus haut.
1. Cette ligne est spcique Oracle qui communique avec le programme via la structure sqlca. Il
faut inclure le chier sqlca.h avant la prcompilation, ce qui se fait avec la commande EXEC SQL
Chapitre 4 Pratique des SGBD 75
INCLUDE.
2. Le principale problme en PRO*C est la conversion des VARCHAR de SQL en chanes de caractres
C contenant le fameux `0. Le plus simple est de dnir explicitement lquivalence entre un type
manipul par le programme et le type SQL correspondant. Cela se fait en deux tapes :
(a) On fait un type typedef pour dnir le type du programme : ici le type asc31 est synonyme
dune chane de 31 caractres C.
(b) On utilise (ligne 2) la commande EXEC SQL TYPE pour dnir lquivalence avec le type SQL.
Maintenant, le SGBD grera convenablement la conversion des VARCHAR vers une variable C (2) en
ajoutant le `0 aprs le dernier caractre non-blanc.
3. Le transfert entre la base de donnes et le C se fait par lintermdiaire de variables htes qui
doivent tre dclares dans un bloc spcique (3 et 3).
4. Il ny a pas, en C, lquivalent de la valeur nulle (qui correspond en fait labsence de valeur).
Pour savoir si une valeur ramene dans un ordre SQL est nulle, on doit donc utiliser une variable
spcique, dite indicatrice. Cette variable est toujours de type short.
5. Dans le cas o une erreur survient au moment de lexcution dun ordre SQL, il faut indiquer le
comportement adopter. ici, on se droute sur une tiquette sqlerror.
6. Connexion la base : indispensable avant tout autre ordre. Ici, on utilise la connexion automatique
Oracle.
7. Initialisation des variables de communication. Cette initialisation est indispensable.
8. Exemple dun ordre SELECT. Pour chaque attribut slectionn, on indique dans la clause INTO la
variable rceptrice suivie de la variable indicatrice. Attention, le SGBD gnre une erreur si on
lit une valeur nulle sans utiliser de variable indicatice.
9. Gestion des erreurs : le champ sqlcode de la structure sqlca est mis jour aprs chaque ordre
SQL. Quand il vaut 0, cest que lon na pas rencontr derreur. La valeur 1403 (spcique dOracle)
indique quaucune ligne na t trouve. Toute valeur ngative indique une erreur, auquel cas le
message se trouve dans sqlca.sqlerrm.sqlerrmc.
peu prs lessentiel de ce qui est susant pour crire un programme C/SQL se trouve dans le code
prcdent. La principale fonctionnalit non voque ci-dessus est lemploi de curseurs pour parcourir un
ensemble de n-uplets. SQL manipule des ensembles, notion qui nexiste pas en C : il faut donc parcourir
lensemble ramen par lordre SQL et traiter les tuples un un. Voici la partie du code qui change si on
souhaite parcourir lensemble des lms.
/* Comme prcdemment, jusqu EXEC SQL WHENEVER SQL ERROR ... */
EXEC SQL DECLARE CFILM CURSOR FOR
SELECT id_film, titre, annee, id_realisateur
FROM film;
EXEC SQL CONNECT :user_id;
ora_id_film = 0; ora_id_mes = 0;
ora_annee = 0; strcpy (ora_titre,"");
EXEC SQL OPEN CFILM;
EXEC SQL FETCH CFILM INTO :ora_id_film:vi1, ora_titre:vi2,
:ora_annee:vi3, ora_id_mes:vi4;
76 7 Linterface C/SQL
while (sqlca.sqlcode != ORA_NOTFOUND)
{
printf ("Film no %d. Titre : %s Annee : %d Id mes %d `n"
ora_id_film, ora_titre, ora_annee, ora_id_mes);
EXEC SQL FETCH CFILM INTO :ora_id_film:vi1, :ora_titre:vi2,
:ora_annee:vi3, ora_id_mes:vi4;
}
EXEC SQL CLOSE CFILM;
/* Comme avant ... */
On dclare un curseur ds quun ordre SQL ramne potentiellement plusieurs n-uplets. Ensuite chaque
appel la clause FETCH accde un n-uplet, jusqu ce que sqlca.sqlcode soit gal 1403 (ici, on a
dclar une constante ORA_NOTFOUND.
Comme dhabitude, il est recommand dorganiser le code avec des fonctions. Dune manire gnrale,
il parat prfrable de bien prparer le code grant les accs la base du code implantant lapplication
proprement dite. Quelques suggestions sont donnes dans la section suivante.
7.1.1 Dveloppement en C/SQL
La recherche dinformation dans une table est une bonne occasion disoler une partie bien spcique du
code crant une fonction charge daccder cette table, de vrier la validit des donnes extraites de
la base, deectuer les conversions ncessaire, etc. De plus, une telle fonction a toutes les chances dtre
utile beaucoup de monde.
Les deux cas les plus courants daccs une table sont les suivants :
1. Recherche dun n-uplet avec la cl.
2. Boucle sur les n-uplets dune table en fonction dun intervalle de valeurs pour la cl.
Du point de vue de la structuration du code, voici des stratgies qui semblent recommandables pour
chaque cas.
Recherche avec la cl
1. On dnit une structure correspondant au sous-ensemble des attributs de la table que lon souhaite
charger dans le programme.
2. On dnit une fonction de lecture (par exemple LireFilm) qui prend en entre un pointeur sur
une structure et renvoie un boolen. Au moment de lappel la fonction, on doit avoir initialis le
champ correspondant la cl.
3. Dans la fonction, on excute lordre SQL, on eectue les contrles ncessaires, on place les donnes
dans les champs de la structure. On renvoie TRUE si on a trouv quelque chose, FALSE sinon.
Voici par exemple le squelette de la fonction LireFilm.
boolean LireFilm (Film * film)
{
/* Declarations */
...
/* Initialisations */
...
ora_id_film = film->id_film;
...
/* Ordre SELECT */
EXEC SQL SELECT ...
/* Test */
if (sqlca.sqlcode == ORA_NOTFOUND) return FALSE;
else ...
Chapitre 4 Pratique des SGBD 77
/* Controles divers et placement dans la structure */
...
film->id_film = ora_id_film;
...
return TRUE;
}
Et voici comment on appelle la fonction.
Film film;
...
film.id_film = 34;
if (LireFilm (&film) )
... /* On a trouve le n-uplet */:
else
... /* On na rien trouve */
Donc la fonction appelante ne voit rien de linterface SQL et peut se consacrer uniquement la manipu-
lation des donnes.
Recherche par intervalle On peut suivre peu prs les mmes principes, ceci prs quil faut :
1. Passer en paramtres les critres de recherche.
2. Grer louverture et la feermeture du curseur.
Pour le deuxime point, on peut procder comme suit. On place dans la fonction une variable statique
initialise 0. Au premier appel cette varaible est nulle et on doit ouvrir le curseur et changer la valeur
1 avant de faire le premier FETCH. Aux appels suivants, la valeur est 1 et on peut faire simplement des
FETCH. Quand on a atteint le dernier n-uplet, on ferme le curseur et on remet la variable 0. Voici le
squelette de la fonction BoucleFilms qui eectue une recherche sur un intervalle de cls.
boolean BoucleFilms (Film *film, int cle_min, int cle_max)
{
/* Declarations des variables et du curseur, initialisations ... */
...
static debut = 0;
...
/* Test douverture du curseur */
if (debut == 0)
{
EXEC SQL OPEN ...
debut = 1;
}
/* Dans tous les cas on fait le FETCH */
EXEC SQL FETCH ...
if (sqlca.sqlcode == ORA_NOTFOUND)
{
EXEC SQL_CLOSE ...
debut = 0;
return FALSE;
}
else
{
/* Faire les contrles et placer les donnes dans film */
...
return TRUE
}
}
78 7 Linterface C/SQL
Et voici comment on utilise cette fonction.
Film film;
int cle_min, cle_max;
...
while (BoucleFilms (&film, cle_min, cle_max))
{
...
}
Notez quavec lutilisation combine des fonction et des structures, non seulement on clarie beaucoup le
code, mais on rend trs facile lajout dune nouvelle donne. Il sut de modier la structure et limplan-
tation de la fonction de lecture. Tout le reste est inchang.
7.2 Autres commandes SQL
Voici, titre de complment, les principales fonctionnalits daccs une base de donnes et leur expression
en C/SQL.
Validation et annulation
1. Validation : EXEC SQL COMMIT WORK...
2. Annulation : EXEC SQL ROLLBACK WORK ;
Si on ne fait pas de COMMIT explicite, Oracle eectue un ROLLBACK la n du programme.
UPDATE, DELETE, INSERT
On utilise ces commandes selon une syntaxe tout fait semblable celle du SELECT. En voici des exemples.
/* Les variables ora_... sont dclares comme prcdemment */
EXEC SQL INSERT INTO film (id_film, titre, annee, id_mes)
VALUES (:ora_id_film, :ora_titre, :ora_annee, :ora_mes);
...
EXEC SQL DELETE FROM film
WHERE id_film = :ora_id_film;
...
EXEC SQL UPDATE film SET annee = :ora_annee, id_mes = :ora_id_mes
WHERE id_film = :ora_id_film;
Valeurs nulles
On teste les valeurs nulles avec les variables indicatrices (voir ci-dessus). Une valeur de -1 aprs lexcution
dun SELECT indique que la valeur extraite de la base est nulle (spcique Oracle).
#define ORA_NULL -1
...
EXEC SQL SELECT ... INTO :ora_id_mes:vi ...
...
if (vi == ORA_NULL)
/* Lidentifiant du metteur en scne est inconnu */
...
Chapitre 4 Pratique des SGBD 79
8. Les environnements de programmation dapplications sur les
bases de donnes
Tout commence et tout nit par lutilisateur. Trois fois dans les chapitres prcdents le point de vue de
lutilisateur a t explicitement au dpart des progrs demands au SGBD :
comme concepteur et dveloppeur : ses exigences conduisent des modles et langages de richesse
smantique de plus en plus grande et indpendants de limplmentation physique ;
comme usager non informaticien : la prise en compte de sa vision propre des donnes - lie ses droits
et responsabilits - conduit la dnition des vues externes, logiquement indpendantes du schma du
concepteur ;
comme oprateur sur terminal : son temps propre - de lecture, de rexion, de frappe et/ou "cliqu" -
dnit le "temps rel" que devra respecter au mieux le systme et lui xe ainsi ses performances.
8.1 La "programmation visuelle"
8.1.1 Les interprteurs de SQL ou de QBE
Quand ladministrateur dun SGBD, ou le dveloppeur dapplication, veut interroger directement la BD,
il utilise un interprteur de SQL. Celui-ci admet gnralement l entre de texte de requte en mode
ligne ou en mode plein cran et peut formater les sorties en tableau ; des instructions supplmentaires
au SQL standard permettent le contrle du texte entr et de lachage du rsultat. Mais on ne peut pas
mettre une telle interface entre les mains dun non-informaticien. Aussi les diteurs de SGBD proposent-
ils des interprteurs de requtes qui guident lutilisateur par une succession de choix faire sur un schma
graphique des relations (rectangles) et de leurs possibles jointures (arcs joignant les rectangles). Des menus
permettent de complter logiquement les prdicats WHERE de restriction du SELECT. Lutilisateur peut,
avant ou aprs excution de sa requte, visualiser le texte SQL automatiquement gnr en tche de fond.
Le langage QBE avait, au contraire du SQL, t conu pour tre graphique ds lorigine, mais malgr
sa puissance dexpression et les enrichissement picturaux qui sont proposs encore ce jour par des
chercheurs, il reprsente encore une voie peu suivie par les diteurs de SGBD.
8.1.2 Les outils QBF et drivs OO
Presque tous les SGBD orent des gnrateurs de formulaires dachage de type "Query By Form" faits de
champs interactifs qui acceptent des valeurs ou des prdicats restrictifs mono-table et des jointures entre
tables, mais implicitement prdnies par le choix des tables aches. Cest, bien sr, smantiquement
infrieur au QBE, mais acceptable pour des applications simples et stables.
Enrichis avec la panoplie des objets graphiques et avec les mmes principes de guidage que pour les
aides la formulation de requtes SQL, on trouve, aujourdhui, des drivs "orients objet" du QBF trs
ergonomiques.
8.1.3 Les "langages visuels"
On appelle ainsi un ensemble de langages dont les lments terminaux sont des objets graphiques dans le
plan de lcran et les expressions des assemblages construits par dplacements et "cliqus" de la souris,
les identiants dobjets ou dattributs et leurs valeurs restant des lments textuels ajouts. Si certaines
de leurs rgles de construction sont reprises dans les outils QBF et drivs, leur utilisation exclusive pour
les GUI reste du domaine de la recherche : leur conception autant que la vrication de leur richesse
smantique prend toujours comme rfrence un des langages relationnels SQL ou QBE ou un modle
smantique gnral comme lEntit-Association.
80 8 Les environnements de programmation dapplications sur les bases de donnes
8.2 Langages de quatrime gnration
Ces langages, mi-visuels mi-textuels, le plus souvent interprts, sont ns en mme temps que les SGBD
Relationnels. Ils ont pour principal objectif de permettre le dveloppement dapplications sur terminaux
semi-graphiques par maquettage-prototypage beaucoup plus rapidement que par programmation et com-
pilation avec les langages classiques - COBOL, PL/1, Pascal, etc... - relgus au rang de "langages de
3me gnration" par les promoteurs de ces nouveaux outils. Leur simplicit apparente dutilisation avait
pour revers leur grande diversit de syntaxe et de capacit smantique. Aujourdhui lexistence et lutili-
sation par ces outils de bibliothques semi-graphiques ou graphiques standards et le renforcement de la
norme SQL ont cr une convergence notable.
Concernant directement les dveloppeurs dapplications, les langages de quatrime gnration visent
faire gagner du temps et baisser les cots dcriture des programmes. Ils utilisent largement les
possibilits des SGBD relationnels travers une manipulation essentiellement ensembliste des donnes.
Ils ne constituent cependant pas simplement un langage de manipulation de donnes comme SQL, mais
intgrent un ensemble complet de possibilits de traitement en fournissant des structures de contrle dun
langage structur de haut niveau (boucle, condition, parcours. . .). Ils seorcent, de surcrot, dintgrer un
ensemble doutils (gnrateurs de rapports, de graphiques, dapplications. . .) souvent disponibles comme
des logiciels adjoindre au SGBD. Orients vers la programmation visuelle, ils constituent parfois un
vritable environnement de dveloppement et sont aujourdhui lobjet dune forte demande.
Il ne faut cependant pas perdre de vue que ces langages modernes ne constituent quune couche de mani-
pulation des informations stockes dans un SGBD. La qualit, les performances, la puissance dexpression
rsulte, en dernire analyse, essentiellement la qualit du SGBD relationnel sous-jacent.
Signalons de surcrot quun L4G ne fournit aucun support une gestion de transactions (voir chapitre 6),
ncessaire tout usage multi-utilisateurs : cette gestion de transactions doit alors tre prise en compte
au niveau de lapplication. Les L4G ne sont pas lobjet dune dnition standard accepte par tous : ce
jour, le choix dun L4G particulier condamne lutilisateur une dpendance totale envers son fournisseur.
Certains L4G gnrent cependant du SQL standard, lment favorable qui peut tre pris en compte dans
le choix.
8.3 Les interfaces au standard SQL et la portabilit
8.3.1 Une portabilit encore bien relative
Un dveloppeur dapplication ne peut pas ne pas avoir le soucis de la portabilit, par rapport la varit
des terminaux et stations semi-graphiques et graphiques, dune part, et par rapport la varit des
SGBD, dautre part. Il y a deux faons de le faire : soit il programme, par exemple en C, en utilisant une
bibliothque de procdures standards pour les entres-sorties graphiques et lEmbedded SQL pour les
entres-sorties de donnes de la base, soit il programme en L4G et rcupre, aprs mise au point complte
et traduction, un programme intermdiaire en C incluant des appels de procdures de X11 Motif et
des blocs cods en Embedded SQL. Mais deux limitations de portabilit subsistent : - les spcications
des procdures de la bibliothque semi-graphique curses(3v) ou de la bibliothque graphique X11 Motif
assurent la portabilit, et mme, dans le monde Unix standard, lindpendance physique par rapport
lcran. Elles ne valent nanmoins pas pour le monde PC sous MS Windows, ni pour le monde Macintosh.
- la prcompilation, qui traduit les blocs de code Embedded SQL en appels de procdures de dnition ou
de manipulation des donnes de la base, ne peut se faire quen prsence dun SGBD et le code C obtenu
reste ensuite li par ces appels de procdures ce SGBD particulier.
8.3.2 Vers une ouverture plus grande
Selon que lapplication regarde vers linterface graphique ou vers la BD leort pour une plus grande
ouverture nest pas de mme nature : - le code de lapplication sexcute sur le PC ou la station donc
avec lunique window manager de ce systme, le problme pour le dveloppeur est donc seulement un
problme classique de compilation multi-cibles partir dun code source commun. La spcication dune
bibliothque source graphique commune relve donc du choix de lditeur de L4G et de son client pour
le temps du dveloppement seulement.
Chapitre 4 Pratique des SGBD 81
- par contre une compilation dEmbedded SQL ne pouvant se faire quavec un SGBD donn, ce PC
ou cette station ne peut plus, pendant lexploitation, quaccder ce SGBD. Il faudrait simultanment
lancer lexcution dun autre code compil - du mme source, mais avec un autre SGBD - pour accder
un autre SGBD depuis le mme PC ou la mme station. Ce besoin dinterconnectivit a t trs tt
exprim par les clients, aussi les diteurs de L4G se sont-ils concerts ds aprs ladoption du SQL1 pour
spcier un niveau commun dappels de procdures pour manipuler les BD. Il a t adopt en 1991 par
le consortium X/Open sous le nom de Call Level Interface (ou CLI) et est candidat la normalisation
par lISO. On voit ainsi se prgurer symtriquement deux bibliothques programmatiques standards -
ou Application Programmatic Interfaces (API) - une pour les entres-sorties ct terminal, lautre pour
les entres-sorties ct SGBD, qui, ensemble, donneront le maximum de portabilit et dinterconnectivit
aux applications sur BD.
8.4 Les ateliers de gnie logiciel (AGL / CASE)
Les cibles pour le dveloppement dapplications multi-utilisateurs sur BD apparaissent maintenant com-
pltement :
la mtabase - Information Schema - du SGBD : cest le rceptacle des dnitions logiques et physiques
des tables, vues, contraintes dintgrit, droits, index, procdures et dune faon gnrale de tout ce qui
peut constituer le dictionnaire de dnition et de manipulation catalogue des donnes ;
les PC ou stations et leurs bibliothques graphiques : ils recevront les codes excutables des programmes
applicatifs, de prfrence par tlchargement et conguration automatique ;
la base elle-mme : avec ncessairement son "peuplement" initial de donnes, mais aussi, dans des
"annexes" spcialement prvues cet eet, les "images" des applications qui seront sauvegardes ou
exportes en mme temps que les donnes, ce qui, somme toute, peut rendre de grands services pour
la scurisation du systme applicatif tout entier.
Quels outils rassembler pour une telle production logicielle et dans quel atelier les trouver ou les intgrer ?
8.4.1 Outils dtachs
Quel est la panoplie minimale doutils ? En gnral, on souhaite au moins y trouver, dans lordre des
productions cites ci-dessus :
un outil daide la conception du schma logique des donnes, dot de plus ou moins dexpertise,
ventuellement tendu pour laide la conception du schma physique ;
des gnrateurs dapplications pour interfaces graphiques mais aussi des gnrateurs de rapports im-
prims ;
des chargeurs de donnes pour le peuplement initial de la BD partir de chier externes de formats
varis ; auquels il faut ajouter les outils dexploitation pour les administrateurs du SGBD et des BD :
- un moniteur des ressources statiquement ou dynamiquement alloues ;
des outils dexport et dimport .
8.4.2 Ateliers intgrs
Que lon suive ou non des mthodes gnrales de gestion des projets de dveloppement logiciel - MERISE
ou lune des nouvelles mthodes Oriente Objet - on peut vouloir se doter dun environnement intgr
pour rassembler de faon cohrente, avec une gestion minimale des versions des congurations - SCCS,
SRCS ou mieux - toutes les pices de la production dune application sur BD, sans oublier laide en ligne,
la documentation papier et les jeux et procdures de validation.
Trois stratgies sont alors possibles :
lachat de latelier dun diteur de SGBD qui fait de lintgration verticale, avec le confort dune
validation garantie par celui-ci pour toutes les tapes du cycle de production dapplications sur ce
SGBD, et, galement, avec les garanties de portabilit et douverture oertes par cet diteur, mais avec
le danger dune dpendance grandissante par rapport cet diteur (ses limites seront vos limites) ;
82 Chap.5 : Ralisation physique des bases de donnes
lachat dun atelier indpendant par rapport aux dirents SGBD comme par rapport aux direntes
interfaces graphiques, mais aussi par rapport lintgration des autres outils dtachs de production,
comme les outils de "middleware" pour les architectures clients-serveurs ;
la constitution de son propre atelier sur un standard ouvert comme par exemple le "Portable Common
Tool Environment" (PCTE) sous Unix, permettant lintgration de tous les outils souhaits dont aucun
nimposera son environnement aux autres.
Chapitre 5
R ealisation physique des bases de
donn ees
Sommaire
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2 Techniques de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.1 Stockage de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.2 Organisation des chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.3 Organisation primaire des chiers . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.4 Lexemple du SGBD Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3 Structures de donnes pour optimiser les accs . . . . . . . . . . . . . . . . 87
3.1 Indexation de chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.2 Hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.3 Larbre-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4 Autres mthodes dindexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.6 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.7 Quelques rgles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.8 Indexation dans Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.9 Index en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.10 Structures de donnes multidimensionnelles . . . . . . . . . . . . . . . . . . . . 105
4 valuation des requtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.1 Introduction loptimisation des performances . . . . . . . . . . . . . . . . . . 105
4.2 Algorithmes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.3 Algorithmes de jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.4 Compilation dune requte et optimisation . . . . . . . . . . . . . . . . . . . . . 106
4.5 Oracle : optimisation et valuation des requtes . . . . . . . . . . . . . . . . . . 106
5 Vision globale sur lexcution dune requte SQL . . . . . . . . . . . . . . . 106
6 Optimisation de laccs une table . . . . . . . . . . . . . . . . . . . . . . . . 106
84 1 Introduction
1. Introduction
Gnralement, les bases de donnes sont trop volumineuses pour tenir en mmoire centrale.
Par ailleurs, les oprations routinires dun SGBD incluent :
1. Insertion dun enregistrement ;
2. Recherche dun enregistrement ;
3. Mise jour dun enregistrement ;
4. Destruction dun enregistrement.
Ces oprations peuvent donc impliquer un nombre, parfois trs grand, daccs la mmoire secondaire
qui est beaucoup plus lente que la mmoire centrale (dans un rapport denviron 100000).
An dacclrer lensemble du processus, on essaye damliorer les performances des supports mmoires.
Mais cela serait largement insusant pour changer la nature du problme, et on a galement recours
des techniques dorganisation particulires des informations permettant de diminuer les accs en mmoire
secondaire. Lune des structures les plus employe consiste dnir des index.
Ces index sont essentiellement la charge de ladministrateur ou du concepteur de la base de donnes. Il
est donc important de bien les comprendre.
Pour rsumer : Les donnes stockes sur le disque sont organises en chiers denregistrements.
Il faut pouvoir les localiser rapidement
et minimiser le nombre daccs car la mmoire secondaire est lente.
2. Techniques de stockage
2.1 Stockage de donnes
2.1.1 Les supports physiques
Mmoire centrale ou primaire. DRAM et RAM.
Mmoire secondaire. Disques magntiques, CD-ROM, bandes magntiques, ...
2.1.2 Fonctionnement dun disque et enregistrement des donnes
Un disque est divis en secteurs, un secteur constituant la plus petite surface dadressage. On sait donc
lire ou crire des zones dbutant sur un secteur et couvrant un nombre entier de secteurs. La taille dun
secteur est le plus souvent de 512 octets.
Le systme dexploitation xe une unit dentre/sortie ventuellement suprieure la taille dun secteur,
et multiple de cette dernire. On obtient des blocs, dont la taille est typiquement 512 octets (un secteur),
1024 octets (deux secteurs) ou 4096 octets (huit secteurs).
Chaque piste est donc divise en blocs (ou pages) qui constituent lunit dchange entre le disque et la
mmoire principale.
Toute lecture ou toute criture sur les disques seectue par blocs, et ceci mme si la donne manipule ne
concerne que 4 octets par exemple. Tout le bloc contenant ces 4 octets sera transmis en mmoire centrale.
Un des objectifs des SGBD est de sarranger pour que lorsquun bloc est transmis, les donnes a priori
superues transmises en mme temps que la donne dsire, aient cependant de grandes chances dtre
Chapitre 5 Ralisation physique des bases de donnes 85
utiles a court terme alors quelles seront encore charges en mmoire centrale. Ainsi des informations
corrles logiquement devraient tre stockes sur des segments proches physiquement. Cette motivation
est la base du mcanisme de regroupement qui fonde, notamment, les structures dindex et de hachage.
Compromis sur la taille des pages
Grande taille -> les donnes lies x ont des chances dtre stockes sur la mme page, do rduction
des accs aux pages
Petite taille -> rduit le temps de transfert et rduit la taille du buer en mmoire centrale
Taille typique : 4096 octets
Contrairement une bande magntique, par exemple, les disques sont accs direct.
La lecture dun bloc, tant donne son adresse, se dcompose en trois tapes :
positionnement de la tte de lecture sur la piste contenant le bloc ;
rotation du disque pour attendre que le bloc passe sous la tte de lecture (rappelons que les ttes sont
xes et que cest le disque qui tourne) ;
transfert du bloc.
La dure dune opration de lecture est donc la somme des temps consacrs chacune de ces trois
oprations, ces temps tant dsigns respectivement par les termes dlai de positionnement, dlai de
latence et temps de transfert. Le temps de transfert est ngligeable pour un bloc, mais peut devenir
important quand des milliers de blocs doivent tre lus. Le mcanisme dcriture est peu prs semblable,
mais peut prendre un peu plus de temps si le contrleur vrie que lcriture sest faite correctement.
2.1.3 Technologie RAID
Un systme RAID ( Redundant Array of Independent Disks ) est un ensemble de disques congurs de
telle manire quils apparaissent comme un seul disque avec :
Une vitesse de transfert accrue
Des demandes des disques dirents peuvent tre traites indpendamment
Si une requte concerne des donnes stockes sparment sur plusieurs disques, les donnes peuvent
tre transfres en parallle
Une plus grande abilit
Les donnes sont stockes de manire redondante
Si un disque tombe en panne, le systme peut continuer oprer
2.2 Organisation des chiers
Une base de donnes nest rien dautre quun ensemble de donnes stockes sur un support persistant.
La technique de trs loin la plus rpandue consiste organiser le stockage des donnes sur un disque au
moyen de chiers.
Sauf exception (par exemple, MysQL qui a choisi le parti-pris dune simplicit maximale), les SGBD
ont leur propre module de gestion de chiers et de mmoire cache, ct de celui utilis par le systme
dexploitation hte.
Le terme dorganisation pour un chier dsigne la structure utilise pour stocker les enregistrements du
chier. Une bonne organisation a pour but de limiter les ressources en espace et en temps consacres
la gestion du chier.
Espace. La situation optimale est celle o la taille dun chier est la somme des tailles des enregistre-
ments du chier. Cela implique quil y ait peut, ou pas, despace vide dans le chier.
Temps. Une bonne organisation doit favoriser les oprations sur un chier. En pratique, on sintresse
plus particulirement la recherche dun enregistrement, notamment parce que cette opration condi-
tionne lecacit de la mise jour et de la destruction. Il ne faut cependant pas ngliger le cot des
insertions.
Il est dicile de garantir une utilisation optimale de lespace tout moment cause des destructions et
modications. Une bonne gestion de chiers doit avoir pour but, entre autres, de rorganiser dynamique-
ment le chier an de prserver une utilisation satisfaisante de lespace.
Lecacit en temps dune organisation de chier se dnit en fonction dune opration donne (par
exemple, linsertion ou la recherche) et se mesure par le rapport entre le nombre de blocs lus et la taille
totale du chier. Pour une recherche par exemple, il faut, dans le pire cas, lire tous les blocs du chier
86 2 Techniques de stockage
pour trouver une enregistrement, ce qui donne une complexit linaire en la taille du chier. Certaines
organisations de chier permettent deectuer des recherches en temps sous-linaire : arbres-B (temps
logarithmique) et hachage (temps constant), par exemple.
Il existe plusieurs organisations primaires de chiers, qui dterminent la faon dont les enregistre-
ments sont placs physiquement sur le disque, et donc la faon dont il possible daccder ces enregistre-
ments.
Dans un chier plat (ou chier non ordonn), les enregistrements sont placs sur le disque sans observer
dordre particulier et les nouveaux enregistrements sont simplement ajouts en n de chier.
Dans un chier tri (ou chier squentiel ), ils sont ordonns en fonction de la valeur dun champ
particulier nomm cl de tri.
Un chier hach utilise une fonction de hachage applique un champ particulier (la cl de hachage).
Dautres organisations primaires, les arbres-B par exemple, utilisent des structures arborescentes.
Une organisation secondaire, ou structure daccs auxiliaire, permet daccder rapidement aux
enregistrements en se basant sur dautres champs que ceux qui ont servi pour lorganisation primaire.
2.3 Organisation primaire des chiers
2.3.1 Fchiers squentiels non ordonns ( heap les )
Type dorganisation le plus simple. Les enregistrements sont placs dans le chier dans lordre de leur
insertion.
Insertions/modications dun tuple :
En moyenne F/2 pages (ou blocs) sont lues (donc transfres) si la page existe dj
F + 1 pages transfres si la page nexiste pas
Eacement dun tuple :
En moyenne F/2 pages sont lues (donc transfres) si la page existe dj
F pages transfres si la page nexiste pas
2.3.2 Fchiers squentiels ordonns ( sorted les )
Les enregistrements sont ordonns physiquement sur disque en fonction des valeurs dun de leurs champs
(champ dordonnancement).
Si le champ dordonnancement est la cl primaire, le champ est appel cl dordonnancement.
Avantages :
Les requtes bases sur le champ dordonnancement ont un cot moyen de log
2
F par recherche binaire ;
Si les requtes concernent des tuples successifs, lutilisation de cache est trs ecace
Aucun avantage si laccs se fait par dautres attributs que le champ dordonnancement.
Problme (maintien de lordre) :
Cot moyen : log
2
F| lectures (pour trouver lendroit par recherche dichotomique) + F/2 critures
(an de pousser les enregistrements suivants)
Solution partielle 1 : Laisser des espaces libres
Solution partielle 2 : Utilisation de pages doverow (et tri de temps en temps)
Dsavantages
Les pages successives ne sont plus ncessairement stockes la suite
Les pages overow ne sont pas dans lordre
On attend des priodes de moindre activit de la base de donnes pour re-trier les enregistrements.
Chapitre 5 Ralisation physique des bases de donnes 87
Overflow
3
111111 MGT123 F1994 4.0
111111 CS305 S1996 4.0 page 0
111111 ECO101 F2000 3.0
122222 REL211 F2000 2.0
-
123456 CS315 S1997 4.0
123456 EE101 S1998 3.0 page 1
232323 MAT123 S1996 2.0
234567 EE101 F1995 3.0
-
234567 CS305 S1999 4.0
page 2
313131 MGT123 S1996 3.0
7
111654 CS305 F1995 2.0
111233 PSY 220 S2001 3.0 page 3
Pointer to
overflow chain
Pointer to
next block
in chain
These pages are
Not overflown
Fig. 5.1: Organisation de chier squentiel avec Overow.
2.4 Lexemple du SGBD Oracle
2.4.1 Fichiers et blocs
2.4.2 Les tablespaces
2.4.3 Cration des tables
3. Structures de donnes pour optimiser les accs
tant donn que les bases de donnes sont gnralement de taille importante, elles doivent tre stockes
en mmoire secondaire, mme lors des traitements. De ce fait, et pour optimiser les temps de raction, le
but est en particulier de minimiser le nombre daccs aux units de mmoire externe lors des oprations
de lecture ou dcriture dans les tables.
Une organisation de chier russie devrait pouvoir excuter ecacement les oprations que nous pensons
appliquer frquemment au chier.
Exemple
Si condition de recherche frquente sur le numro de Scurit Sociale, il faut favoriser la localisation
par rapport la valeur de NoSS.
?==> Soit trier par rapport NoSS, soit dnir un index sur NoSS.
Si, en plus, recherche demploys par service, il faudrait stocker tous les enregistrements des em-
ploys dont la valeur de SERVICE est identique de faon contigu. Mais cet arrangement est en
conit avec les enregistrements classs sur la valeur de NoSS ?
==> Il faut trouver un compromis : optimisation
3.1 Indexation de chiers
Types de recherches :
Recherche par cl
Recherche par intervalle
Recherche multi-attributs
88 3 Structures de donnes pour optimiser les accs
3.1.1 Index primaires, de regroupement et secondaires
Un index ordonn est un index, gnralement construit sur un attribut (ou champ) de la table indexer
(e.g. sa cl primaire), et class selon le mme ordre que les lments de la table. Par exemple, la table
des matires dun livre est une sorte dindex ordonn. Le chier dindex tant beaucoup plus petit que le
chier principal, il est beaucoup plus facile consulter. Le fait quil soit ordonn permet deectuer une
recherche binaire.
Un index est dit primaire si le champ de tri sert ordonner phyiquement les enregistrements en mmoire
secondaire. Une consquence est quil ne peut y avoir au plus quun index primaire.
Si plusieurs enregistrements peuvent avoir la mme valeur pour le champ de tri (qui nest donc pas la cl
primaire), on parle dindex de regroupement.
Un index secondaire sert acclrer les oprations sur les tables, mais il peut tre spci sur nimporte
quel champ et son classement ne correspond pas lorganisation physique des enregistrements.
Il ne peut donc y avoir plus dun seul index primaire alors quil peut y avoir plusieurs index secondaires.
Index primaire
Un index primaire est un chier ordonn dont les enregistrements sont de taille xe et comportant deux
champs 'K(i), P(i)` :
1. Le premier champ est du mme type de donne que celui du champ de la cl de tri (par exemple le
nom ou le numero_SS) ;
2. Le second champ est un pointeur sur un bloc du disque (ladresse dun bloc).
Il existe une entre dindex pour chaque bloc du chier de donnes. Chacune de ces entres contient
donc deux champs, dune part, la valeur du champ de la cl primaire du premier enregistrement du bloc
adress, dautre part le pointeur sur ce bloc (son adresse).
La gure 5.2 montre un tel index. Le nombre total dentres dans lindex est identique au nombre de
blocs de disque dans le chier de donnes ordonn. Le premier enregistrement de chaque bloc est appel
enregistrement dancrage du bloc ou encore ancre du bloc.
Les index peuvent aussi tre caractriss par leur densit. Un index dense contient une entre dindex pour
chacune des valeurs de la cl de recherche (et donc pour chaque enregistrement) du chier de donnes.
A linverse, un index non dense ne contient dentre dindex que pour certaines des valeurs sur lesquelles
il y a des recherches eectuer. En consquence, un index primaire nest pas dense puisquil contient
une entre pour chaque bloc de disque du chier de donnes et non pour chaque valeur de recherche (ou
chaque enregistrement).
Le chier dun index primaire ncessite beaucoup moins de blocs que le chier de donnes pour deux
raisons :
Dabord, il y a moins dentres dindex quil ny a denregistrements dans le chier de donnes (index
non dense) ;
Ensuite, la taille de chaque enregistrement dindex est normalement bien infrieure celle dun enre-
gistrement de donnes.
Pour extraire un enregistrement tant donn la valeur K du champ de la cl primaire, on entreprend une
recherche binaire sur le chier de lindex pour retrouver lentre dindex i approprie et on rcupre le
bloc du chier de donnes dont ladresse est P(i) (pointeur associ).
Exemple Taille de lindex primaire
Soit un chier de 30 000 enregistrements, chacun de 100 octets. Soit des blocs de 1024 octets. Il tient
donc 10 enregistrements par bloc, avec une perte de 24 octets pour chaque bloc.
En tout, il faut donc 3 000 blocs pour contenir les donnes.
Une recherche binaire sur le chier ncessite peu prs ]log
2
3000 = 12 accs blocs.
Soit un index primaire construit partir dun champ de cl de tri de 9 octets et dun pointeur de
bloc de 6 octets, soit 15 octets par entre dindex. Il y a donc ]1024/15 = 68 entres dindex par
bloc. Et il y a 3 000 entres dindex puisque cest un index dense. Do le besoin de ]3000/68 = 45
blocs pour contenir lindex.
Une recherche binaire sur ces blocs ncessite peu prs ]log
2
45 = 6 accs bloc, auxquels il faut
ajouter un accs bloc pour aller chercher le bloc de donnes.
Chapitre 5 Ralisation physique des bases de donnes 89
Fig. 5.2: Exemple dindex primaire.
Le gain est donc de 5 = 12 7 accs sur cet exemple de taille assez rduite.
Le grand problme pos par un index primaire (comme pour nimporte quel chier ordonn) est ce-
lui de linsertion et de la suppression denregistrements. Un index primaire accrot le problme parce
que linsertion dun enregistrement sa position approprie dans le chier provoque non seulement le
dplacement des enregistrements pour faire de la place un nouvel enregistrement, mais aecte aussi
des entres dindex, puisque le dplacement denregistrements modie les enregistrements dancrage de
plusieurs blocs.
Lemploi dun chier de dbordement (unordered overow le) peut rsoudre en partie ce problme.
Index de regroupement
On peut crer des index sur des cls non spciques chaque enregistrement mais qui dont lordre est
lordre physique denregistrement des donnes dans le chier.
Un index de regroupement est aussi un chier ordonn contenant des articles deux champs :
1. Le premier champ est du mme type de donnes que le champ de regroupement qui sert de champ
dindexation ;
2. Le second champ contient un pointeur de bloc pointant sur le premier enregistrement du bloc o
est situ un champ de donn comportant la valeur spcie par le premier champ.
Linsertion et la suppression posent les mmes problmes que pour un index primaire puisque les enre-
gistrements de donnes sont physiquement ordonns selon la cl de regroupement.
Un index de regroupement est un autre exemple dindex non dense.
90 3 Structures de donnes pour optimiser les accs
Fig. 5.3: Exemple dindex de regroupement.
Index secondaires
Un index secondaire peut porter sur un champ cl qui est une cl candidate et a une valeur unique pour
chaque enregistrement, ou bien sur un champ non-cl comportant des valeurs dupliques.
Lindex est un chier tri avec deux champs :
1. Le premier champ est du mme type de donnes que le champ non ordonn du chier de donnes
qui sert de champ dindexation ;
2. Le second champ est soit un pointeur de bloc (index non dense), soit un pointeur denregistrement
(index dense).
Il peut y avoir plusieurs index secondaires (et par suite plusieurs champs dindexation) pour un mme
chier.
Nous nous intressons dabord une structure dindex secondaire reposant sur un champ cl ayant une
valeur distincte pour chaque enregistrement, cest--dire reposant sur une cl secondaire. Il sagit dun
index dense.
Notons 'K(i), P(i)` les deux valeurs des champs dune entre i dindex. Les entres sont tries en fonction
de la valeur de K(i), ce qui rend possible une recherche binaire. Comme les enregistrements du chier
de donnes ne sont pas physiquement ordonns en fonction de la valeur du champ de la cl secondaire,
il nest pas possible demployer des ancrages de blocs. Cest la raison pour laquelle une entre dindex
est cre pour chaque enregistrement du chier de donnes. Mais le pointeur P(i) donne ladresse du bloc
dans lequel se trouve la donne recherche. Ce nest donc que lorsque le bloc appropri est transfr en
mmoire centrale quil est possible dentreprendre la recherche de lenregistrement souhait lintrieur
de celui-ci.
Normalement, un index secondaire ncessite davantage despace de stockage quun index primaire cause
de son plus grand nombre dentres (si il est dense). Cependant, lamlioration du temps de recherche
est signicative, car sinon, il faudrait entreprendre une recherche squentielle sur le chier de donnes
lui-mme.
Exemple Taille de lindex secondaire
Idem exemple prcdent, sauf que recherche squentielle sur chier des donnes demande en moyenne
3000/2 = 1500 accs blocs.
Chapitre 5 Ralisation physique des bases de donnes 91
Fig. 5.4: Exemple dindex secondaire dense (avec des pointeurs de blocs) sur un champ cl non utilis
pour le tri dun chier.
Ave index secondaire (dense), on a 30 000 entres dindex de 15 bits chacune, et 68 entres par bloc,
soit ]30000/68 = 442 blocs.
Une recherche binaire ncessite donc peu prs ]log
2
442 = 9 accs bloc, auquel il faut ajouter
laccs au bloc de donnes.
Le gain est donc substanciel : de 1500 10.
Il est galement possible de crer un index secondaire sur un champ non-cl. Dans ce cas, plusieurs
enregistrements du chier de donnes peuvent avoir la mme valeur pour le champ dindexation. Plusieurs
options existent pour implmenter un tel index. Nous renvoyons le lecteur [EN00] pp.375-376, par
exemple pour obtenir davantage de dtails.
Remarque
Il est possible de crer autant dindex denses que lon veut puisquils sont indpendants du chier de donnes.
Ce nest pas le cas dun index non-dense car il sappuie sur le tri du chier et quun chier ne peut tre tri que
dune seule manire.
3.1.2 Index multi-niveaux
Il peut arriver que la taille du chier dindex devienne elle-mme si grande que les recherches dans lindex
en soient pnalises. Cest le cas particulirement si lindex lui-mme est si grand quil doit tre stock
en mmoire secondaire. La solution naturelle est alors dindexer le chier dindex lui-mme.
Un index multi-niveaux permet de gnraliser lapproche de la recherche par dichotomie. Chaque niveau
de lindex est compos dentres dindex comprenant deux champs (voir gure 5.7) :
1. Le premier champ est du mme type de donnes que le champ du chier de donnes qui sert de
champ dindexation ;
92 3 Structures de donnes pour optimiser les accs
Fig. 5.5: Exemple dindex secondaire (avec des pointeurs denregistrement) sur un champ non cl impl-
ment avec un niveau dindirection de manire ce que les entres dindex aient une valeur xe
et que la valeur de leur champ soit unique.
Fig. 5.6: Un index multi-niveaux.
2. Le second champ est un pointeur de bloc (index non dense).
chaque niveau de lindex, le facteur de branchement br est contrl par le nombre dentres dindex
pouvant tre stockes dans un bloc. Dans la gure 5.7, le facteur de branchement est de 4.
Supposons que le chier contienne F enregistrements (tuples) et que le nombre dentres dindex par bloc
soit de br, alors, avec un seul niveau dindexation, il sut dun seul accs la mmoire secondaire (dans
Chapitre 5 Ralisation physique des bases de donnes 93
ce cas, en eet, lindex est suppos tenir en mmoire principale, et il sut de positionner la condition
de requte par rapport aux valeurs de cl dans lindex pour connatre le bloc charger et explorer
en mmoire secondaire. Un seul niveau est susant tant que le nombre de blocs associ la table en
mmoire secondaire est < br. Dans le cas contraire, il faut avoir recours au moins un niveau dindex
supplmentaire. Par exemple, avec deux niveaux dindex, il est possible daccder br
2
blocs en mmoire
secondaire, et le nombre daccs pour une requte est de 2 : un accs pour atteindre le bloc pertinent
au premier niveau de lindex, puis un accs pour accder au bloc contenant le ou les enregistrements
recherchs.
Le nombre de niveaux ncessaires pour un chier contenu dans b blocs est ainsi de log
br
b|. (E.g. avec
un facteur de branchements br = 10, il faut 6 niveaux pour indexer un chier de 1000000 = 10
6
blocs).
Exemple Taille de lindex multi-niveaux
On suppose que lindex secondaire dense de lexemple 2 est converti en index multi-niveaux.
Le facteur de branchement est donc de 68 entres dindex par bloc.
Le nombre de blocs de premier niveau est de b
1
= 442. Le nombre de blocs du deuxime niveau de
lindex sera donc de b
2
= ](b
1
/br) = ](442/68) = 7 blocs. Le nombre de blocs de troisime niveau
sera donc de 1 (68 > 7).
Il en rsulte que le nombre daccs ncessaire pour atteindre un bloc de la table indexe est de 3 +
1 (un accs par niveau de lindex (en supposant que le troisime niveau soit lui-mme en mmoire
secondaire) + 1 accs au bloc de la table).
Ceci est comparer aux 10 accs ncessaire avec une recherche binaire sur un index un niveau.
Les index multi-niveaux sont trs ecaces en recherche, et ce mme pour des jeux de donnes de trs
grande taille. Le problme rside, comme toujours, dans la dicult de maintenir des chiers tris sans
dgradation de performances. Larbre-B reprsente laboutissement des ides prsentes jusquici puisqu
des performances quivalentes celles des index en recherche, il ajoute des algorithmes de rorganisation
dynamique qui garantissent que la structure reste valide quelles que soient les squences dinsertions et
de suppressions dans les donnes. Nous y reviendrons dans la section 3.3.
3.2 Hachage
Une fonction de hachage ( hash function ) permet de transformer une cl en une adresse.
Par exemple, pour un nom demploy donn, la fonction retournera ladresse dun bloc en mmoire o se
trouve lenregistrement associ cet employ.
Une mthode de transformation simple consiste attribuer une adresse (reprsente par un nombre
naturel de 1 n) chaque valeur de cl choisie dans une table. Cette adresse est interprte comme
un numro de page relatif. Chaque page contient un nombre xe de valeurs de cl, avec ou sans les
enregistrements de donnes correspondants.
La transformation des cls doit satisfaire les critres suivants :
La mthode de transformation doit comporter des oprations simples et non onreuses.
Les adresses rserves doivent tre uniformment distribues dans leur espace dadressage.
La probabilit dattribuer une mme adresse plusieurs valeurs de cl doit tre identique pour toutes
les valeurs de cls.
Il est noter que la condition de recherche ne peut tre quune condition dgalit sur le champ de
hachage.
Il existe une grande varit de fonctions de hachage avec leurs avantages et leurs inconvnients. La
mthode la plus connue et la plus simple est le hachage utilisant le reste dune division.
3.2.1 Principes de base
Supposons que nous ayons M emplacements (e.g. des blocs) dans lesquels stocker nos donnes. An
dutiliser une fonction de hachage, nous devrons disposer dune table associant lentier 0, . . . , M1
une adresse de bloc.
94 3 Structures de donnes pour optimiser les accs
Fig. 5.7: Exemple dindex primaire deux niveaux.
Une fonction de hachage couramment utilise est :
h(K) = f(K) mod M (5.1)
o K est la cl de hachage et f est une fonction transformant la cl en un entier. On pourrait par exemple
imaginer que f calcule la somme des caractres ASCII correspondant la valeur de la cl de hachage.
En gnral, on choisit M comme un nombre premier, ce qui assure une meilleure rpartition des valeurs
de la fonction h.
Exemple Table de hachage
Soit un ensemble de lms auquel nous voulons accder grce une table de hachage sur le titre.
On suppose que chaque bloc contient au plus quatre lms et que lensemble des 16 lms de la base
actuelle occupe donc au moins 4 blocs. An davoir un plus grand degr de libert, on aecte 5 blocs,
numrots de 0 4, la collection de lms.
On dnit une fonction prenant en entre le titre dun lm et produisant en sortie un numro de bloc.
Cette fonction doit satisfaire aux critres :
1. le rsultat de la fonction, pour nimporte quelle chane de caractres, doit tre une adresse de
bloc, soit, ici, un entier compris entre 0 et 4 :
2. la distribution du rsultat de la fonction doit tre uniforme sur lintervalle [0, 4].
Si le premier critre est relativement facile satisfaire, le second est plus problmatique car lensemble
des chanes de caractres auxquelles sapplique la fonction de hachage possde souvent des proprits
statistiques spciques. par exemple, dans le cas des titres de lms en franais, les chanes de caractres
commencent souvent par La ou Le.
Pour notre exemple, nous utiliserons une mthode simple. On aecte chaque lettre son rang dans
lalphabet, soit 1 pour a, 2 pour b, etc. Puis, pour se ramener une valeur dans [0, 4], on utilisera
la fonction modulo.
h(titre) = rang(titre[0]) mod 5
Chapitre 5 Ralisation physique des bases de donnes 95
Fig. 5.8: Exemple de table de hachage.
La gure 5.8 montre la table de hachage obtenue avec cette fonction. Tous les lms commenant par
a, f, k, p, u et z sont aects au bloc 1, les lettres b, g, l, q et v sont aectes au bloc 2, etc.
La gure 5.8 prsente, outre les 5 blocs stockant les lms, un rpertoire 5 entres permettant
dassocier une valeur entre 0 et 4 ladresse dun bloc sur le disque. Ce rpertoire fournit une
indirection entre lidentication logique du bloc et son emplacement physique. Ce rpertoire est
gnralement de taille susamment limite pour tenir en mmoire principale.
Cette fonction est garantie de retourner une valeur entre 0 et 4, mais la distribution risque de ne pas
tre uniforme. Ainsi, le bloc 2 auquel les lms commenant par la lettre l sont aects, risque en eet
dtre dbord. Cest pourquoi en pratique on utilise un calcul moins sensible ce type de biais. Par
exemple, on considrera les 4 ou 8 premiers caractres du titre. Aprs avoir associ ces caractres
leur rang dans lalphabet, on prend la somme et on utilise la fonction de hachage sur cette somme.
3.2.2 Recherche dans une table de hachage
La structure de hachage permet les recherches par titre, ou par le dbut dun titre. Par exemple :
SELECT *
FROM Film
WHERE titre = Impitoyable :
Pour valuer cette requte, il sut dappliquer la fonction de hachage la premire lettre du titre, i ici,
qui a pour rang 9. Le reste de la division de 9 par 5 est 4, et on peut donc charger le bloc 4 et y trouver
le lm Impitoyable. En supposant que le rpertoire tienne en mmoire centrale, la recherche a donc pu
seectuer en lisant un seul bloc, ce qui est optimal. On voit donc ici les deux avantages dune table de
hachage :
1. La structure noccupe pas despace mmoire secondaire, contrairement larbre-B, comme nous
verrons :
2. Elle permet deectuer des recherches par cl par accs direct (calcul) au bloc susceptible de
contenir les enregistrements.
En revanche, le hachage ne permet pas doptimiser des requtes par intervalle puisque lorganisation des
enregistrements ne sappuie pas sur lordre des cls. Ainsi la requte suivante entrane laccs tous les
blocs de la structure.
SELECT *
FROM Film
WHERE titre BETWEEN Annie Hall AND Easy Rider ;
Cette incapacit eectuer ecacement des recherches par intervalle doit mener prfrer larbre-B dans
tous les cas o ce type de recherche est envisageable. Cest le cas, souvent, dune cl reprsentant une
date.
96 3 Structures de donnes pour optimiser les accs
3.2.3 Mise jour dune table de hachage
La structure en table de hachage est mal adapte, dans sa version simple, aux mises jour. Ainsi, dans
le cas des insertions, lespace initial calcul peut ne plus tre susant et conduite au dbordement de
blocs. Par exemple, dans la gure 5.9, linsertion du nouveau lm Citizen Kane doit se faire dans le
bloc 3, mais celui-ci est dj plein. Il faut alors chaner de nouveaux blocs. ladresse 3 dans le rpertoire
correspondent maintenant 2 blocs chans. Cela signie quau lieu dun seul accs en mmoire secondaire,
il peut maintenant arriver que deux soient ncessaires (voir gure 5.9).
Fig. 5.9: Exemple de table de hachage.
Dans le pire cas o on a mal valu les proprits statistiques de distribution des lettres des lms, on
pourrait se retrouver avec un simple chier squentiel, avec comme en consquence une dgradation
catastrophique des performances.
Ce type de structure nest pas dynamique et ne permet pas une volution en fonction de la croissance de
la base de donnes.
Par ailleurs, le hachage est une structure dite plaante, cest--dire qui dicte le placement en mmoire
des enregistrements. Il ne peut donc pas y avoir plusieurs index organiss selon une table de hachage.
3.2.4 Hachage extensible
Le hachage extensible permet dadapter le placement des donnes dans les blocs en fonction des insertions
passes de manire viter les chanages de blocs prjudiciables aux performances.
Plutt que den donner une description gnrale, nous en illustrons le principe laide dun exemple.
Soit une fonction de hachage dont le rsultat est un octet, soit 8 bits. La table suivante donne les rsultats
pour 8 lms.
Titre h(titre)
Vertigo 01110010
Brazil 10100101
Twin Peaks 11001011
Underground 01001001
Easy Rider 00100110
Psychose 01110011
Greystocke 10111001
Shinning 11010011
On suppose que seuls trois lms peuvent tre stocks par bloc.
La gure 5.10 ( gauche) montre le rsultat de linsertion des 5 premiers lms et leur aectation lun
de deux blocs. Tous les lms dont la valeur de hachage commence par 0 sont aects au bloc 0, tandis
que ceux dont la veleur commence par 1 sont aects au bloc 1.
Chapitre 5 Ralisation physique des bases de donnes 97
Linsertion de Psychose, dont la valeur de hachage est 01110011, entrane le dbordement du bloc 0.
On va alors doubler la taille du rpertoire, et le nombre de blocs potentiels. Les nouvelles valeurs seront
00, 01, 10 et 11, avec la nouvelle organisation :
Les lms associe lancienne valeur 0 sont maintenant rpartis sur les valeurs 00 et 01 en fonction
de la valeur de leurs deux premiers bits de hachage. Ainsi, Easy Rider dont la valeur de hachage
commence par 00 est plac dans le premier bloc, tandis que Vertigo, Underground et Psychose,
dont les valeurs de hachage commencent par 01 sont placs dans le deuxime bloc.
les lms associs lancienne valeur 1 restent sur un seul bloc, de double adresse 10 et 11, puisquil ny
a pas de dbordement.
Le rsultat est illustr sur la gure 5.10 ( droite).
Fig. 5.10: Exemple de table de hachage extensible deux entres ( gauche) ; Exemple de table de hachage
extensible aprs doublement du rpertoire ( droite).
Si les lms Greystocke (valeur 10111001) et Shinning (valeur 11010011) sont alors insrs , il y a
dbordement du troisime bloc, qui doit alors tre scind en deux. Lun des nouveaux blocs sera associ
la valeur 10, avec les lms Brazil et Greystocke, lautre sera associ avec la valeur 11, avec les lms
Twin Peaks et Shinning (voir gure 5.11).
Fig. 5.11: tape nale du hachage extensible.
3.3 Larbre-B
Un arbre-B est un arbre tri et quilibr (B pour Balanced tree).
Arbre-B dordre m :
Toutes les feuilles sont au mme niveau (donc tous les chemins de la racine aux nuds feuilles ont la
mme longueur).
98 3 Structures de donnes pour optimiser les accs
Un nud non feuille ou interne a un nombre de ls [m+ 1, 2m+ 1].
Le nud racine a un nombre de ls [0, 2m+ 1].
Fig. 5.12: Un arbre B dordre 2.
la dirence dun arbre-B, un arbre-B+ stocke les valeurs (les cls) uniquement dans les feuilles.
Fig. 5.13: Arbre-B+ pour le chier des lms avec un index unique sur le titres.
Fig. 5.14: Arbre-B+ pour le chier des lms avec un index unique sur lanne.
3.3.1 Structure dun arbre-B+
Dans un arbre-B+, les nuds feuille contiennent chacun deux champs :
1. Le premier champ est du mme type de donnes que le champ du chier de donnes qui sert de
champ dindexation ;
Chapitre 5 Ralisation physique des bases de donnes 99
2. Le second champ est soit un pointeur denregistrement si le champ de recherche est une cl (index
dense), soit un pointeur de bloc (index non dense).
Les nuds feuille dun arbre-B+ sont habituellement chans entre eux de manire orir un accs
ordonn au champ de recherche des enregistrements. Ces nuds feuilles sont donc quivalents au premier
niveau dun index multi-niveaux.
Les nuds internes correspondent aux autres niveaux dun index multi-niveaux. Leur structure est la
suivante :
1.
3.3.2 Recherches avec un arbre B+
Lors dune requte spciant une valeur K
r
du champ de recherche, il y a comparaison de cette valeur
avec les valeurs de comparaison K
i
du nud racine, puis rcursivement sur chacun des noeuds racine
des sous-arbres rencontrs, jusqu ce que le nud soit un nud feuille. chaque fois, il y a recherche
(ventuellement par dichotomie) du pointeur p
i
tel que : K
i1
< K
r
K
i
, et suivi de ce pointeur. (Voir
gure 5.15).
Fig. 5.15: Recherche dun lment, ici 43, dans un arbre B+.
3.3.3 Mise jour dun arbre B+
Algorithme dinsertion dans un arbre B+
1. Trouvez la feuille o lon doit insrer la nouvelle valeur en suivant la rgle de <= gauche (ou >=
droite).
2. Insrer dans la feuille en ordre de tri.
3. Si la feuille est pleine, alors il y a dbordement ( Overow ), Il faut crer un nouveau nud :
a) Insrer les j = (p
leaf
+ 1)/2| premires entres dans le nud original et les autres entres
dans le nouveau nud.
b) La jime valeur (+1 pour la rgle du >= droite) de cl est rplique dans le parent et un
nouveau pointeur au nouveau nud est aussi ajout au parent.
4. Si il y a dbordement dans le parent, Il faut crer un nouveau nud :
a) Les entres dans le nud interne jusqu P
j
restent en place. P
j
est le jime pointeur aprs
insertion de la nouvelle valeur et pointeur, o j = (p + 1)/2|.
b) La jime valeur (+1 pour la rgle du >= droite) de cl est dplace, et non pas rplique,
dans le parent.
c) Le nouveau nud va contenir les entres partir de P
j
+ 1 jusqu la n des entres.
d) Les division peuvent se propager jusqu crer une nouvelle racine et par consquent un nouveau
niveau pour larbre B+.
Algorithme de suppression dans un arbre B+
1. Lorsquune entre est eace, elle est dabord retire de son nud terminal (sa feuille).
2. Si cette valeur est aussi dans un nud interne, elle doit aussi y tre retire. La valeur sa gauche
( sa droite pour la rgle du >= droite) dans le nud terminal la remplace dans le nud interne.
100 3 Structures de donnes pour optimiser les accs
5
Insertion dans un arbre-B+
! Ordre
I
= 2
40 ...
Bloc 0
20 ... 40 ...
Bloc 0
20 ... 40 ... 60 ...
Bloc 0
6
Dbordement et division
! Insertion de 30
! Dbordement et la division du bloc 0
! 40 est promue
! Nouvelle racine
20 ... 40 ... 60 ...
Bloc 0
20 ... 30 ...
Bloc 0
40 ... 60 ...
Bloc 1
40
Bloc 2
7
Insertion de 25
20 ... 30 ...
Bloc 0
40 ... 60 ...
Bloc 1
40
Bloc 2
40
Bloc 2
20
Bloc 0
25 30 40
Bloc 1
60
8
Insertion de 10
40
Bloc 2
20
Bloc 0
25 30 40
Bloc 1
60
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
60
! Dbordement et la division du bloc 0
! 25 est promue
Fig. 5.16: Squence dinsertions dans un arbre B+.
3. Leacement peut causer une insusance de valeur dans le nud terminal. Dans ce cas, il faut faire
une redistribution des valeurs avec les feuilles voisines an que toutes les feuilles aient le nombre
minimum de valeur requis.
4. Si la redistribution est impossible, il faut fusionner des feuilles.
5. Lorsque des feuilles sont fusionnes, les insusances de valeur peuvent se propager dans les nuds
internes puisque moins de pointeurs sont requis. Il faut alors comprimer les nuds internes en
suivant les rgles de base.
6. Notez que la propagation peut entraner llimination dun niveau.
3.4 Autres mthodes dindexation
3.4.1 Les index bitmap
Dans un index bitmap, on construit un tableau de bits correspondant un attribut avec autant de colonnes
que de valeurs possibles de cet attribut (il est prfrable ce que ce nombre soit rduit), et autant de lignes
que de tuples dans la table indexe. Un bit de ce tableau sera 1 si la valeur correspondante de lattribut
fait partie du tuple dsign.
Ainsi, supposons que lon considre lattribut genre dans la table des lms (voir table 5.1) :
Lindex bitmap correspondant est donn dans le tableau 5.2. Il ne peut y avoir quun seul 1 par lm (et
donc ici par colonne) puisquune seule valeur est possible pour chaque attribut pour un tuple.
En gnral, un index bitmap est de trs petite taille. De plus, certaines requtes peuvent tre excutes
trs ecacement, parfois sans mme recourir la table. Ainsi, par exemple, la rponse la requte
Combien de lms y a-t-il dont le genre est Drame ou Comdie ? peut tre calcule directement
partir de lindex bitmap, en comptant le nombre de bits 1 dans les colonnes (ici lignes) correspondant
aux valeurs considres de lattribut.
Chapitre 5 Ralisation physique des bases de donnes 101
9
Insertion de 70
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
60
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
60 70
10
Insertion de 50
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
60 70
10
Bloc 0
20
25 40 60
Bloc 2
25
Bloc 3
30 40
Bloc 1
50 60
Bloc 4
70
! Dbordement et la division du bloc 1
! 60 est promue
11
Insertion de 53
10
Bloc 0
20
25 40 60
Bloc 2
25
Bloc 3
30 40
Bloc 1
50 60
Bloc 4
70
10
Bloc 0
20
25 40 60
Bloc 2
25
Bloc 3
30 40
Bloc 1
50 53 60
Bloc 4
70
12
Insertion de 45
10
Bloc 0
20
25 40 60
Bloc 2
25
Bloc 3
30 40
Bloc 1
50 53 60
Bloc 4
70
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
45 60
Bloc 4
70 50
Bloc 5
53
60
Bloc 6
50
Bloc 7
! Division du bloc 1
! 50 est promue
! Division de la racine
Fig. 5.17: Squence dinsertions dans un arbre B+ (suite).
SELECT COUNT(*)
FROM Film
WHERE genre IN (Comdie, Drame) ;
3.4.2 Structures de donnes multidimensionnelles
3.5 Bilan
3.6 Comparaison
Les arbre B orent des recherches rapide en fonction dune valeur de la cl ; utiles pour les colonnes
ayant un trs grand nombre de valeurs direntes ; mise jour ralentie
Le hachage permet daccder un tuple en une seule E/S
Les index bitmap sont utiles pour des colonnes comptant peu de valeurs distinctes
3.7 Quelques rgles
Ne pas crer des index pour des tables de moins de 200-300 lignes (laccs squentiel est plus rapide)
Ne pas crer dindex sur une colonne qui ne possde que quelques valeurs direntes (utiliser ventuel-
lement bitmap)
Indexer les colonnes qui interviennent souvent dans les clauses WHERE et ORDER BY
Indexer les colonnes de jointure
3.8 Indexation dans Oracle
3.9 Index en SQL
Indexation implicite : par dfaut, un arbre B+ est cr sur la cl primaire de chaque table
102 3 Structures de donnes pour optimiser les accs
13
Suppression dans un arbre-B+
! Cas simple
! minimum prserv
! pas la premire
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
60 70
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
60
14
Premire cl du bloc et pas la premire
feuille
! Remplacer dans le parent (si pas an )
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
60 70
10
Bloc 0
20
25 60
Bloc 2
25
Bloc 3
30 60
Bloc 1
70
15
Premire cl du bloc et pas la premire
feuille
! Remonter tant que l'enfant est l an
10
Bloc 0
20
25 40 45
Bloc 2
25
Bloc 3
30 40
Bloc 1
43 44 60
Bloc 4
70 50
Bloc 5
53 55
60
Bloc 6
50
Bloc 7
45 48
Bloc 8
10
Bloc 0
20
25 40 45
Bloc 2
25
Bloc 3
30 40
Bloc 1
43 44 60
Bloc 4
70 53
Bloc 5
55
60
Bloc 6
53
Bloc 7
45 48
Bloc 8
16
Violation du minimum :
redistribution si possible
! Ajuster sparateur
40
Bloc 2
20
Bloc 0
25 30 40
Bloc 1
60
30
Bloc 2
20
Bloc 0
25 30
Bloc 1
60
Fig. 5.18: Squence de suppressions dans un arbre B+.
Indexation explicite : les recherches sur de critres qui ne font pas partie de la cl peuvent tre optimises
en crant un nouvel index
CREATE [UNIQUE] INDEX nom_index ON nom_table [(nom_colonne)[ASC|DESC], ... ] ;
UNIQUE : sert liminer les doublons / ASC : par dfaut
Ex : CREATE INDEX nom_et ON Etudiants(Nom, Moyenne DESC)
DROP INDEX nom_index
Oracle propose plusieurs techniques dindexation : arbre B, B+, tables de hachage, etc.
Le SGBD Oracle propose plusieurs techniques dindexation : arbre-B, arbre-B+, tables de hachage. Par
dfaut, la structure dindex est celle dun arbre-B+, stocke dans un segment dindex sparment de la
table indexer. Il est possible de demander explicitement quune table soit physiquement organise avec
un arbre-B (Index organized table) ou par une table de hachage (hash cluster).
3.9.1 Arbres B+
La principale structure dindexation utilise par Oracle est larbre B+. Par dfaut, un arbre B+ est
cr sur la cl primaire de chaque table. Cet arbre B+ est ensuite automatiquement maintenu lors des
insertions, suppressions et mises jour aectant la table.
On peut aussi optimiser des recherches sur des attributs non cl en crant un nouvel index avec la
commande CREATE INDEX. Par exemple, on peut crer un index sur les nom et prnom des artistes :
CREATE UNIQUE INDEX idxNomArtiste ON Artite (non, prenom)
Cette commande ne fait pas partie de la norme SQL ANSI, mais on la retrouve peu de chose prs dans
tous les SGBD relationnels. Notons que Oracle cre le mme index si on spcie une clause UNIQUE(nom,
prenom) dans une commande CREATE TABLE.
Chapitre 5 Ralisation physique des bases de donnes 103
17
Violation du minimum : fusion
Fusion des deux frres
10
Bloc 0
20
25 60
Bloc 2
25
Bloc 3
30 60
Bloc 1
70
10
Bloc 0
25 30
60
Bloc 2
60
Bloc 1
70
Violation de la
rgle du minimum
18
Cas de fusion de feuilles et de redistribution au niveau du parent
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
45 60
Bloc 4
70 50
Bloc 5
53
60
Bloc 6
50
Bloc 7
Violation de la
rgle du minimum
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
45 50
Bloc 5
60 70
60
Bloc 6
50
Bloc 7
Violation de la
rgle du minimum
Redistribution
Fusion des deux frres
19
Cas de fusion de feuilles et de redistribution au niveau du parent (suite)
10
Bloc 0
20
25 40
Bloc 2
25
Bloc 3
30 40
Bloc 1
45 50
Bloc 5
60 70
60
Bloc 6
50
Bloc 7
Violation de la
rgle du minimum
Redistribution
10
Bloc 0
20
25
Bloc 2
25
Bloc 3
30 40
Bloc 1
45 50
Bloc 5
60 70
50
Bloc 6
40
Bloc 7
20
Cas de fusion en cascade
Fusion des deux frres
10
Bloc 0
20
25
Bloc 2
25
Bloc 3
30 40
Bloc 1
45 50
Bloc 5
60 70
50
Bloc 6
40
Bloc 7
Violation de la
rgle du minimum
Fusion des deux frres
10
Bloc 0
25 30
25
Bloc 2
40
Bloc 1
45 50
Bloc 5
60 70
50
Bloc 6
40
Bloc 7
Violation de la
rgle du minimum
Fig. 5.19: Squence de suppressions dans un arbre B+ (2).
21
Cas de fusion en cascade (suite) : rduction de la hauteur
Fusion des deux frres
10
Bloc 0
25 30
25
Bloc 2
40
Bloc 1
45 50
Bloc 5
60 70
50
Bloc 6
40
Bloc 7
Violation de la
rgle du minimum
10
Bloc 0
25 30
40 50
Bloc 2
40
Bloc 1
45 50
Bloc 5
60 70
Fig. 5.20: Squence de suppressions dans un arbre B+ (3).
3.9.2 Tables de hachage
La cration dune table de hachage seectue en deux tapes. Ondnit dabord les paramtres de lespace
de hachage avec la commande CREATE CLUSTER, puis on indique ce cluster au moment de la cration de
la table. Voici un exemple pour la table Film :
CREATE CLUSTER HashFilms (id INTEGER)
SIZE 500
HASHKEYS 500 ;
CREATE TABLE Film (idFilm INTEGER, ...)
CLUSTER HachFilms (idFilm) ;
104 3 Structures de donnes pour optimiser les accs
Rang Titre h(titre)
1 Vertigo Suspense
2 Brazil Science-ction
3 Twin Peaks Fantastique
4 Underground Drame
5 Easy Rider Drame
6 Psychose Drame
7 Greystocke Aventures
8 Shinning Fantastique
9 Annie Hall Comdie
10 Jurassic Park Science-ction
11 Metropolis Science-ction
12 Manhattan Comdie
13 Reservoir dogs Policier
14 Impitoyable Western
15 Casablanca Drame
16 Smoke Comdie
Tab. 5.1: Table des lms qualis par genre.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Aventures 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0
Comdie 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1
Drame 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1 0
Fantastique 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0
Science-ction 0 2 0 0 0 0 0 0 0 1 1 0 0 0 0 0
Suspense 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Western 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
Tab. 5.2: Index bitmap sur les lms classs par genre.
La commande CREATE CLUSTER, combine avec la clause HASHKEYS, cr une table de hachage dnie par
les paramtres suivants :
1. la cl de hachage est spcie dans lexemple comme tant un id de type INTEGER ;
2. le nombre dentre dans la table est spci par HASHKEYS ;
3. la taille estime pour chaque entre est donne par SIZE.
Oracle utilise une fonction de hachage approprie pour chaque type dattribut (ou combinaison de types).
Il est cependant possible pour ladministrateur de fournir sa propore fonction, ses risques et prils.
Dans lexemple qui prcde, le paramtre SIZE est gal 500. Ladministrateur estime donc que la somme
des tailles des enregistrements qui seront associs une mme entre est denviron 500 octets. Pour une
taille de bloc de 4096 octets, Oracle aectera alors
4096
500
| = 4 entres de la table de hachage un mme
bloc. Cela tant, si une entre occupe elle seule tout le bloc, les autres seront insres dans un bloc de
dbordement.
Pour structurer une table en hachage, on laecte simplement un cluster existant :
CREATE TABLE Film (idFilm INTEGER, ...)
CLUSTER HachFilms (idFilm) ;
Contrairement larbre B+ qui se cre automatiquement et ne demande aucun paramtrage, lutilisation
des tables de hachage demande de bonnes comptences des administrateurs, et lestimation _dlicate_
des bons paramtres. De plus, le hachage dans Oracle ntant pas extensible, cette technique est rserve
des situations particulires.
Chapitre 5 Ralisation physique des bases de donnes 105
3.10 Structures de donnes multidimensionnelles
4. valuation des requtes
4.1 Introduction loptimisation des performances
4.1.1 Oprations exprimes par SQL
4.1.2 Traitement dune requte
4.1.3 Mesure de lecacit des oprations
4.2 Algorithmes de base
4.2.1 Recherche dans un chier (slection)
4.2.2 Quand doit-on utiliser un index ?
4.2.3 Le tri externe
4.3 Algorithmes de jointure
4.3.1 Jointures par boucles imbriques
4.3.2 Jointure par tri-fusion
106 5 Vision globale sur lexcution dune requte SQL
4.3.3 Jointure par hachage
4.3.4 Jointure avec index
4.3.5 Jointure avec deux index
4.4 Compilation dune requte et optimisation
4.4.1 Dcomposition en bloc
4.4.2 Traduction et r-criture
4.4.3 Modles de cot
4.4.4 Pipelinage ou matrialisation des rsultats intermdiaires
4.5 Oracle : optimisation et valuation des requtes
4.5.1 Loptimisateur dOracle
4.5.2 Plans dexcution Oracle
5. Vision globale sur lexcution dune requte SQL
6. Optimisation de laccs une table
Chapitre 6
Perspectives des SGBD
Sommaire
1 Nouveaux modles de donnes pour nouvelles applications . . . . . . . . . 107
2 Bases de donnes rparties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.2 Fragmentation dune BD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.3 Les problmes spciques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.4 Transaction rpartie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3 Bases de donnes dductives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4 Entrepts de donnes et fouille de donnes . . . . . . . . . . . . . . . . . . . 109
4.1 Perspectives historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
1. Nouveaux modles de donnes pour nouvelles applications
La technologie des bases de donnes relationnelles domine largement le march actuellement. Cepen-
dant, de nouveaux besoins avec llargissement des domaines dapplication rvle les limites du modle
relationnel classique et des systmes de bases de donnes relationnelles.
Intgration dinformation provenant de la Toile
Nombreuses sources de donnes
Htrognit des sources et des formats de donnes (HTML, XHTML, PDF, ...)
2. Bases de donnes rparties
Les bases de donnes rparties ou distribues ( distributed databases ) permettent de raliser des
applications qui ncessitent le stockage, la maintenance et le traitement des donnes en plusieurs endroits
dirents. Une base de donnes est dcentralise ou rpartie lorsquelle est modlise par un seul schma
logique de base de donnes, mais implmente dans plusieurs fragments de tables physiques sur des sites
108 2 Bases de donnes rparties
gographiquement disperss et relis par un rseau. Lutilisateur dune base de donnes rpartie se focalise
sur sa vue logique des donnes et na pas besoin de se proccuper des fragments physiques. Cest le SGBD
qui se charge dexcuter les oprations, soit localement, soit en les distribuant sur plusieurs ordinateurs
en cas de besoin.
2.1 Motivations
Limiter le transfert dinformation entre sites
Meilleure rpartie de charge
Augmenter la abilit (grce la duplication des informations)
Rsultat dune fusion de systmes dinformation initialement spars.
Exemples.
2.2 Fragmentation dune BD
Fragmentation horizontale
Fragments dnis par slection. Reconstruction par union des fragments. (Voir gure 6.1).
Pertinente si des sous-tables sont spciques de sites spars (e.g. les employs dun site de production).
Fig. 6.1: Fragmentation horizontale.
Fragmentation verticale
Fragments dnis par projection. Reconstruction par jointure. (Voir gure 6.2).
Pertinente si forte anit des attributs.
Il faut alors penser conserver un identicateur de tuple pour chaque vue.
Fragmentation hybride
On parle de fragmentation disjointe si il ny a pas de duplication des informations, et de fragmentation
non disjointe sinon.
2.3 Les problmes spciques
Cot des communications
Cohrence des donnes
Contrle de concurrence
Reprise aprs panne
Chapitre 6 Perspectives des SGBD 109
Fig. 6.2: Fragmentation verticale.
Optimisation des requtes
Rpartition des charges.
2.4 Transaction rpartie
2.4.1 Transaction en deux phases
2.4.2 Traitement optimal des requtes rparties
3. Bases de donnes dductives
4. Entrepts de donnes et fouille de donnes
4.1 Perspectives historiques
110 4 Entrepts de donnes et fouille de donnes
Bibliographie g en erale
112
Bibliographie
[EN00] R. Elmasri and S. Navathe. Fundamentals of dabase systems. Addison-Wesley, 2000.
114 Index
Index
assertionnel (langage), 15
atomicit, 53
Complte, 19
Droits
gestion, 69
estampillage, 61
index
arbre-B+, 9497
bitmap, 9798
recouvrabilit, 5657
srialisabilit, 5152
transactions, 5253

You might also like