Cours de Bases de Données

Cours de bases de donnes
Philippe Rigaux 12 janvier 2004
TABLE DES MATIRES
Table des matires

0.1 0.2 Donnes, Bases de donnes et SGBD . . . . Que doit-on savoir pour utiliser un SGBD ? 0.2.1 Dnition du schma de donnes . 0.2.2 Les oprations sur les donnes . . . 0.2.3 Optimisation . . . . . . . . . . . . 0.2.4 Concurrence daccs . . . . . . . . Le plan du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9 9 10 10 11 11
0.3
I Modles et langages
1 Le modle Entit/Association 1.1 Principes gnraux . . . . . . . . . . . . 1.1.1 Bons et mauvais schmas . . . . . 1.1.2 La bonne mthode . . . . . . . . 1.2 Le modle E/A : Prsentation informelle . 1.3 Le modle . . . . . . . . . . . . . . . . . 1.3.1 Entits, attributs et identiants . . 1.3.2 Associations binaires . . . . . . . 1.3.3 Entits faibles . . . . . . . . . . . 1.3.4 Associations gnralises . . . . . 1.4 Avantage et inconvnients du modle E/A 1.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
15 15 16 16 18 19 19 21 24 26 27 29 33 33 35 35 40 41 42 43 44 45 48 49 51 52 53 53 54 55
2 Le modle relationnel 2.1 Dnition dun schma relationnel . . . . . . . . 2.2 Passage dun schma E/A un schma relationnel 2.2.1 Rgles gnrales . . . . . . . . . . . . . 2.2.2 Retour sur le choix des identiants . . . . 2.2.3 Dnormalisation du modle logique . . . 2.3 Le langage de dnition de donnes SQL2 . . . . 2.3.1 Types SQL . . . . . . . . . . . . . . . . 2.3.2 Cration des tables . . . . . . . . . . . . 2.3.3 Contraintes . . . . . . . . . . . . . . . . 2.3.4 Modication du schma . . . . . . . . . 2.4 Exercices . . . . . . . . . . . . . . . . . . . . . 3 Lalgbre relationnelle 3.1 Les oprateurs de lalgbre relationnelle . . . . . . . . . 3.1.1 La slection, 3.1.2 La projection, . . . . . . . . . 3.1.3 Le produit cartsien, . . . . . 3.1.4 Lunion, . . . . . . . . . . .

. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Philippe Rigaux (rigaux@lri.fr), Cours de bases de donnes, 2004
TABLE DES MATIRES

3.1.5 La diffrence, . . . . . . . . . . . . . . . . . 3.1.6 Jointure, Expression de requtes avec lalgbre 3.2.1 Slection gnralise . . . . . 3.2.2 Requtes conjonctives . . . . 3.2.3 Requtes avec et . . . . . Exercices . . . . . . . . . . . . . . .

4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 56 57 57 58 59 60 63 64 64 66 67 68 68 69 70 70 72 72 72 73 74 74 74 74 75 75 77 78 78 78 79 81 81 82 83 83 83 84 87 87 87 90 92 93 93 94 96
3.2
3.3
4 Le langage SQL 4.1 Requtes simples SQL . . . . . . . . . . . 4.1.1 Slections simples . . . . . . . . . 4.1.2 La clause WHERE . . . . . . . . . . 4.1.3 Valeurs nulles . . . . . . . . . . . . 4.2 Requtes sur plusieurs tables . . . . . . . . 4.2.1 Jointures . . . . . . . . . . . . . . 4.2.2 Union, intersection et diffrence . . 4.3 Requtes imbriques . . . . . . . . . . . . 4.3.1 Conditions portant sur des relations 4.3.2 Sous-requtes correlles . . . . . . 4.4 Agrgration . . . . . . . . . . . . . . . . . 4.4.1 Fonctions dagrgation . . . . . . . 4.4.2 La clause GROUP BY . . . . . . . 4.4.3 La clause HAVING . . . . . . . . . 4.5 Mises--jour . . . . . . . . . . . . . . . . . 4.5.1 Insertion . . . . . . . . . . . . . . 4.5.2 Destruction . . . . . . . . . . . . . 4.5.3 Modication . . . . . . . . . . . . 4.6 Exercices . . . . . . . . . . . . . . . . . . 5 Schmas relationnels 5.1 Schmas . . . . . . . . . . . . . . . . . . . 5.1.1 Dnition dun schma . . . . . . . 5.1.2 Utilisateurs . . . . . . . . . . . . . 5.2 Contraintes et assertions . . . . . . . . . . 5.3 Vues . . . . . . . . . . . . . . . . . . . . . 5.3.1 Cration et interrogation dune vue 5.3.2 Mise jour dune vue . . . . . . . 5.4 Triggers . . . . . . . . . . . . . . . . . . . 5.4.1 Principes des triggers . . . . . . . . 5.4.2 Syntaxe . . . . . . . . . . . . . . . 5.5 Exercices . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
6 Programmation avec SQL 6.1 Interfaage avec le langage C . . . . . . . . . 6.1.1 Un exemple complet . . . . . . . . . 6.1.2 Dveloppement en C/SQL . . . . . . 6.1.3 Autres commandes SQL . . . . . . . 6.2 Linterface Java/JDBC . . . . . . . . . . . . 6.2.1 Principes de JDBC . . . . . . . . . . 6.2.2 Le plus simple des programmes JDBC 6.2.3 Exemple dune applet avec JDBC . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
TABLE DES MATIRES
II Aspects systmes
7 Techniques de stockage 7.1 Stockage de donnes . . . . . . . . 7.1.1 Supports . . . . . . . . . . 7.1.2 Fonctionnement dun disque 7.1.3 Optimisations . . . . . . . . 7.1.4 Technologie RAID . . . . . 7.2 Fichiers . . . . . . . . . . . . . . . 7.2.1 Enregistrements . . . . . . . 7.2.2 Blocs . . . . . . . . . . . . 7.2.3 Organisation dun chier . . 7.3 Oracle . . . . . . . . . . . . . . . . 7.3.1 Fichiers et blocs . . . . . . 7.3.2 Les tablespaces . . . . . . . 7.3.3 Cration des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
103 104 104 105 107 110 112 113 115 118 120 121 123 127 129 130 131 133 134 135 135 137 139 140 143 145 146 146 147 147 147 148 149 150 150 150 151 152 153 153 155 158 161 162 164 166 168 169 170 170
8 Indexation 8.1 Indexation de chiers . . . . . . . . . 8.1.1 Index non-dense . . . . . . . 8.1.2 Index dense . . . . . . . . . . 8.1.3 Index multi-niveaux . . . . . 8.2 Larbre-B . . . . . . . . . . . . . . . 8.2.1 Prsentation intuitive . . . . . 8.2.2 Recherches avec un arbre-B+ 8.3 Hachage . . . . . . . . . . . . . . . . 8.3.1 Principes de base . . . . . . . 8.3.2 Hachage extensible . . . . . . 8.4 Les index bitmap . . . . . . . . . . . 8.5 Indexation dans Oracle . . . . . . . . 8.5.1 Arbres B+ . . . . . . . . . . . 8.5.2 Arbres B . . . . . . . . . . . 8.5.3 Indexation de documents . . . 8.5.4 Tables de hachage . . . . . . 8.5.5 Index bitmap . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
9 valuation de requtes 9.1 Introduction loptimisation des performances 9.1.1 Oprations exprimes par SQL . . . . . 9.1.2 Traitement dune requte . . . . . . . . 9.1.3 Mesure de lefcacit des oprations . . 9.1.4 Organisation du chapitre . . . . . . . . 9.2 Algorithmes de base . . . . . . . . . . . . . . 9.2.1 Recherche dans un chier (slection) . 9.2.2 Quand doit-on utiliser un index ? . . . . 9.2.3 Le tri externe . . . . . . . . . . . . . . 9.3 Algorithmes de jointure . . . . . . . . . . . . . 9.3.1 Jointure par boucles imbriques . . . . 9.3.2 Jointure par tri-fusion . . . . . . . . . . 9.3.3 Jointure par hachage . . . . . . . . . . 9.3.4 Jointure avec un index . . . . . . . . . 9.3.5 Jointure avec deux index . . . . . . . . 9.4 Compilation dune requte et optimisation . . . 9.4.1 Dcomposition en bloc . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
TABLE DES MATIRES

9.4.2 Traduction et rcriture . . . . . . . . . . . . . . . . . . 9.4.3 Plans dexcution . . . . . . . . . . . . . . . . . . . . . 9.4.4 Modles de cot . . . . . . . . . . . . . . . . . . . . . 9.4.5 Pipelinage ou matrialisation des rsultats intermdiaires Oracle, optimisation et valuation des requtes . . . . . . . . . . 9.5.1 Loptimiseur dORACLE . . . . . . . . . . . . . . . . . 9.5.2 Plans dexcution ORACLE . . . . . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.1 Oprateurs daccs aux donnes . . . . . . . . . . . . . 9.6.2 Algorithmes de jointure . . . . . . . . . . . . . . . . . 9.6.3 Plans dexcution . . . . . . . . . . . . . . . . . . . . . 9.6.4 Plans dexcution ORACLE . . . . . . . . . . . . . . . 9.6.5 Utilisation de EXPLAIN et de TKPROF . . . . . . . . . 9.6.6 Exercices dapplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 172 174 178 179 181 181 184 187 188 189 189 190 193 195 197 197 198 199 200 201 202 204 204 205 209 210 211 212 212 212 213 213 213 213 214 215 215 216 216
9.5
9.6
10 Introduction la concurrence daccs 10.1 Prliminaires . . . . . . . . . . . . . . . . . . 10.1.1 Excutions concurrentes : srialisabilit 10.1.2 Transaction . . . . . . . . . . . . . . . 10.1.3 Excutions concurrentes : recouvrabilit 10.2 Contrle de concurrence . . . . . . . . . . . . 10.2.1 Verrouillage deux phases . . . . . . . 10.2.2 Contrle par estampillage . . . . . . . 10.3 Gestion des transactions en SQL . . . . . . . . 10.4 Exercices . . . . . . . . . . . . . . . . . . . .
A Travaux pratiques A.1 Interrogation avec SQL . . . . . . . . . . . . . . . . . A.1.1 Slections simples . . . . . . . . . . . . . . . A.1.2 Jointures . . . . . . . . . . . . . . . . . . . . A.1.3 Requtes imbriques . . . . . . . . . . . . . . A.1.4 Ngation . . . . . . . . . . . . . . . . . . . . A.1.5 Fonctions de groupe . . . . . . . . . . . . . . A.2 Cration dun schma relationnel . . . . . . . . . . . . A.2.1 Cration des tables . . . . . . . . . . . . . . . A.2.2 Insertion de donnes . . . . . . . . . . . . . . A.2.3 Vues . . . . . . . . . . . . . . . . . . . . . . . A.2.4 Triggers . . . . . . . . . . . . . . . . . . . . . A.3 Concurrence daccs . . . . . . . . . . . . . . . . . . A.4 Progammation dune application avec base de donnes A.5 Projet . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
TABLE DES MATIRES
Introduction
Ce polycopi sadresse aux tudiants en premier cyle (IUT) ou second cycle universitaire (Licence, Master) et formations apparentes (cycles A et B du Cnam par exemple). Il propose un ensemble de chapitres consacrs aux principes et la mise en uvre de bases de donnes relationnelles, ainsi qu la pratique des Systmes de Gestion de Bases de Donnes (SGBD). Le polycopi est divis en deux parties dont voici, brivement, le contenu : 1. Modles et langages. Cette partie couvre tout dabord la conception et la dnition dun schma relationnel correct et complet, comprenant des tables, des contraintes, des vues, etc. Elle dcrit ensuite lalgbre relationnelle et SQL, ainsi que lintgration de SQL avec un langage de programmation comme le C. 2. Aspects systmes. Cette partie prsente les techniques internes utilises par les SGBD relationnels pour stocker efcacement les donnes et valuer des requtes. Elle couvre la reprsentation physique, lindexation, loptimisation et comprend galement une introduction aux problmes de concurrence daccs, dont la connaissance est ncessaire aux dveloppeurs dapplications bases sur des SGBD. La premire partie est accessible aux tudiants suivant un cours dintroduction aux bases de donnes et ne demande que peu de pr-requis. La second partie est plus avance et ncessite de bonnes bases en structures de donnes et algorithmique. Jajoute quune annexe prsente des travaux pratiques avec le SGBD ORACLE permettant de mettre en oeuvre les techniques tudies en cours. Le polycopi nest quune partie dun ensemble de matriels pdagogiques (exercices, diaporamas, exemples de code, chantillons de bases de donnes) accessibles en ligne lURL suivante : http://www.lri.fr/ rigaux Ce document est un support de cours : il ne prtend certainement pas tre exhaustif ni traiter en dtail tous les sujets abords. Jeffectue rgulirement des mises jour et des ajouts mais je ne prtends pas ( lheure actuelle en tout cas) proposer un support denseignement distance ou dauto-formation.
Bibliographie gnrale
Il existe de trs nombreux ouvrages sur les bases et donnes Pour ceux qui veulent en savoir plus, il existe une riche bibliographie dont voici quelques lments recommandables : 1. [Ullman et Widom, 1999] 2. [Garcia-Molina et al., 2000] Le premier chapitre est une (rapide) prsentation de tous les thmes prsents en dtails dans ce cours. On peut le lire comme une mise en perspective gnrale de lensemble du document. Ce chapitre prsente un panorama gnral de la problmatique des bases de donnes.
0.1 Donnes, Bases de donnes et SGBD

La premire chose faire est dtablir quelques points de terminologie. Quest-ce quune donne ? Cest une information quelconque comme, par exemple : voici une personne, elle sappelle Jean. Cest aussi une relation entre
0.1. DONNES, BASES DE DONNES ET SGBD
des informations : Jean 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 une caractristique essentielle : on souhaite les mmoriser de manire permanente. Do la dnition : Dnition 1 Une Base de donnes est un gros ensemble dinformations structures mmorises sur un support permanent. On peut remarquer quune organisation consistant en un (ou plusieurs) chier(s) stocks sur mmoire secondaire est conforme cette dnition. Un ensemble de chiers ne prsentant quune complexit assez faible, il ny aurait pas l matire longue dissertation. Malheureusement lutilisation directe de chiers soulve de trs gros problmes : 1. Lourdeur daccs aux donnes. En pratique, pour chaque accs, mme le plus simples, il faudrait crire un programme. 2. Manque de scurit. Si tout programmeur peut accder directement aux chiers, il est impossible de garantir la scurit et lintgrit des donnes. 3. Pas de contrle de concurrence. Dans un environnement o plusieurs utilisateurs accdent aux mme chiers, des problmes de concurrence daccs se posent. Do le 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 diffrents types dinterface ncessaires laccs aux donnes. Ce logiciel (le SGBD) est trs complexe et fournit le sujet principal de ce cours. En particulier, une des tches principales du SGBD est de masquer lutilisateur les dtails complexes et fastidieux lis la gestion de chiers. Do la dnition. Dnition 2 Un Systme de Gestion de Bases de Donnes (SGBD) est un logiciel de haut niveau qui permet de manipuler les informations stockes dans une base de donnes. La complexit dun SGBD est essentiellement issue de la diversit des techniques mises en oeuvre, de la multiplicit des composants intervenant dans son architecture, et des diffrents types dutilisateurs (administrateurs, programmeurs, non informaticiens, ...) qui sont confronts, diffrents niveaux, au systme. Voici quelques exemples illustrant tous les cas de gure quil faudrait envisager dans un cours exhaustif : Les modles de donnes : entit-relation, rseau, hirarchique, relationnel, orient-objet, modles smantiques. Les langages de requtes : fondements thoriques (logiques du premier ordre, du point xe, algbres diverses) et les langages comme SQL, SQL3, Datalog, OQL, etc. Les techniques de stockage : sur disque (optique), sur bande. Lorganisation des chiers : index, arbre-B, hachage, ... Larchitecture : centralis, distribu, sur dautres bases accessibles par rseau. Les techniques dvaluation et doptimisation de requtes. La concurrence daccs et les techniques de reprise sur pane. Pour mettre un peu dordre dans tout cela, on peut se raccrocher une architecture standard conforme la plus grande partie des SGBD existant, et offrant lavantage de bien illustrer les principales caractristiques dun SGBD. Cette architecture distingue trois niveaux correspondant dune part trois reprsentations quivalentes de linformation, dautre part aux champs dinterventions respectifs des principaux acteurs. Pour ces derniers, nous utiliserons la terminologie suivante : Utilisateur naf : du non spcialiste des SGBD au non informaticien. Concepteur et programmeur dapplication : partir des besoins des diffrents utilisateurs, crit lapplication pour des utilisateurs nafs.
TABLE DES MATIRES
Utilisateur expert : informaticien connaissant le fonctionnement interne dun SGBD et charg dadministrer la base. Chaque niveau du SGBD remplit (ralise) un certain nombre de fonctions : Niveau physiques : 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). Niveau logique : Dnition de la structure de donnes : Langage de Description de Donnes (LDD) ; Consultation et Mise Jour des donnes : Langages de Requtes (LR) et Langage de Manipulation de Donnes (LMD) ; Gestion de la condentialit (scurit) ; Maintien de lintgrit ; Niveau externe : Vues ; Environnement de programmation (intgration avec un langage de programmation) ; Interfaces conviviales et Langages de 4e 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 (annes) et ables (protection sur pannes), partageables entre plusieurs utilisateurs et/ou programmes et manipules indpendamment de leur reprsentation physique.
0.2 Que doit-on savoir pour utiliser un SGBD ?

Lutilisation dun SGBD suppose de comprendre (et donc de savoir utiliser) les fonctionnalits suivantes : 1. Dnition du schma de donnes en utilisant les modles de donnes du SGBD. 2. Oprations sur les donnes : recherche, mises--jour, etc. 3. Partager les donnes entre plusieurs utilisateurs. (Mcanisme de transaction). 4. Optimiser les performances, par le rglage de lorganisation physique des donnes. Cet aspect relve plutt de ladministration et ne sera voqu que dans lintroduction. Reprenons dans lordre ces diffrents points.
0.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 oprations). En fait, dans un SGBD, il existe plusieurs modles plus ou moins abstraits des mmes objets, e.g. : Le modle conceptuel : la description du systme dinformation Le modle logique : interface avec le SGBD Le modle physique : chiers. Ces diffrents modles correspondent aux niveaux dans larchitecture dun SGBD. Prenons lexemple du modle conceptuel le plus courant : le modle Entit/Association. Cest essentiellement une description trs abstraite qui prsente les avantages suivants : lanalyse du monde rel la conception du systme dinformation la communication entre diffrents acteurs de lentreprise
0.2. QUE DOIT-ON SAVOIR POUR UTILISER UN SGBD ?
10
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 des 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 : oute les structures et les oprations, un modle logique doit permettre 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 (plus ou moins consciemment) 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 appropries appliques la reprsentation physique. Cette aproche offre de trs grands avantages quil est important de souligner. Tout dabord elle ouvre lutilisation des SGBD de 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 : lindpendance 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.
0.2.2 Les oprations sur les donnes

Il existe 4 oprations classiques (ou requtes) : 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 facilement : lidal serait de pouvoir utiliser le langage naturel, mais celui-ci prsente trop dambiguits. Ensuite le langage ne devrait pas demander dexpertise technique (syntaxe complique, structures 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.
0.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.
TABLE DES MATIRES
11
0.2.4 Concurrence daccs

Plusieurs utilisateurs doivent pouvoir accder en mme temps aux mmes donnes. Le SGBD doit savoir : Grer les conits si les deux font des mises--jour. Offrir un mcanisme de retour en arrire si on dcide dannuler des modications en cours. Donner une image cohrente des donnes si lun fait des requtes et lautre des mises--jour. Le but : viter les blocages, tout en empchant des modications anarchiques.
0.3 Le plan du cours

Le cours comprend trois parties consacres successivement la conception dune base de donnes relationnelles, aux langages de requtes relationnels, enn la pratique dun SGBD relationnel. Conception dun schma relationnel Le cours prsente dabord la technique classique de conception laide du modle entit/association, suivie de la transcription du schma obtenu dans le modle relationnel. On obtient un moyen simple et courant de crer des schmas ayant de bonnes proprits. Les concepts de bon et de mauvais schmas sont ensuite revus plus formellement avec la thorie de la normalisation. Langages relationnels Les langages dinterrogation et de manipulation de donnes suivants sont prsents : lalgbre relationnelle qui fournit un petit ensemble doprateurs permettant dexprimer des requtes complexes et le langage SQL, norme SQL2. Pratique dun SGBD relationnel Cette partie reprend et tend les sujets prcdents et dveloppe leur mise en pratique dans lenvironnement dun SGBD relationnel. Elle comprend : 1. Une revue complte du langage de dnition de donnes SQL2 pour la cration de schmas relationnels, incluant lexpression de contraintes, les vues et les triggers. 2. Une introduction au dveloppement dapplications avec SQL. 3. Une introduction la concurrence daccs et ses implications pratiques. 4. Une srie de travaux pratiques et dexercices avec le SGBD Oracle.
0.3. LE PLAN DU COURS
12
13
Premire partie
Modles et langages
CHAPITRE 1. LE MODLE ENTIT/ASSOCIATION
15
Chapitre 1
Le modle Entit/Association
Sommaire
1.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 1.2 1.3 Bons et mauvais schmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La bonne mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16 16 18 19 19 21 24 26 27 29
Le modle E/A : Prsentation informelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 1.3.4 Entits, attributs et identiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Associations binaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entits faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Associations gnralises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 1.5
Avantage et inconvnients du modle E/A
Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 difcilement rcuprable par la suite. Le modle E/A a pour caractristiques dtre simple et sufsamment puissant pour reprsenter des structures relationnelles. Surtout, il repose sur une reprsentation graphique qui facilite considrablement sa comprhension. Le modle E/A souffre galement de nombreuses insufsances : la principale est de ne proposer que des structures. Il nexiste pas dopration permettant de manipuler les donnes, et pas (ou peu) de moyen dexprimer des contraintes. Un autre inconvnient du modle E/A est de mener certaines ambiguits pour des schmas complexes. 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. Dans tout ce chapitre nous prenons lexemple dune base de donnes dcrivant des lms, avec leur metteur en scne et leurs acteurs, ainsi que les cinmas o passent ces lms. Nous supposerons galement que cette base de donnes est accessible sur le Web et que des internautes peuvent noter les lms quils ont vus.
1.1 Principes gnraux

La mthode 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 relationnelle comme un simple chier texte, sans se soucier de lui donner une structure correcte.
1.1. PRINCIPES GNRAUX
16
1.1.1 Bons et mauvais schmas

Considrons une table FilmSimple stockant des lms avec quelques informations de base, dont le metteur en scne. Voici une reprsentation de cette table. titre Alien Vertigo Psychose Kagemusha Volte-face Pulp Fiction Titanic Sacrice anne 1979 1958 1960 1980 1997 1995 1997 1986 nomMES Scott Hitchcock Hitchcock Kurosawa Woo Tarantino Cameron Tarkovski prnomMES Ridley Alfred Alfred Akira John Quentin James Andrei anneNaiss 1943 1899 1899 1910 1946 1963 1954 1932
Mme pour une information aussi simple, il est facile dnumrer tout un ensemble de problmes potentiels. Tous ou presque dcoulent dun grave dfaut de la table ci-dessus : il est possible de reprsenter la mme information plusieurs fois. Anomalies lors dune insertion Rien nempche de reprsenter plusieurs fois le mme lm. Pire : il est possible dinsrer plusieurs fois le lm Vertigo en le dcrivant chaque fois de manire diffrente, par exemple en lui attribuant une fois comme ralisateur Alfred Hitchcock, puis une autre fois John Woo, etc. Une bonne question consiste dailleurs se demander ce qui distingue deux lms lun de lautre, et quel moment on peut dire que la mme information a t rpte. Peut-il y avoir deux lms diffrents avec le mme titre par exemple ? Si la rponse est non, alors on devrait pouvoir assurer quil ny a pas deux lignes dans la table avec la mme valeur pour lattribut titre. Si la rponse est oui, il reste dterminer quel est lensemble des attributs qui permet de caractriser de manire unique un lm. Anomalies lors dune modication La redondance dinformation entrane galement des anomalies de mise jour. Supposons que lon modie lanne de naissance de Hitchcock pour la ligne Vertigo et pas pour la ligne Psychose. On se retrouve alors avec des informations incohrentes. Les mmes questions que prcdemment se posent dailleurs. Jusqu quel point peut-on dire quil ny a quun seul ralisateur nomm Hitchcock, et quil ne doit donc y avoir quune seule anne de naissance pour un ralisateur de ce nom ? Anomalies lors dune destruction On ne peut pas supprimer un lm sans supprimer du mme coup son metteur en scne. Si on souhaite, par exemple, ne plus voir le lm Titanic gurer dans la base de donnes, on va effacer du mme coup les informations sur James Cameron.
1.1.2 La 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.
17
Commenons par les deux premires tapes. On va dabord distinguer la table des lms et la table des ralisateurs. Ensuite on dcide que deux lms ne peuvent avoir le mme titre, mais que deux ralisateurs peuvent avoir le mme nom. An davoir un moyen didentier les ralisateurs, on va leur attribuer un numro, dsign par id. On obtient le rsultat suivant, les identiants (ou cls) tant en gras. anne titre Alien 1979 Vertigo 1958 Psychose 1960 Kagemusha 1980 Volte-face 1997 Pulp Fiction 1995 Titanic 1997 Sacrice 1986 La table des lms
id 1 2 3 4 5 6 7
nomMES prnomMES Scott Ridley Hitchcock Alfred Kurosawa Akira Woo John Tarantino Quentin Cameron James Tarkovski Andrei La table des ralisateurs
anneNaiss 1943 1899 1910 1946 1963 1954 1932
Premier progrs : il ny a maintenant plus de redondance dans la base de donnes. Le ralisateur Hitchcock, par exemple, napparat plus quune seule fois, ce qui limine les anomalies de mise jour voques prcdemment. Il reste reprsenter le lien entre les lms et les metteurs en scne, sans introduire de redondance. Maintenant que nous avons dni les identiants, il existe un moyen simple pour indiquer quel est le metteur en scne qui a ralis un lm : associer lidentiant du metteur en scne au lm. On ajoute un attribut idMES dans la table Film, et on obtient la reprsentation suivante. anne idMES titre Alien 1979 1 Vertigo 1958 2 Psychose 1960 2 Kagemusha 1980 3 Volte-face 1997 4 Pulp Fiction 1995 5 Titanic 1997 6 Sacrice 1986 7 La table des lms
id 1 2 3 4 5 6 7
nomMES prnomMES Scott Ridley Hitchcock Alfred Kurosawa Akira Woo John Tarantino Quentin Cameron James Tarkovski Andrei La table des ralisateurs
anneNaiss 1943 1899 1910 1946 1963 1954 1932
Cette reprsentation est correcte. La redondance est rduite au minimum puisque seule la cl identiant un metteur en scne a t dplace dans une autre table (on parle de cl trangre). On peut vrier que toutes les anomalies que nous avons cites ont disparu. Anomalie dinsertion. Maintenant que lon sait quelles sont les caractristiques qui identient un lm, il est possible de dterminer au moment dune insertion si elle va introduire ou non une redondance. Si cest le cas on doit interdire cette insertion. Anomalie de mise jour. Il ny a plus de redondance, donc toute mise jour affecte lunique instance de la donne modier. Anomalie de destruction. On peut dtruire un lm sans affecter les informations sur le ralisateur. Ce gain dans la qualit du schma na pas pour contrepartie une perte dinformation. Il est en effet 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 offre une mthode simple pour arriver au rsultat ci-dessus, et ce mme dans des cas beaucoup plus complexes.
1.2. LE MODLE E/A : PRSENTATION INFORMELLE
18
1.2 Le modle E/A : Prsentation informelle

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. Par exemple, pour notre base de donnes Films, on na pas besoin de stocker dans la base de donnes lintgralit des informations relatives un internaute, ou un lm. Seules comptent celles qui sont importantes pour lapplication. Voici le schma dcrivant cete base de donnes Films (gure 1.1). Sans entrer dans les dtails pour linstant, on distingue 1. des entits, reprsentes par des rectangles, ici Film, Artiste, Internaute et Pays ; 2. des associations entre entits reprsentes par des liens entre ces rectangles. Ici on a reprsent par exemple le fait quun artiste joue dans des lms, quun internaute note des lms, etc. Chaque entit est caractrise par un ensemble dattributs, parmi lesquels un ou plusieurs forment lidentiant unique (en gras). Comme nous lavons expos prcdemment, il est essentiel de dire ce qui caractrise de manire unique une entit, de manire viter la redondance dinformation.
Artiste id nom prnom anneNaissance 0..* Joue Ralise 0..1 0..* Film id titre anne genre rsum * 1..1 * Donne une note * note Internaute email nom prnom motDePpasse anneNaissance
0..* rle
Pays code nom langue
F IG . 1.1 Le schma de la base de donnes Films
Les associations sont caractrises par des cardinalits. La notation 0..* sur le lien Ralise, du ct de lentit Film, signie quun artiste peut raliser plusieurs lms, ou aucun. La notation 0..1 du ct Artiste signie en revanche quun lm ne peut tre ralis que par au plus un artiste. En revanche dans lassociation Donne une note, un internaute peut noter plusieurs lms, et un lm peut tre not par plusieurs internautes, ce qui justie la prsence de 0..* aux deux extrmits de lassociation. Le choix des cardinalits est essentiel. Ce choix est aussi parfois discutable, et constitue donc laspect le plus dlicat de la modlisation. Reprenons lexemple de lassociation Ralise. En indiquant quun lm est ralis par un seul metteur en scne, on sinterdit les rares situations o un lm est ralis par plusieurs personnes. Il ne sera donc pas possible de reprsenter dans la base de donnes une telle situation. Tout est ici question de choix et de compromis : est-on prt en loccurrence accepter une structure plus complexe (avec 0..* de chaque ct) pour lassociation Ralise, pour prendre en compte un nombre minime de cas ? Les cardinalits sont notes par deux chiffres. Le chiffre de droite est la cardinalit maximale, qui vaut en gnral 1 ou *. Le chiffre de gauche est la cardinalit minimale. Par exemple la notation 0..1 entre Artiste et Film indique quon sautorise ne pas connatre le metteur en scne dun lm. Attention : cela ne signie pas que ce metteur en

19
scne nexiste pas. Une base de donnes, telle quelle est dcrite par un schma E/A, nest quune vision partielle de la ralit. On ne doit surtout pas rechercher une reprsentation exhaustive, mais sassurer de la prise en compte des besoins de lapplication. La notation 1..1 entre Film et Pays indique au contraire que lon doit toujours connatre le pays producteur dun lm. On devra donc interdire le stockage dans la base dun lm sans son pays. Les cardinalits minimales (galement appeles contraintes de participation ) sont moins importantes que les cardinalits maximales, car elles ont un impact moindre sur la structure de la base de donnes et peuvent plus facilement tre remises en cause aprs coup. Il faut bien tre conscient de plus quelles ne reprsentent quun choix de conception, souvent discutable. Dans la notation UML que nous prsentons ici, il existe des notations abrges qui donnent des valeurs implicites aux cardinalits minimales : 1. La notation * est quivalente 0..* ; 2. la notation 1 est quivalente 1..1 . Outre les proprits dj voques (simplicit, clart de lecture), videntes sur ce schma, on peut noter aussi que la modlisation conceptuelle est totalement indpendante de tout choix dimplantation. Le schma de la gure 1.1 ne spcie aucun systme en particulier. Il nest pas non plus question de type ou de structure de donnes, dalgorithme, de langage, etc. En principe, il sagit donc de la partie la plus stable dune application. Le fait de se dbarrasser ce stade de la plupart des considrations techniques permet de se concentrer sur lessentiel : que veut-on stocker dans la base ? Une des principales difcults dans le maniement des schmas E/A est que la qualit du rsultat ne peut svaluer que par rapport une demande qui est souvent oue et incomplte. Il est donc souvent difcile de valider (en fonction de quels critres ?) le rsultat. Peut-on afrmer par exemple que : 1. toutes les informations ncessaires sont reprsentes ; 2. quun lm ne sera jamais ralis par plus dun artiste ; 3. quil ny aura jamais deux lms avec le mme titre. Il faut faire des choix, en connaissance de cause, en sachant toutefois quil est toujours possible de faire voluer une base de donnes, quand cette volution nimplique pas de restructuration trop importante. Pour reprendre les exemples ci-dessus, il est facile dajouter des informations pour dcrire un lm ou un internaute ; il serait beaucoup plus difcile de modier la base pour quun lm passe de un, et un seul, ralisateur, plusieurs. Quant changer la cl de Film, cest une des volutions les plus complexes raliser. Les cardinalits et le choix des cls font vraiment partie des des aspects dcisifs des choix de conception.

1.3 Le modle
Le modle E/A, conu en 1976, est la base de la plupart des mthodes de conception. La syntaxe employe ici est celle de la mthode UML, reprise peu prs lidentique de celle de la mthode OMT. Il existe beaucoup dautres notations, dont celle de la mthode MERISE principalement utilise en France. Ces notations sont globalement quivalentes. Dans tous les cas la conception repose sur deux concepts complmentaires, entit et association.
1.3.1 Entits, attributs et identiants

Il est difcile de donner une dnition trs prcise des entits. Les points essentiels sont rsums ci-dessous. Dnition 3 (Entit) On dsigne par entit tout objet identiable et pertinent pour lapplication. Comme nous lavons vu prcdemment, la notion didentit est primordiale. Cest elle qui permet de distinguer les entits les unes des autres, et donc de dire quune information est redondante ou quelle ne lest pas. Il est indispensable de prvoir un moyen technique pour pouvoir effectuer cette distinction entre entits au niveau de la base de donnes : on parle didentiant ou de cl.
1.3. LE MODLE
20
La pertinence est galement essentielle : on ne doit prendre en compte que les informations ncessaires pour satisfaire les besoins. Par exemple : 1. le lm Impitoyable ; 2. lacteur Clint Eastwood ; sont des entits pour la base Films. La premire tape dune conception consiste identier les entits utiles. On peut souvent le faire en considrant quelques cas particuliers. La deuxime est de regrouper les entits en ensembles : en gnral on ne sintresse pas un individu particulier mais des groupes. Par exemple il est clair que les lms et les acteurs sont des ensembles distincts dentits. Quen est-il de lensemble des ralisateurs et de lensemble des acteurs ? Doit-on les distinguer ou les assembler ? Il est certainement prfrable de les assembler, puisque des acteurs peuvent aussi tre ralisateurs. Attributs Les entits sont caractrises par des proprits : le titre (du lm), le nom (de lacteur), sa date de naissance, ladresse, etc. Ces proprits sont dnotes attributs dans la terminologie du modle E/A. Le choix des attributs relve de la mme dmarche dabstraction qui a dict la slection des entits : il nest pas question de donner exhaustivement toutes les proprits dune entit. On ne garde que celles utiles pour lapplication. Un attribut est dsign par un nom et prend ses valeurs dans un domaine numrable comme les entiers, les chanes de caractres, les dates, etc. On peut considrer un nom datribut comme une fonction dnie sur un ensemble dentits et prenant ses valeurs dans un domaine . On note alors la valeur de lattribut pour une entit . Considrons par exemple un ensemble de lms et les attributs titre et anne. Si est le lm Impitoyable, tourn par Clint Eastwood en 1992, on aura : titre ( ) = Impitoyable ; anne ( ) = 1992 Il est trs important de noter que selon cette dnition un attribut prend une valeur et une seule. On dit que les attributs sont atomiques. Il sagit dune restriction importante puisquon ne sait pas, par exemple, dnir un attribut tlphones dune entit Personne, prenant pour valeur les numros de tlphone dune personne. Certaines mthodes admettent (plus ou moins clairement) lintroduction de constructions plus complexes : 1. les attributs multivalus sont constitus dun ensemble de valeurs prises dans un mme domaine ; une telle construction permet de rsoudre le problme des numros de tlphones multiples ; 2. les attributs composs sont constitus par agrgation dautres atributs ; un attribut adresse peut par exemple tre dcrit comme lagrgation dun code postal, dun numro de rue, dun nom de rue et dun nom de ville. Nous nous en tiendrons pour linstant aux attributs atomiques qui, au moins dans le contexte dune modlisation oriente vers un SGBD relationnel, sont sufsants. Types dentits Il est maintenant possible de dcrire un peu plus prcisment les entits par leur type. Dnition 4 (Type dentit) Le type dune entit est compos des lments suivants : 1. son nom ; 2. la liste de ses attributs avec, optionnellement le domaine o lattribut prend ses valeurs : les entiers, les chanes de caractres ; 3. lindication du (ou des) attribut(s) permettant didentier lentit : ils constituent la cl.
'
(
% $ &#""!
'
21 . Enn, un ensemble dentits
Dnition 5 (Cl) Soit un type dentit et lensemble des attributs de . Une cl de est un sous-ensemble minimal de permettant didentier de manire unique une entit parmi nimporte quelle extension de . Prenons quelques exemples pour illustrer cette dnition. Un internaute est caractris par plusieurs attributs : son email, son nom, son prnom, la rgion o il habite. Lemail constitue une cl naturelle puisquon ne trouve pas, en principe, deux internautes ayant la mme adresse lectronique. En revanche lidentication par le nom seul parat impossible puisquon constitureait facilement un ensemble contenant deux internautes avec le mme nom. On pourrait penser utiliser la paire (nom,prnom), mais il faut utiliser avec modration lutilisation didentiants composs de plusieurs attributs, quoique possible, peut poser des problmes de performance et complique les manipulations par SQL. Il est possible davoir plusieurs cls pour un mme ensemble dentits. Dans ce cas on en choisit une comme cl primaire, et les autres comme cls secondaires. Le choix de la cl (primaire) est dterminant pour la qualit du schma de la base de donnes. Les caractristiques dune bonne cl primaire sont les suivantes : sa valeur est connue pour toute entit ; on ne doit jamais avoir besoin de la modier ; enn, pour des raisons de performance, sa taille de stockage doit tre la plus petite possible. Il nest pas toujours vident de trouver un ensemble dattributs satisfaisant ces proprits. Considrons lexemple des lms. Le choix du titre pour identier un lm serait incorrect puisquon aura affaire un jour ou lautre deux lms ayant le mme titre. Mme en combinant le titre avec un autre attribut (par exemple lanne), il est difcile de garantir lunicit. Dans la situation, frquente, o on a du mal dterminer quelle est la cl dune entit, on cre un identiant abstrait indpendant de tout autre attribut. On peut ainsi ajouter dans le type dentit Film un attribut id, corespondant un numro squentiel qui sera incrment au fur et mesure des insertions. Ce choix est souvent le meilleur, ds lors quun attribut ne simpose pas de manire vidente comme cl. Il satisfait notamment toutes les proprits nonces prcdemment (on peut toujours lui attribuer une valeur, il ne sera jamais ncessaire de la modier, et elle a une reprsentation compacte). On reprsente graphiquement un type dentit comme sur la gure 1.2 qui donne lexemple des types Internaute et Film. Lattribut (ou les attributs sil y en a plusieurs) formant la cl sont en gras.

Nom du type dentit Internaute email nom prnom rgion Identifiant Attributs Film id titre anne rsum genre
F IG . 1.2 Reprsentation des types dentit
Il est essentiel de bien distinguer types dentits et entits. La distinction est la mme quentre schma et base dans un SGBD, ou entre type et valeur dans un langage de programmation.
1.3.2 Associations binaires

La reprsentation (et le stockage) dentits indpendantes les unes des autres est de peu dutilit. On va maintenant dcrire les relations (ou associations) entre des ensembles dentits.

Dnition 6 Une association binaire entre les ensembles dentits et .
et
est un ensemble de couples

On dit quun entit est une instance de son type mme type est une extension de . Il reste dnir plus prcisment la notion de cl.
% $ !""
instance dun

, avec

1.3. LE MODLE
22
Cest la notion classique de relation en thorie des ensembles. On emploie plutt le terme dassociation pour viter toute confusion avec le modle relationnel. Une bonne manire dinterprter une association entre des ensembles dentits est de faire un petit graphe o on prend quelques exemples, les plus gnraux possibles.
Les ralisateurs Les liens "Ralise" Les films
Alfred Hitchcock Clint Eastwood
Vertigo Impitoyable Psychose
F IG . 1.3 Association entre deux ensembles.
Prenons lexemple de lassociation reprsentant le fait quun ralisateur met en scne des lms. Sur le graphe de la gure 1.3 on remarque que : 1. certains ralisateurs mettent en scne plusieurs lms ; 2. inversement, un lm est mis en scne par au plus un ralisateur. La recherche des situations les plus gnrales possibles vise sassurer que les deux caractristiques ci-dessus sont vraies dans tout les cas. Bien entendu on peut trouver 1% des cas o un lm a plusieurs ralisateurs, mais la question se pose alors : doit-on modier la structure de notre base, pour 1% des cas. Ici, on a dcid que non. Encore une fois on ne cherche pas reprsenter la ralit dans toute sa complexit, mais seulement la partie de cette ralit que lon veut stocker dans la base de donnes. Ces caractristiques sont essentielles dans la description dune association entre des ensembles dentits. Dnition 7 (Cardinalit) Soit une association pour , est une paire [min, max] telle que :
Les cardinalits maximales sont plus importantes que les cardinalits minimales ou, plus prcisment, elles savrent beaucoup plus difciles remettre en cause une fois que le schma de la base est constitu. On dcrit donc souvent une association de manire abrge en omettant les cardinalits minimales. La notation * , en UML, est labrviation de 0..* , et 1 est labrviation de 1..1 . On caractrise galement une association de manire concise en donnant les cardinalits maximales aux deux extrmits, par exemple 1:n (association de un plusieurs) ou n:n (association de plusieurs plusieurs). Les cardinalits minimales sont parfois dsignes par le terme contraintes de participation . La valeur 0 indique quune entit peut ne pas participer lassociation, et la valeur 1 quelle doit y participer. Insistons sur le point suivant : les cardinalits nexpriment pas une vrit absolue, mais des choix de conception. Elles ne peuvent tre dclars valides que relativement un besoin. Plus ce besoin sera exprim prcisment, et plus il sera possible dappcier la qualit du modle. Il existe plusieurs manires de noter une association entre types dentits. Nous utilisons ici la notation de la mthode UML, qui est trs proche de celle de la mthode OMT. En France, on utilise aussi couramment de moins en moins... la notation de la mthode MERISE que nous ne prsenterons pas ici.

2. Le symbole min (cardinalit minimale) dsigne le nombre minimal de fois o une une entit intervenir dans la relation. En gnral, ce nombre est 1 (au moins une fois) ou 0.
En gnral, ce nombre est 1 (au plus une fois) ou * .

(plusieurs fois, nombre indetermin), not par le symbole de peut
1. Le symbole max (cardinalit maximale) dsigne le nombre maximal de fois o une une entit intervenir dans lassociation.
#
entre deux types dentits. La cardinalit de lassociation de peut
%
23
Ralisateur 0..1 id nom prnom anneNaissance Ralise 0..n
Film id titre anne genre
F IG . 1.4 Reprsentation de lassociation.
Dans la notation UML, on indique les cardinalits aux deux extrmits dun lien dassociation entre deux types dentits et . Les cardinalits pour sont places lextrmit du lien allant de vers et les cardinalits pour sont lextrmit du lien allant de vers . Pour lassociation entre Ralisateur et Film, cela donne lassociation de la gure 1.4. Cette association se lit Un ralisateur ralise zro, un ou plusieurs lms, mais on pourrait tout aussi bien utiliser la forme passive avec comme intitul de lasscoiation Est ralis par et une lecture Un lm est ralis par au plus un ralisateur. Le seul critre privilgier dans ce choix des termes est la clart de la reprsentation. Prenons maintenant lexemple de lassociation (Acteur,Film) reprsentant le fait quun acteur joue dans un lm. Un graphe bas sur quelques exemples est donn dans la gure 1.5. On constate tout dabord quun acteur peut jouer dans plusieurs lms, et que dans un lm on trouve plusieurs acteurs. Mieux : Clint Eastwood, qui apparaissait dj en tant que metteur en scne, est maintenant galement acteur, et dans le mme lm.
Les acteurs Tom Cruise Gene Hackman Clint Eastwood Jacques Dutronc Les liens "Joue" Les films Ennemi dtat Impitoyable Van Gogh
F IG . 1.5 Association (Acteur,Film)
Cette dernire constatation mne la conclusion quil vaut mieux regrouper les acteurs et les ralisateurs dans un mme ensemble, dsign par le terme plus gnral Artiste . On obtient le schma de la gure 1.6, avec les deux associations reprsentant les deux types de lien possible entre un artiste et un lm : il peut jouer dans le lm, ou le raliser. Ce ou nest pas exclusif : Eastwood joue dans Impitoyable, quil a aussi ralis.
Artiste id Ralise 1..1 0..* 0..* rle

nom 0..* prnom anneNaiss Joue
F IG . 1.6 Associations entre Artiste et Film.
Dans le cas dassociations avec des cardinalits multiples de chaque ct, on peut avoir des attributs qui ne peuvent tre affects qu lassociation elle-mme. Par exemple lassociation Joue a pour attribut le rle tenu par lacteur dans
1.3. LE MODLE
24
le lm (gure 1.6). Rappelons quun attribut ne peut prendre quune et une seule valeur. Clairement, on ne peut associer rle ni Acteur puisquil a autant de valeurs possibles quil y a de lms dans lesquels cet acteur a jou, ni Film, la rciproque tant vraie galement. Seules les associations ayant des cardinalits multiples de chaque ct peuvent porter des attributs. Quelle est la cl dune association ? Si lon sen tient la dnition, une association est un ensemble de couples, et il ne peut donc y avoir deux fois le mme couple (parce quon ne trouve pas deux fois le mme lment dans un ensemble). On a donc :
En pratique cette contrainte est souvent trop contraignante car on souhaite autoriser deux entits tre lies plus dune fois dans une association. Imaginons par exemple quun internaute soit amen noter plusieurs reprises un lm, et que lon souhaite conserver lhistorique de ces notations successives. Avec une association binaire entre Internaute et Film, cest impossible : on ne peut dnir quun seul lien entre un lm donn et un internaute donn. Le problme est quil nexiste pas de moyen pour distinguer des liens multiples entre deux mmes entits. Le seul moyen pour effectuer une telle distinction est dintroduire une entit discriminante, par exemple la date de la notation. On obtient alors une association ternaire dans laquelle on a ajout un type dentit Date (gure 1.7).
Date date
Internaute email nom prnom rgion note
F IG . 1.7 Ajout dune entit Date pour conserver lhistorique des notations
Un lien de cette association runit donc une entit Film, une entit Internaute et une entit Date. On peut identier un tel lien par un triplet (id, email, date) constitu par les cls des trois entits constituant le lien. Comme le montre la gure 1.8, il devieent alors possible, pou un mme internaute, de noter plusieurs fois le mme lm, pourvu que ce ne soit pas la mme date. Rciproquement un internaute peut noter des lms diffrents le mme jour, et un mme lm peut tre not plusieurs fois la mme date, condition que ce ne soit pas par le mme internaute. Mme si cette solution est correcte, elle prsente linconvnient dintroduire une entit assez articielle, Date, qui porte peu dinformation et vient alourdir le schma. En pratique on sautorise une notation abrge en ajoutant un attribut date dans lassociation, et en le soulignant pour indiquer quil fait partie de la cl, en plus du couple des cls des entits (voir gure 1.9). Nous reviendrons plus longuement sur les associations ternaires par la suite.
1.3.3 Entits faibles

Jusqu prsent nous avons considr le cas dentits indpendantes les unes des autres. Chaque entit, disposant de son propre identiant, pouvait tre considre isolment. Il existe des cas o une entit ne peut exister quen troite association avec une autre, et est identie relativement cette autre entit. On parle alors dentit faible. Prenons lexemple dun cinma, et de ses salles. On peut considrer chaque salle comme une entit, dote dattributs comme la capacit, lquipement en son Dolby, ou autre. Il est diffcilement imaginable de reprsenter une salle
Dnition 8 (Cl dune association) La cl dune association (binaire) entre un type dentit est le couple constitu de la cl de et de la cl de .
et un type dentit

Internautes Phileas Fogg Jules Maigret Films Ennemi dtat Van Gogh
25
12 juillet 2023
6 juin 2000
Dates
F IG . 1.8 Graphe dune association ternaire
Internaute 0..n email nom prnom rgion date note
0..n
F IG . 1.9 Notation abrge dune association avec un type dentit Date
sans quelle soit rattache son cinma. Cest en effet au niveau du cinma que lon va trouver quelques informations gnrales comme ladresse ou le numro de tlphone. Il est possible de reprsenter le lien en un cinma et ses salles par une association classique, comme le montre la gure 1.10.a. La cardinalit 1..1 force la participation dune salle un lien dassociation avec un et un seul cinma. Cette reprsentation est correcte, mais prsente un inconvnient : on doit crer un identiant articiel id pour le type dentit Salle, et numroter toutes les salles, indpendamment du cinma auquel elles sont rattaches. On peut considrer quil est beaucoup plus naturel de numroter les salles par un numro interne chaque cinma. La cl didentication dune salle est alors constitue de deux parties : 1. la cl de Cinma, qui indique dans quel cinma se trouve la salle ; 2. le numro de la salle au sein du cinma. En dautres termes, lentit salle ne dispose pas dune identication absolue, mais dune identication relative une autre entit. Bien entendu cela force la salle a toujours tre associe un et un seul cinma. La reprsentation graphique des entits faibles avec UML est illustre dans la gure 1.10.b. La salle est associe au cinma avec une association qualie par lattribut no qui sert de discriminant pour distinguer les salles au sein dun mme cinma. Noter que la cardinalit du ct Cinma est implicitement 1..1 . Lintroduction dentits faibles nest pas une ncessit absolue puisquon peut trs bien utiliser une association classique. La principale diffrence est que, dans le cas dune entit faible, on obtient un identication compose qui est souvent plus pratique grer, et peut galement rendre plus faciles certaines requtes. La prsence dun type dentit faible associ un type dentit implique galement des contraintes fortes sur les crations, modications et destructions des instances de et car on doit toujours sassurer que la contrainte est valide. Concrtement, en prenant lexemple de Salle et de Cinma, on doit mettre en place les mcanismes suivants : 1. Quand on insre une salle dans la base, on doit toujours lassocier un cinma ;

1.3. LE MODLE
Cinma nom ville rue numro 1 * Salle id capacit dateConstr. (a) Cinma nom ville rue numro no * Salle capacit dateConstr. (b)
26
F IG . 1.10 Modlisation du lien Cinma-Salle (a) sous la forme dune association classique (b) avec une entit faible
2. quand un cinma est dtruit, on doit aussi dtruire toutes ses salles ; 3. quand on modie la cl dun cinma, il faut rpercuter la modication sur toutes ses salles. Pour respecter les rgles de destruction/cration nonces, on doit mettre en place une stratgie. Nous verrons que les SGBD relationnels nous permettent de spcier de telles stratgies.
1.3.4 Associations gnralises

On peut envisager des associations entre plus de deux entits, mais elles sont plus difciles comprendre, et surtout la signication des cardinalits devient beaucoup plus ambigue. La dnition dune association -aire est une gnralisation de celle des associations binaires.
Mme sil ny a en principe pas de limite sur le degr dune association, en pratique on ne va jamais au-del dune association entre trois entits.
Cinma nom ville rue numro no * Salle capacit dateConstr. Horaire id heureDbut heureFin
Sance
tarif
F IG . 1.11 Association ternaire reprsentant les sances
$ !"! #
Dnition 9 Une association -aire entre types dentits o chaque appartient .
est un ensemble de -uplets
$ !"!"

Horaires 14h16h 16h18h Films Salles Salle Rex1 Salle Kino3 Impitoyable Vertigo
27
F IG . 1.12 Graphe dune association ternaire
Nous allons prendre lexemple dune association permettant de reprsenter la projection de certains lms dans des salles certains horaires. Il sagit dune association ternaire entre les types dentits Film, Salle et Horaire (gure 1.11). Chaque instance de cette association lie un lm, un horaire et une salle. La gure 1.12 montre quelques-unes de ces instances. Bien que, jusqu prsent, une association ternaire puisse tre considre comme une gnralisation directe des associations binaires, en ralit de nouveaux problmes sont soulevs. Tout dabord les cardinalits sont, implicitement, 0..* . Il nest pas possible de dire quune entit ne participe quune fois lassociation. Il est vrai que, dune part la situation ce prsente rarement, dautre part cette limitation est due la notation UML qui place les cardinalits lextrmit oppose dune entit. Plus problmatique en revanche est la dtermination de la cl. Quest-ce qui identie un lien entre trois entits ? En principe, la cl est le triplet constitu des cls respectives de la salle, du lm et de lhoraire constituant le lien. On aurait donc le -uplet [nomCinma, noSalle, idFilm, idHoraire]. Une telle cl est assez volumineuse, ce qui risque de poser des problmes de performance. De plus elle ne permet pas dimposer certaines contraintes comme, par exemple, le fait que dans une salle, pour un horaire donn, il ny a quun seul lm. Comme le montre la gure 1.12, il est tout fait possible de crer deux liens distincts qui sappuient sur le mme horaire et la mme salle. Ajouter une telle contrainte, cest signier que la cl de lassociation est en fait le couple (nomCinma, noSalle, idHoraire]. Donc cest un sous-ensemble de la concatnation des cls, ce qui semble rompre avec la dnition donne prcdemment. On peut videmment compliquer les choses en ajoutant une deuxime contrainte similaire, comme connaissant le lm et lhoraire, je connais la salle . Il faut ajouter une deuxime cl [idFilm, idHoraire]. Il nest donc plus possible de dduire automatiquement la cl comme on le faisait dans le cas des associations binaires. Plusieurs cls deviennent possibles : on parle de cl candidates. Les associations de degr suprieur deux sont donc difciles manipuler et interprter. Il est toujours possible de remplacer cette association par un type dentit. Pour cela on suit la rgle suivante :
1. On attribue un identiant autonome .
Lassociation prcdente peut tre transforme en un type dentit Sance. On lui attribue un identiant idSeance et des associations 1-n avec Film, Horaire et Salle. Voir gure 1.13.
1.4 Avantage et inconvnients du modle E/A

Le modle Entit/Association est simple et pratique. 1. Il ny a que 3 concepts : entits, associations et attributs. 2. Il est appropri une reprsentation graphique intuitive, mme sil existe beaucoup de conventions.
2. On cre une association toujours 1.
de type 1:n entre
et chacun des
. La contrainte minimale, du ct de
% $ #""!"
Rgle 1 Soit une association entre les types dentit seffectue en trois tapes :
. La transformation de
en type dentit
, est
1.4. AVANTAGE ET INCONVNIENTS DU MODLE E/A

Cinma nom ville rue numro no * Salle 1..1 capacit dateConstr. * id tarif Horaire id heureDbut heureFin 1..1 * Sance *
28
Film 1..1 id titre anne genre
F IG . 1.13 Lassociation Sance transforme en entit
3. Il permet de modliser rapidement des structures pas trop complexes. Il y a malheureusement plusieurs inconvnients. Tout dabord il est non-dterminisme : il ny a pas de rgle absolue pour dterminer ce qui est entit, attribut ou relation. Exemple : est-il prfrable de reprsenter le metteur en scne (MES) comme un attribut de Film ou comme une association avec Artiste ? Rponse : comme une association ! Les arguments sont les suivants : 1. On connat alors non seulement le nom, mais aussi toutes les autres proprits (prnom, ge, ...). 2. Lentit MES peut-tre associe beaucoup dautres lms : on permet le partage de linformation. Autre exemple : est-il indispensable de grer une entit Horaire ? Rponse : pas forcment ! Arguments : 1. Pour. Permet de normaliser les horaires. Plusieurs sances peuvent alors faire rfrence au mme horaire (gain de place, facilit de mise jour, cohrence, ...) 2. Contre. On alourdit le schma inutilement : un horaire est propre une sance. On peut le reprsenter comme un attribut de Sance. Enn on a vu quune association pouvait tre transforme en entit. Un des principaux inconvnients du modle E/A reste sa pauvret : il est difcile dexprimer des contraintes dintgrit, des structures complexes. Beaucoup dextensions ont t proposes, mais la conception de schma reste en partie matire de bon sens et dexprience. On essaie en gnral : 1. de se ramener des associations entre 2 entits : au-del, on a probablement intrt a transformer lassociation en entit ; 2. dviter toute redondance : une information doit se trouver en un seul endroit ; 3. enn et surtout de privilgier la simplicit et la lisibilit, notamment en ne reprsentant que ce qui est strictement ncessaire. Pour en savoir plus Le modle E/A est utilis dans la plupart des mthodes danalyse/conception : OMT, CASE, MERISE, etc. La syntaxe varie, mais on retrouve toujours les mmes lments fondamentaux. Pour en savoir (beaucoup) plus : J. Rumbauch , . Dans le cadre des bases de donnes, le modle E/A est utilis dans la phase de conception. Il permet de spcier la structure des informations qui vont tre contenues dans la base et doffrir une reprsentation abstraite indpendante du modle logique qui sera choisi ensuite. Le modle E/A cepedant linconvnient majeur de ne pas proposer doprations sur les donnes.
!
29
1.5 Exercices
Exercice 1 On vous donne un schma E/A (gure 1.14) reprsentant des visites dans un centre mdical. Rpondez aux questions suivantes en fonction des caractristiques de ce schma (autrement dit, indiquez si la situation dcrite est reprsentable, indpendamment de sa vraissemblance).
Mdicament code libell 0..* nbPrises 0..* Consultation no date Mdecin matricule nom 1..1 Donne Patient noSS nom 1..1 Assiste
0..*
0..*
F IG . 1.14 Centre mdical
1. Un patient peut-il effectuer plusieurs visites ? 2. Un mdecin peut-il recevoir plusieurs patients dans la mme consultation ? 3. Peut-on prescrire plusieurs mdicaments dans une mme consultation ? 4. Deux mdecins diffrents peuvent-ils prescrire le mme mdicament ?
Exercice 2 Le second schma (gure 1.15) reprsente des rencontres dans un tournoi de tennis.
Joueur noCarte nom 2..2 Joue 0..* Terrain no surface 1..1 0..* Se joue sur
Gagne 1..1 0..* Match id horaire
F IG . 1.15 Tournoi de tennis
1. Peut-on jouer des matchs de double ? 2. Un joueur peut-il gagner un match sans y avoir particip ? 3. Peut-il y avoir deux matchs sur le mme terrain la mme heure ? 4. Connaissant un joueur, peut-on savoir sur quels terrains il a jou ?
1.5. EXERCICES
30
Journaliste id nom dateNaiss 1..1 rdige 0..n interviewe 0..n
Personnalit id nom 0..n prnom nation. Journal nom adresse 0..n no Numro date tirage
a travaill pour 0..n Article no contenu 0..n parat dans 0..n
1..1
1..1
Sujet id libelle
F IG . 1.16 Systme dinformation dun quotidien
Exercice 3 Voici le schma E/A (gure 1.16) du systme dinformation (trs simpli) dun quotidien. 1. Un article peut-il tre rdig par plusieurs journalistes ? 2. Un article peut-il tre publi plusieurs fois ? 3. Peut-il y avoir plusieurs articles sur le mme sujet dans le mme numro ? 4. Connaissant une article, est-ce que je connais le journal o il est paru ? Exercice 4 Voici (gure 1.17) le dbut dun schma E/A pour la gestion dune mdiathque. La spcication des besoins est la suivante : un disque est constitu dun ensemble de plages. Chaque plage contient un oeuvre et une seule, mais une oeuvre peut stendre sur plusieurs plages (Par exemple une symphonie en 4 mouvements). De plus, pour chaque plage, on connat les interprtes. 1. Compltez le modle de la gure 1.17, en ajoutant les cardinalits. 2. On suppose que chaque interprte utilise un instrument (voix, piano, guitare, etc) et un seul sur une plage. O placer lattribut Instrument dans le modle prcdent ? 3. Transformez lassociation Joue dans la gure 1.17 en entit. Donnez le nouveau modle, sans oublier les cardinalits. 4. Introduisez maintenant les entits Auteur (dune oeuvre) et Editeur dun disque dans le schma. Un disque na quun diteur, mais une oeuvre peut avoir plusieurs auteurs. Exercice 5 La gure 1.18 montre la modlisation de sances de cours sous forme dune association ternaire. Noter que lhoraire fait partie de la cl (on aurait pu le reprsenter comme une entit supplmentaire). La notion de cours regroupe les notions de cours magistral, enseignement dirig et travaux pratiques, pour une UV donne. Par exemple lUV Base de donnes comprend un cours, un ED et un TP.


Plage dure dateEnreg Disque titre no anne producteur
31
Oeuvre id titre anne
Interprte joue sur id nom prnom
F IG . 1.17 Contenu dun disque
1. Donner une reprsentation, sous forme de graphe ou de tableau, de linstance de lassociation correspondant aux enseignements (cours, EDs, TPs) de lUV Base de donnes. 2. Comment exprimer les contraintes suivantes : (i) un professeur ne donne pas deux cours en mme temps, (ii) Pour une salle, un cours, un horaire, il y a un seul professeur. 3. Transformer lassociation en entit, selon la rgle vue en cours.
Exercice 6 Voici quelques tableaux (gure 1.19, 1.20, 1.21) reprsentant des associations entre entits. Pour chacun, 1. Donner une reprsentation sous forme de graphe. 2. Donner le schma E/A avec les cardinalits correspondant aux exemples donns.
COURS #ID Libelle Niveau Seance #date-heure
SALLE #ID No Emplacement
PROFESSEUR #ID Nom Grade
F IG . 1.18 Sances de cours

1.5. EXERCICES
32
SOCIETE Tresys Fungus Demona Faribole
DIRECTEUR Charlus Morel Saint-Loup Charlus
F IG . 1.19 Association SOCIETE/DIRECTEUR
ORDINATEUR PC124 MAC04 MAC03 PC02 MAC03
UTILISATEUR Charlus Morel Saint-Loup Morel Charlus
F IG . 1.20 Association ORDINATEUR/UTILISATEUR
ORDINATEUR PC124 MAC04 MAC04 PC124 PC02
DISQUES dsk09 dsk08 dsk05 dsk11 dsk04
F IG . 1.21 Association ORDINATEUR/DISQUES DURS
CHAPITRE 2. LE MODLE RELATIONNEL
33
Chapitre 2
Le modle relationnel
Sommaire
2.1 2.2 Dnition dun schma relationnel . . . . . . . . Passage dun schma E/A un schma relationnel 2.2.1 Rgles gnrales . . . . . . . . . . . . . . . 2.2.2 Retour sur le choix des identiants . . . . . 2.2.3 Dnormalisation du modle logique . . . . . Le langage de dnition de donnes SQL2 . . . . 2.3.1 Types SQL . . . . . . . . . . . . . . . . . 2.3.2 Cration des tables . . . . . . . . . . . . . 2.3.3 Contraintes . . . . . . . . . . . . . . . . . 2.3.4 Modication du schma . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 35 35 40 41 42 43 44 45 48 49
2.3
2.4
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. 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 dapplication 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, offre 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.
2.1 Dnition dun schma relationnel

Un des grands avantages du modle relationnel est sa trs grande simplicit. Il nexiste en effet quune seule structure, la relation. Une relation peut simplement tre reprsente sous forme de table, comme sur la gure 2.1. Une relation a donc un nom (Film) et se compose dun ensemble de colonnes dsignes par un nom dattribut. Dans chaque
2.1. DFINITION DUN SCHMA RELATIONNEL

titre Alien Vertigo Volte-face Pulp Fiction anne 1979 1958 1997 1995 genre Science-Fiction Suspense Thriller Policier
34
F IG . 2.1 Une relation colonne on trouve des valeurs dun certain domaine (chanes de caractres, nombres). Enn on constate que chaque ligne (ou tuple) correspond une entit (ici des lms). Un schma relationnel est constitu dun ensemble de schmas de relations qui dcrivent, laide des lements prsents informellement ci-dessus (domaines, attributs, noms de relation) le contenu dune relation. Le schma de la relation de la gure 2.1 est donc : Film (titre: string, anne: number, genre : string) Il existe un langage de dnition pour crer une relation dans un SGBDR (voir section 2.3), mais nous nous contenterons pour linstant de la description ci-dessus. Voici maintenant quelques prcisions sur la terminologie introduite ci-dessus. Domaines Un domaine de valeurs est un ensemble dinstances dun type lmentaire. Exemple : les entiers, les rels, les chanes de caractres, etc. La notion de type lmentaire soppose celle de type structur : il est interdit en relationnel de manipuler des valeurs instances de graphes, de listes, denregistrements, etc. En dautres termes le systme de types est g et fourni par le systme. Attributs Les attributs nomment les colonnes dune relation. Il servent la fois indiquer le contenu de cette colonne, et la rfrencer quand on effectue des oprations. Un attribut est toujours associ un domaine. Le nom dun attribut peut apparatre dans plusieurs schmas de relations. Schma de relation Un schma de relation est simplement un nom suivi de la liste des attributs, chaque attribut tant associ son domaine. La syntaxe est donc :
o les sont les noms dattributs et les les domaines. Larit dune relation est le nombre de ses attributs. On peut trouver dans un schma de relation plusieurs fois le mme domaine, mais une seule fois un nom dattribut. Le domaine peut tre omis en phase de dnition. Instance dune relation Une instance dune relation , ou simplement relation se dnit mathmatiquement comme un sous-ensemble ni du produit cartsien des domaines des attributs de . Rappelons que le produit cartsien entre des domaines est lensemble de tous les tuples o . Un des fondements du modle relationnel est la thorie des ensembles et la notion de relation dans le modle correspond strictement au concept mathmatique dans cette thorie. Une relation se reprsente sous forme de table, et on emploie le plus souvent ces deux termes comme des synonymes. La dnition dune relation comme un ensemble (au sens mathmatique) a quelques consquences importantes : 1. lordre des lignes na pas dimportance car il ny a pas dordre dans un ensemble ;
"!
$ $ "!"!
$ "!"!
$ !"!"

2. on ne peut pas trouver deux fois la mme ligne car il ny a pas de doublons dans un ensemble ; 3. il ny a pas de case vide dans la table, donc toutes les valeurs de tous les attributs sont toujours connues ; Dans la pratique les choses sont un peu diffrentes : nous y reviendrons. Cl dune relation

35
La cl dune relation est le plus petit sous-ensemble des attributs qui permet didentier chaque ligne de manire unique. Comme on a vu que deux lignes sont toujours diffrentes, lensemble de tous les attributs est lui-mme une cl mais on peut pratiquement toujours trouver un sous-ensemble qui satisfait la condition. Pour distinguer la cl, nous mettrons le (ou les) attribut(s) en gras. Film (titre, anne, genre) Le choix de la cl est trs important pour la qualit du schma. Choisir didentier un lm par son titre comme nous lavons envisag dans lexemple prcdent nest pas un trs bon choix : nous y reviendrons. Tuples
(Cyrano, 1992, Rappeneau)
Un tuple est donc simplement une ligne dans la reprsentation dune relation sous forme de table. En thorie, on connat les valeurs de tous les attributs du tuple. Base de donnes Une (instance de) base de donnes est un ensemble ni (dinstances) de relations. Le schma de la base est lensemble des schmas des relations de cette base. 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 difcile car il dtermine en grande partie les caractristiques, qualits de la base : performances, exactitude, exhaustivit, disponibilit 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. En pratique, on procde dune manire moins rigoureuse mais plus accessible, en concevant le schma laide dun modle de donnes conceptuel , puis en transcrivant le shma conceptuel obtenu en schma relationnel. La technique la plus rpandue consiste partir dun schma Entit/Association. La section suivante donne les rgles du processus de transformation, en sappuyant sur lexemple de la gure 2.2.
2.2 Passage dun schma E/A un schma relationnel

On passe donc dun modle disposant de deux structures (entits et associations) un modle disposant dune seule structure (relations). Logiquement, entits et associations seront donc toutes deux transformes en relations. La subtilit rside en fait dans la ncesit de prserver les liens existant explicitement dans un schma E/A et qui semblent manquer dans le modle relationnel. Dans ce dernier cas on utilise en fait un mcanisme de rfrence par valeur bas sur les cls des relations. Le choix de la cl dune relation est un problme central dans la conception de schma.
2.2.1 Rgles gnrales

Nous allons considrer dans un premier temps que la cl est dnie, pour chaque type dentit E, par un identiant abstrait, idE.
Un tuple est une liste de . Exemple :
valeurs
o chaque valeur
est la valeur dun attribut
$ """!
de domaine
2.2. PASSAGE DUN SCHMA E/A UN SCHMA RELATIONNEL
36
Artiste id Ralise nom 0..1 prnom anneNaissance 0..* Joue 0..* rle Cinma nom adresse no Donne une note * note 0..* Film id titre anne genre rsum *
Internaute email nom prnom motDePpasse anneNaissance
1..1
Pays code nom langue
Salle capacit climatise
Horaire id heureDbut heureFin
F IG . 2.2 Le schma de la base de donnes Films
Rgles de passage : entits Rappel : le schma dune relation est constitu du nom de la relation, suivi de la liste des attributs. Alors, pour chaque entit du schma E/A: 1. On cre une relation de mme nom que lentit. 2. Chaque proprit de lentit, y compris lidentiant, devient un attribut de la relation. 3. Les attributs de lidentiant constituent la cl de la relation. Exemple 1 partir du schma E/A Ofciel des spectacles, lexception des entits concernant les cinmas, les salles et les horaires, on obtient les relations suivantes : Film (idFilm, titre, anne, genre, rsum) Artiste (idArtiste, nom, prnom, anneNaissance) Internaute (email, nom, prnom, rgion) Pays (code, nom, langue) On peut remarquer que lon a perdu pour linstant tout lien entre les relations. Rgles de passage : associations de un plusieurs et
Soit une association de un plusieurs 1 entre
1. Il sagit ici des cardinalits maximales qui dterminent pour lessentiel le schma relationnel obtenu.
1. On cre les relations
et
correspondant respectivement aux entits
et
. Le passage au modle logique suit les rgles suivantes : .
37 .

Lide est quune occurence de rfrence loccurence de qui lui est associe laide dune cl trangre. Cette rfrence se fait de manire unique et sufsante laide de lidentiant. Exemple 2 Voici le schma obtenu pour reprsenter lassociation entre les types dentit Film, Artiste et Pays. Les cls trangres sont en italiques. Film (idFilm, titre, anne, genre, rsum, idArtiste, codePays) Artiste (idArtiste, nom, prnom, anneNaissance) Pays (code, nom, langue) Le rle prcis tenu par lartiste dans lassociation disparat. Lartiste dans Film a un rle de metteur en scne, mais il pourrait tout aussi bien sagir du dcorateur ou de laccessoiriste. Rien nempche cependant de donner un nom plus explicite lattribut. Il nest pas du tout obligatoire en fait que les attributs constituant une cl trangres aient le mme nom que ceux de le cl primaire auxquels ils se rfrent. Voici le schma de la table Film, dans lequel la cl trangre pour le metteur en scne est nomme idMES. Film (idFilm, titre, anne, genre, rsum, idMES) Les tables ci-dessous montrent un exemple de la reprsentation des associations entre Film et Artiste dune part, Film et Pays dautre part (on a omis le rsum du lm). Noter que si on ne peut avoir quun artiste dont lid est 2 dans la table Artiste, en revanche rien nempche cet artiste 2 de gurer plusieurs fois dans la colonne idMES de la table Film. On a donc bien lquivalent de lassociation un plusieurs labore dans le schma E/A. idFilm 100 101 102 103 104 105 106 107 titre Alien Vertigo Psychose Kagemusha Volte-face Van Gogh Titanic Sacrice anne genre 1979 Science Fiction 1958 Suspense 1960 Suspense 1980 Drame 1997 Action 1991 Drame 1997 Drame 1986 Drame La table Film idMES 1 2 2 3 4 8 6 7 codePays US US US JP US FR US FR

idArtiste 1 2 3 4 6 7 8
nom prnom Scott Ridley Hitchcock Alfred Kurosawa Akira Woo John Cameron James Tarkovski Andrei Pialat Maurice La table Artiste
Rgles de passage : associations avec type entit faible Une entit faible est toujours identie par rapport une autre entit. Cest le cas par exemple de lassociation en Cinma et Salle (voir chapitre 1). Cette association est de type un plusieurs car lentit faible (une salle) est lie une seule autre entit (un cinma) alors que, en revanche, un cinma peut tre li plusieurs salles.

2. Lidentiant de
devient un attribut de
anneNaiss 1943 1899 1910 1946 1954 1932 1925
code US FR JP
nom langue Etats Unis anglais France franais Japon japonais La table Pays
38
Le passage un schma relationnel est donc identique celui dune association 1- classique. On utilise un mcanisme de cl trangre pour rfrencer lentit forte dans lentit faible. La seule nuance est que la cl trangre est une partie de lidentiant de lentit faible. Exemple 3 Voici le schma obtenu pour reprsenter lassociation entre les types dentit Cinma et Salle. On note que lidentiant dune salle est constitu de lidentiant du cinma (ici on a considr que le nom du cinma sufsiat lidentier), et dun numro complmentaire permettant de distinguer les salles au sein dun mme cinma. La cl trangre est donc une partie de la cl primaire. Cinma (nomCinma, numro, rue, ville) Salle (nomCinma, no, capacit) Rgles de passage : associations binaires de plusieurs plusieurs Soit une association binaire n-m entre et
. et
Exemple 4 Toujours partir du schma Ofciel des spectacles, on obtient la table Rle reprsentant lassociation entre les lms et les acteurs. Film (idFilm, titre, anne, genre, rsum, idMES, codePays) Artiste (idArtiste, nom, prnom, anneNaissance) Role (idFilm, idActeur, nomRle) De mme, on obtient une table Notation pour reprsenter lassociation entre un internaute et les lms quil a nots. Film (idFilm, titre, anne, genre, rsum, idMES, codePays) Internaute (email, nom, prnom, rgion) Notation (email, idFilm, note) Les tables suivantes montrent un exemple de reprsentation de Rle. On peut constater le mcanisme de rfrence unique obtenu grce aux cls des relations. Chaque rle correspond un unique acteur et un unique lm. De plus on ne peut pas trouver deux fois la mme paire (idFilm, idActeur) dans cette table, ce qui naurait pas de sens. En revanche un mme acteur peut gurer plusieurs fois (mais pas associ au mme lm), ainsi quun mme lm (mais pas associ au mme acteur). idFilm 20 21 titre Impitoyable Ennemi dtat anne genre 1992 Western 1998 Action La table Film idMES 100 102 codePays USA USA
idArtiste 100 101 102 103
nom prnom Eastwood Clint Hackman Gene Scott Tony Smith Will La table Artiste
anneNaiss 1930 1930 1930 1968
idFilm 20 20 21 21
5. Les proprits de lassociation deviennent des attributs de
idActeur rle 100 William Munny 101 Little Bill 101 Bril 103 Robert Dean La table Rle
4. La cl de cette relation est la concatnation des cls des relations
et
3. La cl de
et la cl de
deviennent des attributs de
2. On cre une relation
pour lassociation. . .
1. On cre les relations
et
correspondant respectivement aux entits
39
On peut remarquer nalement que chaque partie de la cl de la table Rle est elle-mme une cl trangre qui fait rfrence une ligne dans une autre table : 1. lattribut idFilm fait rfrence une ligne de la table Film (un lm) ; 2. lattribut idActeur fait rfrence une ligne de la table Artiste (un acteur) ; Le mme principe de rfrencement et didentication des tables sapplique la table Notation dont un exemple est donn ci-dessous. Il faut bien noter que, par choix de conception, on a interdit quun internaute puisse noter plusieurs fois le mme lm, de mme quun acteur ne peut pas jouer plusieurs fois dans un mme lm. Ces contraintes ne constituent pas des limitations, mais des dcisions prises au moment de la conception sur ce qui est autoris, et sur ce qui ne lest pas. idFilm 100 101 102 103 104 105 106 107 titre Alien Vertigo Psychose Kagemusha Volte-face Van Gogh Titanic Sacrice anne genre 1979 Science Fiction 1958 Suspense 1960 Suspense 1980 Drame 1997 Action 1991 Drame 1997 Drame 1986 Drame La table Film idMES 1 2 2 3 4 8 6 7 codePays USA USA USA JP USA FR USA FR
email nom prnom doe@void.com Doe John fogg@verne.fr Fogg Phileas La table Internaute
anneNaiss 1945 1965
idFilm 100 104 100 107 106
email note fogg@verne.fr 4 fogg@verne.fr 3 doe@void.com 5 doe@void.com 2 fogg@verne.fr 5 La table Notation
Le processus de conception dtaill ci-dessus permet de dcomposer toutes les informations dune base de donnes en plusieurs tables dont chacune stocke un des ensembles dentits grs par lapplication. Les liens sont dnis par un mcanisme de rfrencement bas sur les cls primaires et les cls trangres. Il est important de bien comprendre ce mcanisme pour matriser la construction de bases de donnes qui ne ncessiteront par de rorganisation ncessairement douloureuse par la suite. Associations ternaires Dans le cas dassociations impliquant plus de deux entits, on atteint une des limites du modle Entit/Association en matire de spcication de contraintes. En premire approche, on peut appliquer la rgle nonce prcdemment pour les associations binaires et la gnraliser. On obtiendrait alors, pour lassociation Sance : Cinma (nomCinma, numro, rue, ville) Salle (nomCinma, no, capacit) Film (idFilm, titre, anne, genre, rsum, idMES, codePays) Horaire (idHoraire, heureDbut, heureFin) Sance (idFilm, nomCinma, noSalle, idHoraire, tarif)

idCinma no capacit Le Rex 1 200 Kino 1 130 Le Rex 2 180 La table Salle idHoraire heureDbut heureFin 1 14 16 2 16 18 La table Horaire idFilm 100 101 102 103 104 105 106 107 titre Alien Vertigo Psychose Kagemusha Volte-face Van Gogh Titanic Sacrice anne genre 1979 Science Fiction 1958 Suspense 1960 Suspense 1980 Drame 1997 Action 1991 Drame 1997 Drame 1986 Drame La table Film idMES 1 2 2 3 4 8 6 7 codePays USA USA USA JP USA FR USA FR
40
idFilm 103 103 100 102
nomCinma noSalle idHoraire Le Rex 2 1 Le Rex 2 2 Kino 1 2 Le Rex 2 1 La table Sance
tarif 23 56 45 50
F IG . 2.3 Reprsentation dune association ternaire : Sance Donc, la relation Sance a pour cl la concatnation des identiants de chacune des entits composantes, ce qui donne une cl dune taille assez importante. On autorise alors une base comme celle de la gure 2.3. On ne peut pas trouver deux fois le mme triplet constituant la cl. Maintenant on saperoit que la mme salle prsente deux lms diffrents au mme horaire. Si on souhaite viter cette situation, la cl devient (nomCinma, noSalle, idHoraire), et on ne respecte plus la rgle de passage du schma E/A vers le schma relationnel. En dautres termes, en cas dassociation entre plus de 2 entits, la cl de la table reprsentant lassociation est un sous-ensemble de la concatnation des cls. Il faut se poser soigneusement la question de la (ou des) cl(s) au moment de la cration de la table car elle(s) ne peu(ven)t plus tre dduite(s) du schma E/A. On parle parfois de cl candidate. Ces cls peuvent tre spcies avec la clause UNIQUE du langage SQL2.
2.2.2 Retour sur le choix des identiants

Il est prfrable en gnral de choisir un identiant neutre qui ne soit pas une proprit de lentit. En effet : 1. Chaque valeur de lidentiant doit caractriser de manire unique une occurence. Exemple : titre pour la relation Film ou nom pour la relation Acteur ne sont clairement pas des bons choix. 2. Si on utilise un ensemble de proprits comme identiant, la rfrence une occurence est trs lourde. Exemple : la cl de Cinma pourrat tre (nom, rue, ville). 3. Lidentiant sert de rfrence externe et ne doit donc jamais tre modiable (il faudrait rpercuter les mises jour).


41
Linconvnient de lidentiant neutre est quil ne donne pas dindication sur loccurence quil rfre. Par exemple, quand on consulte la table Sance, on ne sait pas dire de quel lm il sagit sans aller rechercher la ligne de la table Film correspondant lidentiant du lm. En admettant pour un sintant que le titre identie de manire unique un lm, le schma de la table Film devient : Film (titre, anne, genre, rsum, idMES, codePays) La relation Sance a alors pour schma : Sance (titreFilm, nomCinma, noSalle, idHoraire, tarif) ce qui permet dobtenir le titre du lm directement, comme le montre linstance ci-dessous. titreFilm nomCinma noSalle idHoraire Kagemusha Le Rex 2 1 Kagemusha Le Rex 2 2 Alien Kino 1 2 Psychose Le Rex 2 1 La table Sance, avec le titre du lm tarif 23 56 45 50

Un problme du schma ci-dessus est que la rfrence une ligne de la table Sance devient complique, et donc peu performante. Il faut veiller limiter le nombre de champs constituant une cl car lexpression des requtes est plus lourde, et leur excution peut tre ralentie par la taille des index.
2.2.3 Dnormalisation du modle logique

Le terme de dnormalisation sapplique un non-respect des rgles nonces prcdemment, avec deux objectifs principaux : 1. Simplier le schma relationnel en rduisant le nombre dlments qui le composent (chiers ou segments ou records ou relation). 2. Faciliter laccs aux donnes en introduisant un certain degr de redondance. Ces techniques reviennent introduire des anomalies dans le schma. Il faut donc systmatiquement comparer le gain attendu avec les risques courus ! Suppression de relations On peut supprimer les entits qui portent peu dattributs en les dplaant vers une autre relation. Exemple : si le schma de Cinema est simplement Cinma (nom, adresse), on peut supprimer la relation et placer ladresse dans Salle. Salle (nomCinma, noSalle, adresse) Ladresse dun cinma est duplique autant de fois quil y a de salles. Cette option implique une perte de place due la redondance, un effort de saisie supplmentaire, et des risques dincohrences. Elle ne peut tre valable que tant quil ny a pas dattrbuts ajouter pour qualier un cinma. Quand ce sera le cas, il faudra nalement se dcider (1) crer la relation Cinma et (2) supprimer les attributs mal placs dans Salle. Autre exemple : il peut paratre inutile de crer Horaire pour grer un couple dheures. On peut alors placer lhoraire dans la relation Sance. An de permettre lexistence de plusieurs lignes avec le mme lm et la mme salle, il faut introduire lattribut heureDbut dans la cl. On obtient le schma suivant. Sance (idFilm, nomCinema, noSalle, heureDbut, heureFin, tarif) Cette variante prsente peu dinconvnients. On peut tout juste citer le fait quil y a duplication de certains horaires, et que la gestion contraintes (heure dbut heure n) doit tre gre pour plus de lignes. En fait la cration dun type dentit Horaire ou Date, mme si elle se justie en thorie, prsente plus dinconvnients que davantages. En pratique, on place toujours un attribut horaire ou date dans le schma de la relation.
2.3. LE LANGAGE DE DFINITION DE DONNES SQL2

Introduction de redondance
42
En principe il faut viter les redondances dans une base de donnes. Donc une information est reprsente soit explicitement (elle gure une fois et une seule), soit implicitement (elle peut tre dduite ou calcule). Laccs une information peut cependant tre long et/ou compliqu, et justier lintroduction de redondances. Par exemple : partir de la table Sance, il faut consulter Salle puis Cinma pour connatre ladresse du cinma. ; il faut faire un calcul pour obtenir le nombre de salles dun cinma. En pratique on peut tre amen introduire (prudemment) des redondances. Les problmes prcdents pourraient ainsi se rsoudre de la manire suivante : ajout de ladresse du cinma dans la table Sance. Sance (idFilm, nomCinema, noSalle, idHoraire, adresse) Le risque peut tre considr comme mineur car ladresse dun cinma change rarement. ajout du nombre de salles dans la relation Cinma. Cinma (nomCinema, numro, rue, ville, nbSalles). Il faut mettre jour nbSalles quand une salle est ajoute ou supprime dun cinma. On peut considrer que cela arrive rarement, et que la redondance est donc sans grand danger. ajout du nombre de rles tenus dans la table Artiste. Artiste (idArtiste, nom, prnom, anneNaissance, nbRles) Il faut mettre jour nbRles quand un artiste obtient un nouveau rle. Cela arrive frquemment, et le risque induit par la redondance est alors important. Lintroduction de redondances prsente principalement le danger dintroduire des incohrences dans la base. On peut utiliser le mcanisme des triggers pour effectuer automatiquement la rpercussion de la modication dune donne sur ses autres versions prsentes dans la base.
2.3 Le langage de dnition de donnes SQL2

Ce chapitre prsente le langage de dnition de donnes (LDD) qui permet de spcier le schma dune base de donnes relationnelle. Ce langage correspond une partie de la norme SQL (structured query language), lautre partie tant relative la manipulation des donnes (LMD). La dnition dun schma logique comprend essentiellement deux parties : dune part la description des tables et de leur contenu, dautre part les contraintes qui portent sur les donnes de la base. La spcication des contraintes est souvent place au second plan bien quelle soit en fait trs importante : elle permet dassurer, au niveau de la base des contrles sur lintgrit des donns qui simposent toutes les applications accdant cette base. Un dernier aspect de la dnition dun schma, rapidement survol ici, est la description de la reprsentation physique. Il existe plusieurs versions de SQL. Le plus ancien standard date de 1989. Il a t rvis de manire importante en 1992 : la norme rsultant de cette rvision est SQL-92 ou SQL2. Une extension (SQL3) comprenant lintroduction de caractristiques orientes-objet est en cours de discussion depuis trs longtemps, et certains systmes ont dj anticip en proposant de nouvelles fonctionnalits. Le matriel prsent dans ce cours est essentiellement SQL2, sauf pour quelques nouveauts explicitement indiques.

Type INTEGER SMALLINT BIGINT FLOAT DOUBLE PRECISION REAL NUMERIC (M, D) DECIMAL (M, D) CHAR(M ) VARCHAR(M ) BIT VARYING DATE TIME DATETIME YEAR Description Type des entiers relatifs Idem. Idem. Flottants simple prcision Flottants double prcision Synonyme de FLOAT Numrique avec prcision xe. Idem. Chanes de longueur xe Chanes de longueur variable Chanes doctets Date (jour, mois, an) Horaire (heure, minutes, secondes) Date et heure Anne TAB . 2.1 Types SQL ANSI Taille 4 octets 2 octets 8 octets 4 octets 8 octets 4 octets M octets M octets M octets L+1 avec L M Longueur de chane. env. 4 octets env. 4 octets 8 octets 2 octets
43
la
2.3.1 Types SQL

La norme SQL ANSI propose un ensemble de types qui sont donns dans le tableau 2.1. Ce tableau prsente galement la taille, en octets, des instances de chaque type, cette taille ntant ici qu titre indicatif car elle peut varier selon les systmes. Types numriques exacts La norme SQL ANSI distingue deux catgories dattributs numriques : les numriques exacts, et les numriques ottants. Les types de la premire catgorie (essentiellement INTEGER et DECIMAL) permettent de spcier la prcision souhaite pour un attribut numrique, et donc de reprsenter une valeur exacte. Les numriques ottants correspondent aux types couramment utiliss en programmation (FLOAT, DOUBLE) et ne reprsentent une valeur quavec une prcision limite. Le type INTEGER permet de stocker des entiers, sur 4 octets en gnral, mais la taille du stockage nest pas spcie par la norme. Il existe deux variantes du type INTEGER : SMALLINT et BIGINT. Ces types diffrent par la taille utilise pour le stockage : voir le tableau 2.1. Le type DECIMAL (M, D) correspond un numrique de taille maximale M, avec un nombre de dcimales x D. Le type NUMERIC est un synonyme pour DECIMAL. Ces types sont surtout utiles pour manipuler des valeurs dont la prcision est connue, comme les valeurs montaires. An de prserver cette prcision, les instances de ces types sont stockes comme des chanes de caractres. Types numriques ottants Ces types sappuient sur la reprsentation des numriques ottants propre la machine, en simple ou double prcision. Leur utilisation est donc analogue celle que lon peut en faire dans un langage de programmation comme le C. 1. Le type FLOAT correspond aux ottants en simple prcision. 2. Le type DOUBLE PRECISION correspond aux ottants en double prcision. Le raccourci DOUBLE est accept. 3. Le type REAL est un synonyme pour DOUBLE.

Caractres et chanes de caractres
44
Les deux types principaux de la norme ANSI, disponibles dans la plupart des SGBD relationnels, sont CHAR et VARCHAR. Ces deux types permettent de stocker des chanes de caractres dune taille maximale xe par le paramtre M. Les syntaxes sont identiques. Pour le premier, CHAR(M ), et pour le second VARCHAR(M ). La diffrence essentielle entre les deux types est quune valeur CHAR a une taille xe, et se trouve donc complte avec des blancs si sa taille est infrieure M. En revanche une valeur VARCHAR a une taille variable et est tronque aprs le dernier caractre non blanc. Quand on veut stocker des chanes de caractres trs longues (des textes, voire des livres), le type VARCHAR ne suft plus. La norme SQL propose un type BIT VARYING qui correspond de trs longues chanes de caractres. Souvent les systmes proposent des variantes de ce type sous le nom BLOB (pour Binary Long Object) ou LONG. Dates Un attribut de type DATE stocke les informations jour, mois et anne (sur 4 chiffres). La reprsentation interne nest pas spcie par la norme. Tous les systmes proposent de nombreuses oprations de conversion (non normalises) qui permettent dobtenir un format dafchage quelconque. Un attribut de type TIME stocke les informations heure , minute et seconde . Lafchage se fait par dfaut au format HH:MM:SS. Le type DATETIME permet de combiner une date et un horaire, lafchage se faisant au format AAAA-MM-JJ HH:MM:SS.
2.3.2 Cration des tables

La commande principale est CREATE TABLE. Voici la commande de cration de la table Internaute. CREATE TABLE Internaute (email VARCHAR (50) NOT NULL, nom VARCHAR (20) NOT NULL, prenom VARCHAR (20), motDePasse VARCHAR (60) NOT NULL, anneeNaiss DECIMAL (4)) La syntaxe se comprend aisment. La seule difcult est de choisir correctement le type de chaque attribut. Le NOT NULL dans la cration de table Internaute indique que lattribut correspondant doit toujours avoir une valeur. Il sagit dune diffrence importante entre la pratique et la thorie : on admet que certains attributs peuvent ne pas avoir de valeur, ce qui est trs diffrent dune chane vide ou de 0. Quand on parle de valeur NULL en SQL2, il sagit en fait dune absence de valeur. En consquence : 1. on ne peut pas faire dopration incluant un NULL ; 2. on ne peut pas faire de comparaison avec un NULL. Loption NOT NULL oblige toujours indiquer une valeur. Loption suivante permet ainsi de garantir que tout internaute a un mot de passe. motDePasse VARCHAR(60) NOT NULL

Le SGBD rejettera alors toute tentative dinsrer une ligne dans Internaute sans donner de mot de passe. Si les valeurs NULL sont autorises, il faudra en tenir compte quand on interroge la base. Cela peut compliquer les choses, voire donner des rsultats surprenants : il est prfrable de forcer les attributs important avoir une valeur. Une autre manire de forcer un attribut toujours prendre une valeur est de spcier une valeur par dfaut avec loption DEFAULT. CREATE TABLE Cinma (nom VARCHAR (50) NOT NULL, adresse VARCHAR (50) DEFAULT Inconnue) Quand on insrera une ligne dans la table Cinma sans indiquer dadresse, le systme affectera automatiquement la valeur Inconnu cet attribut. En gnral on utilise comme valeur par dfaut une constante, sauf pour quelques variables fournies par le systme (par exemple SYSDATE qui peut indiquer la date du jour).
45
2.3.3 Contraintes
La cration dune table telle quon la vue prcdemment est extrmement sommaire car elle nindique que le contenu de la table sans spcier les contraintes que doit respecter ce contenu. Or il y a toujours des contraintes et il est indispensable de les inclure dans le schma pour assurer (dans la mesure du possible) lintgrit de la base. Voici les rgles (ou contraintes dintgrit) que lon peut demander au systme de garantir : 1. Un attribut doit toujours avoir une valeur. Cest la contrainte NOT NULL vue prcdemment. 2. Un attribut (ou un ensemble dattributs) constitue(nt) la cl de la relation. 3. Un attribut dans une table est lie la cl primaire dune autre table (intgrit rfrentielle). 4. La valeur dun attribut doit tre unique au sein de la relation. 5. Enn toute rgle sappliquant la valeur dun attribut (min et max par exemple). Les contraintes sur les cls doivent tre systmatiquement spcies. La dernire (clause CHECK) sappuie en grande partie sur la connaissance du langage dinterrogation de SQL et sera vue ultrieurement. Cls dune table Une cl est un attribut (ou un ensemble dattributs) qui identie(nt) de manire unique un tuple dune relation. Il peut y avoir plusieurs cls mais lune dentre elles doit tre choisie comme cl primaire. Ce choix est important : la cl primaire est la cl utilise pour rfrencer une ligne et une seule partir dautres tables. Il est donc assez dlicat de la remettre en cause aprs coup. En revanche les cls secondaires peuvent tre cres ou supprimes beaucoup plus facilement. La cl primaire est spcie avec loption PRIMARY KEY. CREATE TABLE Internaute (email VARCHAR (50) NOT NULL, nom VARCHAR (20) NOT NULL, prenom VARCHAR (20), motDePasse VARCHAR (60) NOT NULL, anneeNaiss INTEGER, PRIMARY KEY (email)) Il devrait toujours y avoir une PRIMARY KEY dans une table pour ne pas risquer dinsrer involontairement deux lignes strictement identiques. Une cl peut tre constitue de plusieurs attributs : CREATE TABLE Notation (idFilm INTEGER NOT NULL, email VARCHAR (50) NOT NULL, note INTEGER DEFAULT 0, PRIMARY KEY (titre, email)) Tous les attributs gurant dans une cl doivent tre dclars NOT NULL. Cela na pas vraiment de sens en effet didentier des lignes par des valeurs absentes. On peut galement spcier que la valeur dun attribut est unique pour lensemble de la colonne. Cela permet dindiquer des cls secondaires. On peut par exemple indiquer que deux artistes ne peuvent avoir les mmes nom et prnom avec loption UNIQUE. CREATE TABLE Artiste(id INTEGER NOT NULL, nom VARCHAR (30) NOT NULL, prenom VARCHAR (30) NOT NULL, anneeNaiss INTEGER, PRIMARY KEY (id), UNIQUE (nom, prenom));
46
Il est facile de supprimer cette contrainte de cl secondaire par la suite. Ce serait beaucoup plus difcile si on avait utilis la paire (nom, prenom) comme cl primaire puisquelle serait alors utilise pour rfrencer un artiste dans dautres tables. Voici un autre exemple dutilisation dune cl secondaire : on indique ci-dessous quon ne peut pas trouver deux cinmas la mme adresse. Ce deuxime exemple montre que lon peut placer une contrainte comme UNIQUE sur la ligne de lattribut auquel elle se rapporte. Ce nest bien entendu possible que quand cette contrainte ne concerne quun seul attribut. CREATE TABLE Cinema (nom VARCHAR (30) NOT NULL, adresse VARCHAR(50) UNIQUE, PRIMARY KEY (nomCinema)) La clause UNIQUE ne sapplique pas aux valeurs NULL : il peut y avoir plusieurs cinmas dadresse inconnue. En revanche le nom du cinma est obligatoire (clause NOT NULL) et il est unique (clause PRIMARY KEY). Cls trangres La norme SQL ANSI permet dindiquer quelles sont les cls trangres dans une table, autrement dit, quels sont les attributs qui font rfrence une ligne dans une autre table. On peut spcier les cls trangres avec loption FOREIGN KEY. CREATE TABLE Film (idFilm INTEGER NOT NULL, titre VARCHAR (50) NOT NULL, annee INTEGER NOT NULL, idMES INTEGER, codePays INTEGER, PRIMARY KEY (idFilm), FOREIGN KEY (idMES) REFERENCES Artiste, FOREIGN KEY (codePays) REFERENCES Pays); La commande FOREIGN KEY (idMES) REFERENCES Artiste indique que idMES rfrence la cl primaire de la table Artiste. Le SGBD vriera alors, pour toute modication pouvant affecter le lien entre les deux tables, que la valeur de idMES correspond bien une ligne de Artiste. Ces modications sont : 1. linsertion dans Film avec une valeur inconnue pour idMES ; 2. la destruction dun artiste ; 3. la modication de id dans Artiste ou de idMES dans Film. En dautres termes le lien entre Film et Artiste est toujours valide. Cette contrainte est importante pour garantir quil ny a pas de fausse rfrence dans la base, par exemple quun lm ne fait pas rfrence un artiste qui nexiste pas. Il est beaucoup plus confortable dcrire une application par la suite quand on sait que les informations sont bien l o elles doivent tre. Il faut noter que lattribut idMES nest pas dclar NOT NULL, ce qui signie que lon sautorise ne pas connatre le metteur en scne dun lm. Quand un attribut est NULL, la contrainte dintgrit rfrentielle ne sapplique pas. Que se passe-t-il quand la violation dune contrainte dintgrit est dtecte par le systme ? Par dfaut, la mise jour est rejete, mais il est possible de demander la rpercussion de cette mise jour de manire ce que la contrainte soit respecte. Les vnements que lon peut rpercuter sont la modication ou la destruction de la ligne rfrence, et on les dsigne par ON UPDATE et ON DELETE respectivement. La rpercussion elle-mme consiste soit mettre la cl trangre NULL (option SET NULL), soit appliquer la mme opration aux lignes de lentit composante (option CASCADE).
47
Voici comment on indique que la destruction dun metteur en scne dclenche la mise NULL de la cl trangre idMES pour tous les lms quil a ralis. CREATE TABLE Film (titre VARCHAR (50) NOT NULL, annee INTEGER NOT NULL, idMES INTEGER, codePays INTEGER, PRIMARY KEY (titre), FOREIGN KEY (idMES) REFERENCES Artiste ON DELETE SET NULL, FOREIGN KEY (codePays) REFERENCES Pays); Dans le cas dune entit faible, on dcide en gnral de dtruire le composant quand on dtruit le compos. Par exemple, quand on dtruit un cinma, on veut galement dtruire les salles ; quand on modie la cl dun cinma, on veut rpercuter la modication sur ses salles. CREATE TABLE Salle (nomCinema VARCHAR (30) NOT NULL, no INTEGER NOT NULL, capacite INTEGER, PRIMAR KEY (nomCinema, no), FOREIGN KEY (nomCinema) REFERENCES Cinema ON DELETE CASCADE ON UPDATE CASCADE ) Il est important de noter que nomCinema fait partie de la cl et ne peut donc pas tre NULL. On ne pourrait donc pas spcier ici ON DELETE SET NULL. La spcication des actions ON DELETE et ON UPDATE simplie considrablement la gestion de la base par la suite : on na plus par exemple se soucier de dtruire les salles quand on dtruit un cinma. numration des valeurs possibles avec CHECK La norme SQL ANSI comprend une option CHECK (condition) pour exprimer des contraintes portant soit sur un attribut, soit sur une ligne. La condition elle-mme peut tre toute expression suivant la clause WHERE dans une requte SQL. Les contraintes les plus courantes sont celles consistant restreindre un attribut un ensemble de valeurs, comme expliqu ci-dessous. On peut trouver des contraintes arbitrairement complexes, faisant rfrence dautres relations. Nous reviendrons sur cet aspect aprs avoir tudi le langage dinterrogation SQL. Voici un exemple simple qui restreint les valeurs possibles des attributs annee et genre dans la table Film. CREATE TABLE Film (titre VARCHAR (50) NOT NULL, annee INTEGER CHECK (annee BETWEEN 1890 AND 2000) NOT NULL, genre VARCHAR (10) CHECK (genre IN (Histoire,Western,Drame)), idMES INTEGER, codePays INTEGER, PRIMARY KEY (titre), FOREIGN KEY (idMES) REFERENCES Artiste, FOREIGN KEY (codePays) REFERENCES Pays); Au moment dune insertion dans la table Film, ou dune modication de lattribut annee ou genre=, le SGBD vrie que la valeur insre dans genre appartient lensemble numr dni par la clause CHECK. Une autre manire de dnir, dans la base, lensemble des valeurs autorises pour un attribut en dautres termes, une codication impose consiste placer ces valeurs dans une table et la lier lattribut par une contrainte de cl trangre. Cest ce que nous pouvons faire par exemple pour la table Pays. CREATE TABLE Pays (code VARCHAR (4) DEFAULT 0 NOT NULL,

nom VARCHAR (30) NOT NULL, langue VARCHAR (30) NOT NULL, PRIMARY KEY (code)) INSERT INSERT INSERT INSERT INSERT ... INTO INTO INTO INTO INTO Pays Pays Pays Pays Pays VALUES VALUES VALUES VALUES VALUES (0, (1, (2, (3, (4, Inconnu, Inconnue); France, Franais); USA, Anglais); Allemagne, Allemand); Angleterre, Anglais);
48
Si on ne fait pas de vrication automatique, soit avec CHECK, soit avec la commande FOREIGN KEY, il faut faire cette vrication dans lapplication, ce qui est plus lourd grer.
2.3.4 Modication du schma

La cration dun schma nest quune premire tape dans la vie dune base de donnes. On est toujours amen par la suite crer de nouvelles tables, ajouter des attributs ou en modier la dnition. La forme gnrale de la commande permettant de modier une table est : ALTER TABLE nomTable ACTION description o ACTION peut tre principalement ADD, MODIFY, DROP ou RENAME, et description est la commande de modication associe ACTION. La modication dune table peut poser des problmes si elle est incompatible avec le contenu existant. Par exemple passer un attribut NOT NULL implique que cet attribut a dj des valeurs pour toutes les lignes de la table. Modication des attributs Voici quelques exemples dajout et de modication dattributs. On peut ajouter un attribut region la table Internaute avec la commande : ALTER TABLE Internaute ADD region VARCHAR(10); Sil existe dj des donnes dans la table, la valeur sera NULL ou la valeur par dfaut. La taille de region tant certainement insufsante, on peut lagrandir avec MODIFY, et la dclarer NOT NULL par la mme occasion : ALTER TABLE Internaute MODIFY region VARCHAR(30) NOT NULL; Il est galement possible de diminuer la taille dune colonne, avec le risque dune perte dinformation pour les donnes existantes. On peut mme changer son type, pour passer par exemple de VARCHAR INTEGER, avec un rsultat imprvisible. Loption ALTER TABLE permet dajouter une valeur par dfaut. ALTER TABLE Internaute ALTER region SET DEFAULT PACA; Enn on peut dtruire un attribut avec DROP. ALTER TABLE Internaute DROP region;

Cration dindex
49
Pour complter le schma dune table, on peut dnir des index. Un index offre un chemin daccs aux lignes dune table qui est considrablement plus rapide que le balayage de cette table du moins quand le nombre de lignes est trs lev. Les SGBDL crent systmatiquement un index sur la cl primaire de chaque table. Il y a deux raisons cela ; 1. lindex permet de vrier rapidement, au moment dune insertion, que la cl nexiste pas dj ; 2. beaucoup de requtes SQL, notamment celles qui impliquent plusieurs tables (jointures), se basent sur les cls des tables pour reconstruire les liens. Lindex peut alors tre utilis pour amliorer les temps de rponse. Un index est galement cr pour chaque clause UNIQUE utilise dans la cration de la table. On peut de plus crer dautres index, sur un ou plusieurs attributs, si lapplication utilise des critres de recherche autres que les cls primaire ou secondaires. La commande pour crer un index est la suivante : CREATE [UNIQUE] INDEX nomIndex ON nomTable (attribut1 [, ...]) La clause UNIQUE indique quon ne peut pas trouver deux fois la mme cl. La commande ci-dessous cre un index de nom idxNom sur les attributs nom et prenom de la table Artiste. Cet index a donc une fonction quivalente la clause UNIQUE dj utilise dans la cration de la table. CREATE UNIQUE INDEX idxNom ON Artiste (nom, prenom); On peut crer un index, cette fois non unique, sur lattribut genre de la table Film. CREATE INDEX idxGenre ON Film (genre); Cet index permettra dexcuter trs rapidement des requtes SQL ayant comme critre de recherche le genre dun lm. SELECT * FROM Film WHERE genre = Western Cela dit il ne faut pas crer des index tort et travers, car ils ont un impact ngatif sur les commandes dinsertion et de destruction. chaque fois, il faut en effet mettre jour tous les index portant sur la table, ce qui reprsente un cot certain.
2.4 Exercices
Exercice 7 La relation de la gure 2.4 est-elle conforme la dnition ? Si non, citez les anomalies. titre Cyrano Les oiseaux Titanic Les oiseaux anne 1992 1963 1963 metteurEnScne Rappeneau Hitchcock Cameron Hitchcock acteur Depardieu, Perez Taylor DiCaprio Taylor
F IG . 2.4 Une relation
Exercice 8 Donnez le schma relationnel de la base de donnes Centre mdical dcrite par un schma E/A dans le prcdent TD. Pour chaque table, il faut indiquer prcisment, laide de la syntaxe vue en cours : La cl primaire.

2.4. EXERCICES
Les cls trangres.
50
Exercice 9 Mme exercice que prcdemment, pour lapplication Discothque. Exercice 10 Mme exercice, portant sur les schmas SOCIETE, DIRECTEUR, ORDINATEUR, UTILISATEUR, ORDINATEUR, DISQUE DUR que vous avez tudis dans la sance consacre au schma E/A. Cette fois, il est demand de spcier, pour chaque cl trangre, la stratgie en cas de mise--jour ou de destruction de la ligne rfrence (clauses ON UPDATE et ON DELETE vues en cours). Exercice 11 Mme exercice, pour le schma Cours. Donner les spcications compltes (cls primaires et trangres, NOT NULL, clauses UNIQUE, etc). Exercice 12 Des diteurs se runissent pour crer une Base de Donnes sur leurs publications scientiques. Dans de telles publications, plusieurs auteurs se regroupent pour crire un livre en se rpartissant les chapitres rdiger. Aprs discussion, voici le schma obtenu : 1. Livre (titreLivre, anne, diteur, chiffreAffaire) 2. Chapitre (titreLivre, titreChapitre, nbPages) 3. Auteur (nom, prnom, anneNaissance) 4. Redaction (nomAuteur, titreLivre, titreChapitre) Les cls primaires sont en gras, mais les cls trangres ne sont pas signales. 1. Donnez le schma Entit/Association correspondant au schma relationnel. 2. Donnez les ordres CREATE TABLE pour le schma, en spciant soigneusement cls primaires et trangres avec la syntaxe SQL2. Le type des donnes est secondaire: choisissez ce qui vous semble logique. 3. Sur quelles cls trangres devrait-on mettre loption ON DELETE CASCADE ? Exercice 13 On trouve dans un SGBD relationnel les relations ci-dessous. Les cls primaires sont en gras, les cls trangres ne sont pas signales. Immeuble (nom, adresse, nbEtages, anneConstruction, nomGrant) Appart (nomImm, noApp, type, supercie, tage) Personne (nom, prenom, age, codeProfession) Occupant (nomImm, noApp, nomOccupant, anneArrive) Proprit (nomImm, nomPropritaire, quotePart) TypeAppart (code, libell) Profession (code, libell) Identier les cls trangres dans chaque relation, et reconstruire le schma E/A.
CHAPITRE 3. LALGBRE RELATIONNELLE
51
Chapitre 3
Lalgbre relationnelle
Sommaire
3.1 Les oprateurs de lalgbre relationnelle 3.1.1 La slection, . . . . . . . . . . . 3.1.2 La projection, . . . . . . . . . . 3.1.3 Le produit cartsien, . . . . . . 3.1.4 Lunion, . . . . . . . . . . . . . 3.1.5 La diffrence, . . . . . . . . . . . . . . . . . . . . . . 3.1.6 Jointure, Expression de requtes avec lalgbre . . 3.2.1 Slection gnralise . . . . . . . 3.2.2 Requtes conjonctives . . . . . . . 3.2.3 Requtes avec et . . . . . . . Exercices . . . . . . . . . . . . . . . . .

3.2
3.3
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
52 53 53 54 55 56 56 57 57 58 59 60
Le premier langage tudi dans ce cours est lalgbre relationnelle. Il consiste en un ensemble doprations qui permettent de manipuler des relations, considres comme des ensemble de tuples : on peut ainsi faire lunion ou la diffrence de deux relations, slectionner une partie de la relation, effectuer 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. Dans tout ce chapitre on va prendre lexemple de la (petite) base de donnes dun organisme de voyage. Cet organisme propose des sjours (sportifs, culturels, etc) se droulant dans des stations de vacances. Chaque station propose un ensemble dactivts (ski, voile, tourisme). Enn on maintient une liste des clients (avec le solde de leur compte !) et des sjours auxquels ils ont particip avec leurs dates de dbut et de n. Station (nomStation, capacit, lieu, rgion, tarif) Activite (nomStation, libell, prix) Client (id, nom, prnom, ville, rgion, solde) Sjour (idClient, station, dbut, nbPlaces)
3.1. LES OPRATEURS DE LALGBRE RELATIONNELLE

nomStation Venusa Farniente Santalba Passac capacit 350 200 150 400 lieu rgion Guadeloupe Antilles Seychelles Ocan Indien Martinique Antilles Alpes Europe La table Station Prix 150 120 130 200 20 50 tarif 1200 1500 2000 1000
52
NomStation Libell Venusa Voile Venusa Plonge Farniente Plonge Passac Ski Passac Piscine Santalba Kayac La table Activit
F IG . 3.1 Les stations et leurs activits id 10 20 30 nom Fogg Pascal Kerouac idClient 10 30 20 30 30 20 30 10 prnom ville Phileas Londres Blaise Paris Jack New York La table Client rgion Europe Europe Amrique nbPlaces 2 5 4 3 3 6 5 3 solde 12465 6763 9812
station dbut Passac 1998-07-01 Santalba 1996-08-14 Santalba 1998-08-03 Passac 1998-08-15 Venusa 1998-08-03 Venusa 1998-08-03 Farniente 1999-06-24 Farniente 1998-09-05 La table Sjour
F IG . 3.2 Les clients et leurs sjours
3.1 Les oprateurs de lalgbre relationnelle

Lalgbre se compose dun ensemble doprateurs, parmi lesquels 5 sont ncessaires et sufsants et permettent de dnir les autres par composition. Ce sont : 1. La slection, dnote ; 2. La projection, dnote ;

3. Le produit cartsien, dnot
4. Lunion,
5. La diffrence, . Les deux premiers sont des oprateurs unaires (ils prennent en entre une seule relation) et les autres sont des oprateurs binaires. A partir de ces oprateurs il est possible den dnir dautres, et notamment la jointure, , qui est la composition dun produit cartsien et dune slection. Ces oprateurs sont maintenant prsents tour tour.
53
La slection sapplique une relation, slection, . Ce critre peut tre :
La comparaison entre un attribut de la relation, appartient . La comparaison entre deux attributs que prcdemment. et
, et une constante . Cette comparaison scrit
, o
, qui scrit
avec les mmes oprateurs de comparaison
Premier exemple : exprimer la requte qui donne toutes les stations aux Antilles.
On obtient donc le rsultat : nomStation Venusa Santalba
capacit 350 150
lieu Guadeloupe Martinique
rgion Antilles Antilles
tarif 1200 2000
La slection a pour effet de supprimer des lignes, mais chaque ligne garde lensemble de ses attributs.
La projection sapplique une relation , et ne garde que les attributs contrairement la slection, on ne supprime pas des lignes mais des colonnes. Exemple : donner le nom des stations, et leur rgion.
On obtient le rsultat suivant, aprs suppression des colonnes capacit, lieu et tarif : nomStation Venusa Farniente Santalba Passac rgion Antilles Ocan Indien Antilles Europe
En principe le nombre de lignes dans le rsultat est le mme que dans la relation initiale. Il y a cependant une petite subtilit : comme le rsultat est une relation, il ne peut pas y avoir deux lignes identiques (il ny a pas deux fois le mme lment dans un ensemble). Il peut arriver quaprs une projection, deux lignes qui taient distinctes initialement se retrouvent identiques, justement parce ce que lattribut qui permettait de les distinguer a t supprim. Dans ce cas on ne conserve quune seule des deux (ou plus) lignes identiques. Exemple : on souhaite connatre toutes les rgions o il y a des stations. On exprime cette requte par :
et on obtient :
rgion Antilles Ocan Indien Europe La ligne Antilles tait prsente deux fois dans la relation Station, et napparat plus quen un seul exemplaire dans le rsultat.
!""
) I
$ G H$ G FE# 4 #
) I
$ G
C B D(
@ 8884 5 4 2 " 4 99976 3
3.1.2 La projection,
. Donc,

$$ # ! ! &% $ " $ ) ' 0 (
%
3.1.1 La slection,
, et extrait de cette relation les tuples qui satisfont un critre de
54
Le premier oprateur binaire, et le plus important, est le produit cartsien, . Le produit cartsien entre deux relations et se note , et permet de crer une nouvelle relation o chaque tuple de est associ chaque tuple de . Voici deux relations et : C D A B c d a b u v x y x y Et voici le rsultat de : A a a a x x x B b b b y y y

C c u x c u x
D d v y d v y
Le nombre de lignes dans le rsultat est exactement ( dnote le nombre de lignes dans la relation ). En lui-mme, le produit cartsien ne prsente pas un grand intrt puisquil associe aveuglment chaque ligne de chaque ligne de . Il ne prend vraiment son sens quassoci lopration de slection, ce qui permet dexprimer des jointures, opration fondamentale qui sera dtaille plus loin. Conits de noms dattributs Quand les schmas des relations et sont compltement distincts, il ny a pas dambiguit sur la provenance des colonnes dans le rsultat. Par exemple on sait que les valeurs de la colonne dans viennent de la relation . Il peut arriver (il arrive de fait trs souvent) que les deux relations aient des attributs qui ont le mme nom. On doit alors se donner les moyens de distinguer lorigine des colonnes dans la table rsultat en donnant un nom distinct chaque attribut. Voici par exemple une table qui a les mmes noms dattributs que . Le schma du rsultat du produit cartsien a pour schma et prsente donc des ambiguits, avec les colonnes et en double. A B m n o p La table
La premire solution pour lever lambiguit est de prxer un attribut par le nom de la table do il provient. Le rsultat de devient alors :
R.A a a x x
R.B b b y y
T.A m n m n
T.B n p n p
Au lieu dutiliser le nom de la relation en entier, on peut sautoriser tout synonyme qui permet de lever lambiguit. Par exemple, dans le produit cartsien Station Activite, on peut utiliser S comme prxe pour les attributs venant de Station, et A pour ceux venant dActivite. Le rsultat peut alors tre reprsent comme sur la Fig. 3.3. On lve lambiguit sur les attributs nomStation qui apparaissent deux fois. Ce nest pas ncessaire pour les autres attributs. Renommage
3.1.3 Le produit cartsien,

)


S.nomStation Venusa Venusa Venusa Venusa Venusa Venusa Farniente Farniente Farniente Farniente Farniente Farniente Santalba Santalba Santalba Santalba Santalba Santalba Passac Passac Passac Passac Passac Passac cap. 350 350 350 350 350 350 200 200 200 200 200 200 150 150 150 150 150 150 400 400 400 400 400 400 lieu Guadeloupe Guadeloupe Guadeloupe Guadeloupe Guadeloupe Guadeloupe Seychelles Seychelles Seychelles Seychelles Seychelles Seychelles Martinique Martinique Martinique Martinique Martinique Martinique Alpes Alpes Alpes Alpes Alpes Alpes rgion Antilles Antilles Antilles Antilles Antilles Antilles Ocan Indien Ocan Indien Ocan Indien Ocan Indien Ocan Indien Ocan Indien Antilles Antilles Antilles Antilles Antilles Antilles Europe Europe Europe Europe Europe Europe tarif 1200 1200 1200 1200 1200 1200 1500 1500 1500 1500 1500 1500 2000 2000 2000 2000 2000 2000 1000 1000 1000 1000 1000 1000 A.nomStation Venusa Venusa Farniente Passac Passac Santalba Venusa Venusa Farniente Passac Passac Santalba Venusa Venusa Farniente Passac Passac Santalba Venusa Venusa Farniente Passac Passac Santalba libelle Voile Plonge Plonge Ski Piscine Kayac Voile Plonge Plonge Ski Piscine Kayac Voile Plonge Plonge Ski Piscine Kayac Voile Plonge Plonge Ski Piscine Kayac prix 150 120 130 200 20 50 150 120 130 200 20 50 150 120 130 200 20 50 150 120 130 200 20 50
55
Il existe une deuxime possibilit pour rsoudre les conits de noms : le renommage. Il sagit dun oprateur particulier, dnot , qui permet de renommer un ou plusieurs attributs dune relation. Lexpression permet ainsi de renommer en et en dans la relation . Le produit cartsien
ne prsente alors plus dambiguits. Le renommage est une solution trs gnrale, mais asez lourde utiliser Il est tout fait possible de faire le produit cartsien dune relation avec elle-mme. Dans ce cas le renommage o lutilisation dun prxe distinctif est impratif. Voici par exemple le rsultat de , dans lequel on prxe par et respectivement les attributs venant de chacune des oprandes. R1.A a a x x R1.B b b y y R2.A a x a x R2.B b y b y
Il existe deux autres oprateurs binaires, qui sont la fois plus simples et moins frquemment utiliss. Le premier est lunion. Lexpression cre une relation comprenant tous les tuples existant dans lune ou lautre des relations et . Il existe une condition imprative : les deux relations doivent avoir le mme schma, cest--dire mme nombre dattributs, mmes noms et mmes types. Lunion des relations et donnes en exemple ci-dessus est donc interdite (on ne saurait pas comment nommer les attributs dans le rsultat). En revanche, en posant , il devient possible de
I )
4
)
#
3.1.4 Lunion,
)
4 "
4 3
F IG . 3.3 Produit cartsien Station
Activit, avec leve des ambiguts

S.nomStation Venusa Venusa Farniente Santalba Passac Passac cap. 350 350 200 150 400 400 lieu Guadeloupe Guadeloupe Seychelles Martinique Alpes Alpes rgion Antilles Antilles Ocan Indien Antilles Europe Europe

56 tarif 1200 1200 1500 2000 1000 1000 A.nomStation Venusa Venusa Farniente Santalba Passac Passac libelle Voile Plonge Plonge Kayac Ski Piscine prix 150 120 130 50 200 20 et

Comme pour la projection, il faut penser viter les doublons. Donc le tuple (x,y) qui existe la fois dans dans ne gure quune seule fois dans le rsultat.
3.1.5 La diffrence,
A a
B b
La diffrence est le seul oprateur qui permet dexprimer des requtes comportant une ngation (on veut rejeter quelque chose, on ne veut pas des lignes ayant telle proprit). Il sagit dune fonctionnalit importante et difcile manier : elle sera dtaille plus loin.
3.1.6 Jointure,
Toutes les requtes exprimables avec lalgbre relationnelle peuvent se construire avec les 5 oprateurs prsents ci-dessus. En principe, on pourrait donc sen contenter. En pratique, il existe dautres oprations, trs couramment utilises, qui peuvent se contruire par composition des oprations de base. La plus importante est la jointure. An de comprendre lintrt de cet oprateur, regardons nouveau la Fig. 3.3 qui reprsente le produit cartsien Station Activite. Le rsultat est norme et comprend manifestement un grand nombre de lignes qui ne nous intressent pas. Cela ne prsente pas beaucoup de sens de rapprocher des informations sur Santalba, aux Antilles et sur lactivit de ski Passac. Si, en revanche, on considre le produit cartsien comme un rsultat intermdiaire, on voit quil devient maintenant possible, avec une simple slection, de rapprocher les informations gnrales sur une station et la liste des activits de cette station. La slection est la suivante :
Et on obtient le rsultat de la Fig. 3.4. On a donc effectu une composition de deux oprations (un produit cartsien, une slection) an de rapprocher des informations rparties dans plusieurs tables, mais ayant des liens entre elles (toutes les informations dans un tuple du
Comme lunion, la diffrence sapplique deux relations qui ont le mme schma. Lexpression pour rsultat tous les tuples de qui ne sont pas dans . Voici la diffrence de et , les deux relations tant dnies comme prcdemment.
a alors
) I
$ G FE# #
C B D( $ 8 $ F# DB $ 8 C #E C
)
calculer
, avec le rsultat suivant : A a x c u B b y d v et
$ 7FE# #
C DB $ 8 $ G F# C B $ 8 C #E
F IG . 3.4 Une jointure
) 0
, composition de
)
)
57
rsultat sont relatives une seule station). Cette opration est une jointure, que lon peut directement, et simplement, noter : La jointure consiste donc rapprocher les lignes de deux relations pour lesquelles les valeurs dun (ou plusieurs) attributs sont identiques. De fait, dans 90% des cas, ces attributs communs sont (1) la cl primaire dune des relations et (2) la cl trangre dans lautre relation. Dans lexemple ci-dessus, cest le cas pour nomStation. La jointure permet alors de reconstruire lassociation entre Station et Activite. Une jointure peut simplement tre dnie comme tant quivalent . Le critre de rapprochement, , peut tre nimporte quelle opration de comparaison liant un attribut de un attribut de . En pratique, on emploie peu les ou qui sont difciles interprter, et on effectue des galits. Remarque : Si on nexprime pas de critre de rapprochement, la jointure est quivalente un produit cartsien. Il faut tre attentif aux ambiguits dans le nommage des attributs qui peut survenir dans la jointure au mme titre que dans le produit cartsien. Les solutions employer sont les mmes : on prxe par le nom de la relation ou par un synonyme clair, ou bien on renomme des attributs avant deffectuer la jointure.
3.2 Expression de requtes avec lalgbre

Cette section est consacre lexpression de requtes algbriques complexes impliquant plusieurs oprateurs. On utilise la composition des oprations, rendue possible par le fait que tout oprateur produit en sortie une relation sur laquelle on peut appliquer nouveau des oprateurs.
3.2.1 Slection gnralise

Regardons dabord comment on peut gnraliser les critres de slection de loprateur . Jusqu prsent on a vu comment slectionner des lignes satisfaisant un critre de slection, par exemple : les stations aux Antilles. Maintenant supposons que lon veuille retrouver les stations qui sont aux Antilles et dont la capacit est suprieure 200. On peut exprimer cette requte par une composition :
Ce qui revient pouvoir exprimer une slection avec une conjonction de critres. La requte prcdente est donc quivalente celle ci-dessous, o le dnote le et logique.
Donc la composition de plusieurs slections permet dexprimer une conjonction de critres de recherche. De mme la composition de la slection et de lunion permet dexprimer la disjonction. Voici la requte qui recherche les stations qui sont aux Antilles, ou dont la capacit est suprieure 200.
Ce qui permet de sautoriser la syntaxe suivante, o le dnote le ou logique.
Enn la diffrence permet dexprimer la ngation et dliminer des lignes. Par exemple, voici la requte qui slectionne les stations dont la capacit est suprieure 200 mais qui ne sont pas aux Antilles.
Cette requte est quivalente une slection o on sautorise loprateur :
# $ G FE#

$ ! &$ # $ " $ G ! ) 0 '
# ! $ $ $ ! $ G ) 0 '
$$ # ! ! &% $ " $ # E E ) I '
$ ! &$ # $ 3 $ G # E E ! ) 0 '
$ ! &$ # $ ! $ G # E E ) 0 '
$ ! &$ # $ 3$ G # E E ! ) 0 '
C B $ $ G F# D( #E C B

$
) I
) I
# E E
# E E
3.2. EXPRESSION DE REQUTES AVEC LALGBRE
58
En rsum, les oprateurs dunion et de diffrence permettent de dnir une slection o le critre est une expression boolenne quelconque. Attention cependant : si toute slection avec un ou peut sexprimer par une union, linverse nest pas vrai (exercice).
3.2.2 Requtes conjonctives

Les requtes dites conjonctives constituent lessentiel des requtes courantes. Intuitivement, il sagit de toutes les recherches qui sexpriment avec des et, par opposition celles qui impliquent des ou ou des not. Dans lalgbre, ces requtes sont toutes celles qui peuvent scrire avec seulement trois oprateurs : , , (et donc, indirectement, ). Les plus simples sont celles o on nutilise que et . En voici quelques exemples.
Des requtes lgrement plus complexes - et extrmement utiles - sont celles qui impliquent la jointure (le produit cartsien ne prsente dintrt que quand il est associ la slection). On doit utiliser la jointure ds que les attributs ncessaires pour valuer une requte sont rparties dans au moins deux tables. Ces attributs ncessaires peuvent tre : Soit des attributs qui gurent dans le rsultat ; Soit des attributs sur lesquels on exprime un critre de slection. Considrons par exemple la requte suivante : Donner le nom et la rgion des stations o lon pratique la voile. Une analyse trs simple suft pour constater que lon a besoin des attributs rgion qui apparat dans la relation Station, libelle qui apparat dans Activite, et nomStation qui apparat dans les deux relations. Donc il faut faire une jointure, de manire rapprocher les lignes de Station et de Activit. Il reste donc dterminer le (ou les) attribut(s) sur lesquels se fait ce rapprochement. Ici, comme dans la plupart des cas, la jointure permet de recalculer lassociation entre les relations Station et Activit. Elle seffectue donc sur lattribut nomStation qui permet de reprsenter cette association.
En pratique, la grande majorit des oprations de jointure seffectue sur des attributs qui sont cl primaire dans une relation, et cl secondaire dans lautre. Il ne sagit pas dune rgle absolue, mais elle rsulte du fait que la jointure permet le plus souvent de reconstituer le lien entre des informations qui sont naturellement associes (comme une station et ses activits, ou une station et ses clients), mais qui ont t rparties dans plusieurs relations au moment de la modlisation logique de la base. Cette reconstitution sappuie sur le mcanisme de cl trangre qui a t tudi dans le chapitre consacr la conception. Voici quelques autres exemples qui illustrent cet tat de fait : Nom des clients qui sont alls Passac :
Quelles rgions a visit le client 30 :
Nom des clients qui ont eu loccasion de faire de la voile :
! %$
! %$

! $ " &$ $
E ! # 0 ! E ' ' 3 " $ G FE# )
) I
$ ! &$ $
$ G FE# #
$ FE# #
C B $ $ G F# ' #E
$ 7FE# #
C DB $ $ 7F# ' #E
C DB $ $ G F# C B #E
C B

# $ $

I )
# $ $
# 0 $ $ )
$
3. Nom et prnom des clients europens
2. Nom des stations o lon pratique la voile.
C B D(
$ G
1. Nom des stations aux Antilles :
"

B ! ! " $ B $ 4 ( $ # C ! $ ! &$$ $ $ 7FE# DB $ ! # 0 ! ' &$$ # $ 3 $ G $ G FE# )
) I
$ H$ 7FE# 4 #
B (
C DB
B
59
La dernire requte comprend deux jointures, portant chaque fois sur des cls primaires et/ou trangres. Encore une fois ce sont les cls qui dnissent les liens entre les relations, et elle servent donc naturellement de support lexpression des requtes. Voici maintenant un exemple qui montre que cette rgle nest pas systmatique. On veut exprimer la requte qui recherche les noms des clients qui sont partis en vacances dans leur rgion, ainsi que le nom de cette rgion. Ici on a besoin des informations rparties dans les relations Station, Sejour et Client. Voici lexpression algbrique :
Les jointures avec la table Sejour se font sur les couples (cl primaire, cl trangre), mais on a en plus un critre de rapprochement relatif lattribut rgion de Client et de Station. Noter que dans la projection nale, on utilise la notation client.region pour viter toute ambiguit.
Pour nir, voici quelques exemples de requtes impliquant les deux oprateurs et . Leur utilisation est moins frquente, mais elle peut savrer absolument ncessaire puisque ni lun ni lautre ne peuvent sexprimer laide des trois oprateurs conjonctifs tudis prcdemment. En particulier, la diffrence permet dexprimer toutes les requtes o gure une ngation : on veut slectionner des donnes qui ne satisfont pas telle proprit, ou tous les untels sauf les x et les y, etc. Illlustration concrte sur la base de donnes avec la requte suivante : quelles sont les stations qui ne proposent pas de voile ?
Comme le suggre cet exemple, la dmarche gnrale pour construire une requte du type Tous les satisfont pas la proprit est la suivante : 1. Construire une premire requte qui slectionne tous les
2. Construire une deuxime requte
qui slectionne tous les
qui satisfont .
3. Finalement, faire
Les requtes et peuvent bien entendu tre arbitrairement complexes et mettre en oeuvre des jointures, des slections, etc. La seule contrainte est que le rsultat de et de comprenne le mme nombre dattributs. Voici quelques exemples complmentaires qui illustrent ce principe. Rgions o il y a des clients, mais pas de station.
Nom des stations qui nont pas reu de client amricain.
Id des clients qui ne sont pas alls aux Antilles.
La dernire requte construit lensemble des idClient pour les clients qui ne sont pas alls aux Antilles. Pour obtenir le nom de ces clients, il suft dajouter une jointure (exercice). Complment dun ensemble

!
# # ) $ 7FE# ' $ 7FE#
! %$
B " $ !
C DB
$
! $ 3 &$ $
$ $ #
) I
$ G
! $ $ $ 3 $ G # $ $ # ! ) 0 '
# $ FE#

$
C DB
# 0 $ G FE# ' )
) 0
$ 7FE# #
# $ $
) 0
C DB
$ G FE# #
3.2.3 Requtes avec
et
$ FE# #
C DB $ $ 7F# ' #E

# 0 $ $ G $ $ )

$ G $ $ 4 8#
C B D(
B
qui ne
3.3. EXERCICES
60
La diffrence peut tre employe pour calculer le complment dun ensemble. Prenons lexemple suivant : on veut les ids des clients et les stations o ils ne sont pas alls. En dautres termes, parmi toutes les associations Client/Station possibles, on veut justement celles qui ne sont pas reprsentes dans la base ! Cest un des rares cas o le produit cartsien seul est utile : il permet justement de constituer toutes les associations possibles. Il reste ensuite en soustraire celles qui sont dans la base avec loprateur .
Quantication universelle Enn la diffrence est ncessaire pour les requtes qui font appel la quantication universelle : celles o lon demande par exemple quune proprit soit toujours vraie. A priori, on ne voit pas pourquoi la diffrence peut tre utile dans de tels cas. Cela rsulte simplement de lquivalence suivante : une proprit est vraie pour tous les lments dun ensemble si et seulement si il nexiste pas un lment de cet ensemble pour lequel la proprit est fausse. En pratique, on se ramne toujours la seconde forme pour exprimer des requtes : donc on emploie toujours la ngation et la quantication existentielle la place de la quantication universelle. Par exemple : quelles sont les stations dont toutes les activits ont un prix suprieur 100 ? On lexprime galement par quelles sont stations pour lesquelles il nexiste pas dactivit avec un prix infrieur 100. Ce qui donne lexpression suivante :
Pour nir, voici une des requtes les plus complexes, la division. Lnonc (en franais) est simple, mais lexpression algbrique ne lest pas du tout. Lexemple est le suivant : on veut les ids des clients qui sont alls dans toutes les stations. Traduit avec ngation et quantication existentielle, cela donne : les ids des clients tels quil nexiste pas de station o ils ne soient pas alls. On constate une double ngation, ce qui donne lexpression algbrique suivante :
On rutilise lexpression donnant les clients et les stations o ils ne sont pas alls (voir plus haut) : on obtient un ensemble . Il reste prendre tous les clients, sauf ceux qui sont dans . Ce type de requte est rare (heureusement) mais illustre la capacit de lalgbre exprimer par de simples manipulations ensemblistes des oprations complexes.
3.3 Exercices
Exercice 14 La gure 3.5 donne une instance de la base Immeubles (le schma est lgrement simpli). Pour chacune des requtes suivantes, exprimez en franais sa signication, et donnez son rsultat.
B %B $ B B B
9.
8.
B B B B $ B ( $ B ( $
B $ ( # $ E
#
7.
B ( $ B B B B B
B # ( $ $ E # B( $ $ E
#
6.
$
" B $ " # $ $ E B $ "B $ $ G ' ' $ 4# ' 4 $ E $ E B $ " 4# ' $ E B $
B
5.
!

B
4.
(

B
3.
B
2.

B
$& $& $ &
1.

# 4# I $ 7FE# ' $ $ )

# $ FE#
# 4# 0 $ G FE# ' $ $ )
) I
$ FE# #
C DB
C DB
) 0
FE# $ $ 4 B B $$ E ! ' E E E " B ( $ $ E B B ! # ' $ 4 B B B B 4E
$ G FE# # $

C B

$ &
) 0
$ 7FE# #
C DB
61
Quelle est la diffrence entre les deux dernires requtes ? nomImm Koudalou Barabas adresse 3 Rue Blanche 2 Allee Nikos nomImm Koudalou Koudalou Koudalou Koudalou Barabas Barabas
ge profession nom Ross 51 Informaticien Alice 34 Cadre Rachel 23 Stagiaire William 52 Acteur Doug 34 Rentier La table Personne nomImm Koudalou Barabas Barabas Koudalou Koudalou noApp nomOcc anneeArrivee 1 Rachel 1992 1 Doug 1994 2 Ross 1994 51 William 1996 34 Alice 1993 La table Occupant
F IG . 3.5 Les immeubles et leurs occupants
Exercice 15 Exprimez les requtes suivantes, en algbre relationnelle. Pour chaque requte, donnez le rsultat sur la base Immeubles. 1. Nom des immeubles ayant strictement plus de 10 tages. 2. Nom des personnes ayant emmnag avant 1994. 3. Qui habite le Koudalou ? 4. Nom des informaticiens de plus de 25 ans. 5. Nom des immeubles ayant un appartement de plus de 150 m .
13.
nbEtages anneConstruction 15 1975 2 1973 La table Immeuble noApp supercie 1 150 34 50 51 200 52 50 1 250 2 250 La table Appart tage 14 15 2 5 1 2
12.
B ! ! " # $ E ( $ B B B B B ! !" #$ E B $ B ( $ B B B B B $ $ 4 B ( & $ 4 B B B
$ &
11.
nomGrant Doug Ross
B B B $ B ( $ B B $
%
B
#
10.
!$
E ! # E "" $
$
'
3.3. EXERCICES
6. Qui gre lappartement o habite Rachel ? 7. Dans quel immeuble habite un acteur ? 8. Qui habite un appartement de moins de 70 m ? 9. Nom des personnes qui habitent au dernier tage de leur immeuble. 10. Qui a emmnag au moins 20 ans aprs la construction de son immeuble ? 11. Profession du grant du Barabas ? 12. Couples de personnes ayant emmnag dans le mme immeuble la mme anne. 13. Age et profession des occupants de limmeuble gr par Ross ? 14. Qui habite, dans un immeuble de plus de 10 tages, un appartement de plus de 100 m ? 15. Couples de personnes habitant, dans le mme immeuble, un appartement de mme supercie. 16. Qui nhabite pas un appartement gr par Ross ? 17. Qui nhabite pas un appartement quil gre lui-mme ? 18. Quels sont les immeubles o personne na emmnag en 1996 ? 19. Quels sont les immeubles o tout le monde a emmnag en 1994 ? Exercice 16 1. Montrez que la requte 4 dans lexercice 14 peut sexprimer avec lunion.
62
3. Exprimez la dernire requte de lexercice 14 avec la diffrence, et sans
2. Inversement, donner une requte sur la base Immeuble qui peut sexprimer avec lunion, mais pas avec .
et
CHAPITRE 4. LE LANGAGE SQL
63
Chapitre 4
Le langage SQL
Sommaire
4.1 Requtes simples SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.4 4.4.1 4.4.2 4.4.3 4.5 4.5.1 4.5.2 4.5.3 4.6 Slections simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La clause WHERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Valeurs nulles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jointures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Union, intersection et diffrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conditions portant sur des relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sous-requtes correlles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctions dagrgation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La clause GROUP BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La clause HAVING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 64 66 67 68 68 69 70 70 72 72 72 73 74 74 74 74 75 75
Requtes sur plusieurs tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requtes imbriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agrgration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mises--jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ce chapitre prsente le langage SQL dinterrogation et de manipulation de donnes (insertion, mise--jour, destruction). La syntaxe est celle de la norme SQL2, implante plus ou moins compltement dans la plupart des principaux SGBDR. Certaines fonctionnalits (triggers par exemple) sont en cours de normalisation dans SQL3, mais existent dj dans quelques systmes en raison de leur importance. Ils seront prsents brivement. SQL est un langage dclaratif qui permet dinterroger une base de donnes sans se soucier de la reprsentation interne (physique) des donnes, de leur localisation, des chemins daccs ou des algorithmes ncessaires. A ce titre il sadresse une large communaut dutilisateurs potentiels (pas seulement des informaticiens) et constitue un des atouts les plus spectaculaires (et le plus connu) des SGBDR. On peut lutiliser de manire interactive, mais galement en association avec des interfaces graphiques, des outils de reporting ou, trs gnralement, des langages de programmation. Ce dernier aspect est trs important en pratique car SQL ne permet pas de faire de la programmation au sens courant du terme et doit donc tre associ avec un langage comme le C, le COBOL ou JAVA pour raliser des traitements complexes accdant une base de donnes. Linterface de SQL et du langage C sera prsente dans le chapitre 6.
4.1. REQUTES SIMPLES SQL
64
4.1 Requtes simples SQL

Dans tout ce chapitre on va prendre lexemple de la (petite) base de donnes prsente dans le chapitre sur lalgbre.
4.1.1 Slections simples

Commenons par les requtes les plus simples : la gure 3.1 montre une instance de la base pour les relations Station et Activite. Premire requte : on souhaite extraire de la base le nom de toutes les stations se trouvant aux Antilles. SELECT nomStation FROM Station WHERE region = Antilles Ce premier exemple montre la structure de base dune requte SQL, avec les trois clauses SELECT, FROM et WHERE. FROM indique la (ou les) tables dans lesquelles on trouve les attributs utiles la requte. Un attribut peut tre utile de deux manires (non exclusives) : (1) on souhaite afcher son contenu, (2) on souhaite quil ait une valeur particulire (une constante ou la valeur dun autre attribut). SELECT indique la liste des attributs constituant le rsultat. WHERE indique les conditions que doivent satisfaire les n-uplets de la base pour faire partie du rsultat. Dans lexemple prcdent, linterprtation est simple : on parcourt les n-uplets de la relation Station. Pour chaque n-uplet, si lattribut region a pour valeur Antilles, on place lattribut nomStation dans le rsultat 1 . On obtient donc le rsultat : nomStation Venusa Santalba Le rsultat dun ordre SQL est toujours une relation (une table) dont les attributs sont ceux spcis dans la clause SELECT. On peut donc considrer en premire approche ce rsultat comme un dcoupage, horizontal et vertical, de la table indique dans le FROM, similaire une utilisation combine de la slection et de la projection en algbre relationnelle. En fait on dispose dun peu plus de libert que cela. On peut : Renommer les attributs Appliquer des fonctions aux valeurs de chaque tuple. Introduire des constantes. Les fonctions applicables aux valeurs des attributs sont par exemple les oprations arithmtiques ( , *, ...) pour les attributs numriques ou des manipulations de chane de caractres (concatnation, sous-chanes, mise en majuscule, ...). Il nexiste pas de norme mais la requte suivante devrait fonctionner sur tous les systmes : on convertit le prix des activits en euros et on afche le cours de leuro avec chaque tuple. SELECT libelle, prix / 6.56, Cours de leuro = , 6.56 FROM Activite WHERE nomStation = Santalba Ce qui donne le rsultat : libelle Kayac prix / 6.56 7.62 Cours de leuro = Cours de leuro = 6.56 6.56
1. Attention, ce nest pas forcment ainsi que la requte est excute par le systme.
65
Renommage Les noms des attributs sont par dfaut ceux indiqus dans la clause SELECT, mme quand il y a des expressions complexes. Pour renommer les attributs, on utilise le mot-cl AS. SELECT libelle, prix / 6.56 AS prixEnEuros, Cours de leuro = , 6.56 AS cours FROM Activite WHERE nomStation = Santalba On obtient alors : libelle Kayac prixEnEuros 7.69 Cours de leuro = Cours de leuro = cours 6.56
Remarque : Sur certains systmes, le mot-cl AS est optionnel.
Doublons Lintroduction de fonctions permet daller au-del de ce qui est possible en algbre relationnelle. Il existe une autre diffrence, plus subtile : SQL permet lexistence de doublons dans les tables (il ne sagit donc pas densemble au sens strict du terme). La spcication de cls permet dviter les doublons dans les relations stockes, mais il peuvent apparatre dans le rsultat dune requte. Exemple : SELECT libelle FROM Activite donnera autant de lignes dans le rsultat que dans la table Activite. libelle Voile Plongee Plongee Ski Piscine Kayac Pour viter dobtenir deux tuples identiques, on peut utiliser le mot-cl DISTINCT. SELECT DISTINCT libelle FROM Activite Attention : llimination des doublons peut tre une opration coteuse. Tri du rsultat Il est possible de trier le rsultat dun requte avec la clause ORDER BY suivie de la liste des attributs servant de critre au tri. Exemple : SELECT * FROM Station ORDER BY tarif, nomStation
4.1. REQUTES SIMPLES SQL
66
trie, en 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. Voici maintenant la plus simple des requtes SQL : elle consiste afcher lintgralit dune table. Pour avoir toutes les lignes on omet la clause WHERE, et pour avoir toutes les colonnes, on peut au choix lister tous les attributs ou utiliser le caractre * qui a la mme signication. SELECT * FROM Station
4.1.2 La clause WHERE

Dans la clause WHERE, on spcie une condition boolenne portant sur les attributs des relations du FROM. On utilise pour cela de manire standard le AND, le OR, le NOT et les parenthses pour changer lordre de priorit des oprateurs boolens. Par exemple : SELECT FROM WHERE AND nomStation, libelle Activite nomStation = Santalba (prix > 50 AND prix < 120)
Les oprateurs de comparaison sont ceux du Pascal : , , , , , et pour exprimer la diffrence ( est galement possible). Pour obtenir une recherche par intervalle, on peut galement utiliser le mot-cl BETWEEN. La requte prcdente est quivalente : SELECT FROM WHERE AND nomStation, libelle Activite nomStation = Santalba prix BETWEEN 50 AND 120
Chanes de caractres Les comparaisons de chanes de caractres soulvent quelques problmes dlicats. 1. Il faut tre attentif aux diffrences entre chanes de longueur xe et chanes de longueur variable. Les premires sont compltes par des blancs ( ) et pas les secondes. 2. Si SQL ne distingue pas majuscules et minuscules pour les mot-cls, il nen va pas de mme pour les valeurs. Donc SANTALBA est diffrent de Santalba. SQL fournit des options pour les recherches par motif (pattern matching) laide de la clause LIKE. Le caractre _ dsigne nimporte quel caractre, et le % nimporte quelle chane de caractres. Par exemple, voici la requte cherchant toutes les stations dont le nom termine par un a. SELECT nomStation FROM Station WHERE nomStation LIKE %a Quelles sont les stations dont le nom commence par un V et comprend exactement 6 caractres ? SELECT nomStation FROM Station WHERE nomStation LIKE V_____

Dates
67
Une autre diffrence avec lalgbre est la possibilit de manipuler des dates. En fait tous les systmes proposaient bien avant la normalisation leur propre format de date, et la norme prconise par SQL2 nest de ce fait pas suivie par tous. Une date est spcie en SQL2 par le mot-cl DATE suivi dune chane de caractres au format aaaa-mm-jj, par exemple DATE 1998-01-01. Les zros sont ncessaires an que le mois et le quantime comprennent systmatiquement deux chiffres. On peut effectuer des slections sur les dates laide des comparateurs usuels. Voici par exemple la requte ID des clients qui ont commenc un sjour en juillet 1998. SELECT idClient FROM Sejour WHERE debut BETWEEN DATE 1998-07-01 AND
DATE 1998-07-31
Les systmes proposent de plus des fonctions permettant de calculer des carts de dates, dajouter des mois ou des annes des dates, etc.
4.1.3 Valeurs nulles

Autre spcicit de SQL par rapport lalgbre : on admet que la valeur de certains attributs soit inconnue, et on parle alors de valeur nulle, dsigne par le mot-cl NULL. Il est trs important de comprendre que la valeur nulle nest en fait pas une valeur mais une absence de valeur, et que lon ne peut donc lui appliquer aucune des oprations ou comparaisons usuelles. Toute opration applique NULL donne pour rsultat NULL. Toute comparaison avec NULL donne un rsultat qui nest ni vrai, ni faux mais une troisime valeur boolenne, UNKNOWN. Les valeurs boolennes TRUE, FALSE et UNKNOWN sont dnies de la manire suivante : TRUE vaut 1, FALSE 0 et UNKNOWN 1/2. Les connecteurs logiques donnent alors les rsultats suivants :

1. 2.
AND

= =
OR
Les conditions exprimes dans une clause WHERE sont values pour chaque tuple, et ne sont conservs dans le rsultat que les tuples pour lesquels cette valuation donne TRUE. La prsence dune valeur nulle dans une comparaison a donc souvent (mais pas toujours !) le mme effet que si cette comparaison choue et renvoie FALSE. Voici une instance de la table SEJOUR avec des informations manquantes. SEJOUR station dbut Passac 1998-07-01 Santalba 1998-08-03 Passac
La prsence de NULL peut avoir des effets surprenants. Par exemple la requte suivante SELECT station FROM Sejour WHERE nbPlaces <= 10 OR nbPlaces >= 10
3. NOT

idClient 10 20 30
nbPlaces 2 3
4.2. REQUTES SUR PLUSIEURS TABLES
68
devrait en principe ramener toutes les stations de la table. En fait Santalba ne gurera pas dans le rsultat car nbPlaces est NULL. Autre pige : NULL est un mot-cl, pas une constante. Donc une comparaison comme nbPlaces = NULL est incorrecte. Le prdicat pour tester labsence de valeur dans une colonne est IS NULL (et son inverse IS NOT NULL). La requte suivante slectionne tous les sjours pour lesquels on connat le nombre de places. SELECT * FROM Sejour WHERE nbPlaces IS NOT NULL La prsence de NULL est une source de problmes : dans la mesure du possible il faut lviter en spciant la contrainte NOT NULL ou en donnant une valeur par dfaut.
4.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, diffrence.
4.2.1 Jointures
La jointure est une des oprations les plus utiles (et donc une des plus courantes) puisquelle permet dexprimer des requtes portant sur des donnes rparties dans plusieurs tables. La syntaxe pour exprimer des jointures avec SQL est une extension directe de celle tudie prcdemment dans le cas des slections simples : on donne simplement 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 Sejour. 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, Sejour WHERE id = idClient On peut remarquer quil ny a pas dans ce cas dambiguit sur les noms des attributs : nom et id viennent de la table Client, tandis que station et idClient viennent de la table Sejour. Il peut arriver (il arrive de fait frquemment) quun mme nom dattribut soit partag par plusieurs tables impliques dans une jointure. Dans ce cas on rsout lambiguit en prxant lattribut par le nom de la table. Exemple : afcher le nom dune station, son tarif hebdomadaire, ses activits et leurs prix. SELECT nomStation, tarif, libelle, prix FROM Station, Activite WHERE Station.nomStation = Activite.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 : 2 SELECT S.nomStation, tarif, libelle, prix FROM Station S, Activite A WHERE S.nomStation = A.nomStation
2. Au lieu de Station S, la norme SQL2 prconise Station AS S, mais le AS est parfois inconnu ou optionnel.
69
Bien entendu, on peut effectuer des jointures sur un nombre quelconque de tables, et les combiner avec des slections. Voici par exemple la requte qui afche le nom des clients habitant Paris, les stations o ils ont sjourn avec la date, enn le tarif hebdomadaire pour chaque station. SELECT FROM WHERE AND AND nom, station, debut, tarif Client, Sejour, Station ville = Paris id = idClient station = nomStation
Il ny a pas dambiguit sur les noms dattributs donc il est inutile en loccurence demployer des synonymes. Il existe en revanche une situation o lutilisation des synonymes est indispensable : celle ou lon souhaite effectuer une jointure dune relation avec elle-mme. Considrons la requte suivante : 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 sil on devait faire la jointure entre deux versions distinctes de la table Station. Techniquement, on rsout le problme en SQL en utilisant deux synonymes distincts. SELECT s1.nomStation, s2.nomStation FROM Station s1, Station s2 WHERE s1.region = s2.region On peut imaginer que s1 et s2 sont deux curseurs qui parcourent indpendamment la table Station et permettent de constituer des couples de tuples auxquels on applique la condition de jointure. Interprtation dune jointure Linterprtation dune jointure est une gnralisation de linterprtation dun ordre SQL portant sur une seule table. Intuitivement, on parcourt tous les tuples dnis par la clause FROM, et on leur applique la condition exprime dans le WHERE. Finalement on ne garde que les attributs spcis dans la clause SELECT. Quels sont les tuples dnis par le FROM ? Dans le cas dune seule table, il ny a pas de difcult. Quand il y a plusieurs tables, on peut donner (au moins) deux dnitions quivalentes : 1. Boucles imbriques. On considre chaque synonyme de table (ou par dfaut chaque nom de table) comme une variable tuple. Maintenant on construit des boucles imbriques, chaque boucle correspondant une des tables du FROM et permettant la variable correspondante ditrer sur le contenu de la table. A lintrieur de lensemble des boucles, on applique la clause WHERE. 2. Produit cartsien. On construit le produit cartsien des tables du FROM, en prxant chaque attribut par le nom ou le synonyme de sa table pour viter les ambiguits. On est alors ramen la situation o il y a une seule table (le rsultat du produit cartsien) et on interprte lordre SQL comme dans le cas des requtes simples. La premire interprtation est proche de ce que lon obtiendrait si on devait programmer une requte avec un langage comme le C ou Pascal, la deuxime sinspire de lalgbre relationnelle.
4.2.2 Union, intersection et diffrence

Lexpression de ces trois oprations ensemblistes en SQL est trs proche de lalgbre relationnelle. On construit deux requtes dont les rsultats ont mme arit (mme nombre de colonnes et mmes types dattributs), et on les relie par un des mot-cl UNION, INTERSECT ou EXCEPT. Trois exemples sufront pour illustrer ces oprations. 1. Donnez tous les noms de rgion dans la base. SELECT region FROM Station
4.3. REQUTES IMBRIQUES

UNION SELECT region FROM Client
70
2. Donnez les rgions o lon trouve la fois des clients et des stations. SELECT region FROM Station INTERSECT SELECT region FROM Client
3. Quelles sont les rgions o lon trouve des stations mais pas des clients ? SELECT region FROM Station EXCEPT SELECT region FROM Client
La norme SQL2 spcie que les doublons doivent tre limins du rsultat lors des trois oprations ensemblistes. Le cot de llimination de doublons ntant pas ngligeable, il se peut cependant que certains systmes fassent un choix diffrent. Lunion ne peut tre exprime autrement quavec UNION. En revanche INTERSECT peut tre exprime avec une jointure, et la diffrence sobtient, souvent de manire plus aise, laide des requtes imbriques.
4.3 Requtes imbriques

Jusqu prsent les conditions exprimes dans le WHERE consistaient en comparaisons de valeurs scalaires. Il est possible galement avec SQL dexprimer des conditions sur des relations. Pour lessentiel, ces conditions consistent en lexistence dau moins un tuple dans la relation teste, ou en lappartenance dun tuple particulier la relation. La relation teste est construite par une requte SELECT ... FROM ... WHERE que lon appelle sous-requte ou requte imbrique puisquelle apparat dans la clause WHERE
4.3.1 Conditions portant sur des relations

Une premire utilisation des sous-requtes est doffrir une alternative syntaxique lexpression de jointures. Les jointures concernes sont celles pour lesquelles le rsultat est constitu avec des attributs provenant dune seule des deux tables, lautre ne servant que pour exprimer des conditions. Prenons lexemple suivant : on veut les noms des stations o ont sjourn des clients parisiens. On peut obtenir le rsultat avec une jointure classique. SELECT FROM WHERE AND station Sejour, Client id = idClient 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 FROM WHERE station Sejour idClient IN (SELECT id FROM Client WHERE ville = Paris)
71
Le mot-cl IN exprime clairement la condition dappartenance de idClient la relation forme par la requte imbrique. On peut remplacer le IN par un simple = si on est sr que la sous-requte ramne un et un seul tuple. Par exemple : SELECT FROM WHERE nom, prenom Client region = (SELECT region FROM Station WHERE nomStation = Santalba)
est (partiellement) correct car la recherche dans la sous-requte seffectue par la cl. En revanche il se peut quaucun tuple ne soit ramen, ce qui gnre une erreur. Voici les conditions que lon peut exprimer sur une relation 1. EXISTS R. Renvoie TRUE si 2. 3.
nest pas vide, FALSE sinon. . TRUE si appartient
IN R o est un tuple dont le type est celui de
ANY R, o est un comparateur SQL ( , , , etc.). Renvoie TRUE si la comparaison avec au moins un des tuples de la relation unaire renvoie TRUE.
De plus, toutes ces expressions peuvent tre prxes par NOT pour obtenir la ngation. Voici quelques exemples. O (station, lieu) ne peut-on pas faire du ski ? SELECT nomStation, lieu FROM Station WHERE nomStation NOT IN (SELECT nomStation FROM Activite WHERE libelle = Ski) Quelle station pratique le tarif le plus lev ? SELECT nomStation FROM Station WHERE tarif >= ALL (SELECT tarif FROM Station) 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) Ces requtes peuvent sexprimer sans imbrication (exercice), parfois de manire moins lgante ou moins concise. La diffrence, en particulier, sexprime facilement avec NOT IN ou NOT EXISTS.
4.
ALL R, o est un comparateur SQL ( , tuples de la relation unaire renvoie TRUE.
, etc.). Renvoie TRUE si la comparaison avec tous les
construite avec une requte imbrique.
, FALSE sinon.
4.4. AGRGRATION
72
4.3.2 Sous-requtes correlles

Les exemples de requtes imbriques donns prcdemment pouvait tre valus indpendamment de la requte principale, ce qui permet 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 correlles. Exemple : quels sont les clients (nom, prnom) qui ont sjourn 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. Remarque : on peut employer un NOT IN la place du NOT EXISTS (exercice), de mme que lon peut toujours employer EXISTS la place de IN. Voici une des requtes prcdentes o lon a appliqu cette transformation, en utilisant de plus des synonymes. Dans quelle station pratique-t-on une activit au mme prix qu Santalba ? SELECT nomStation FROM Activite A1 WHERE EXISTS (SELECT WHERE AND AND
xFROM Activite A2 nomStation = Santalba A1.libelle = A2.libelle A1.prix = A2.prix)
Cette requte est elle-mme quivalente une jointure sans requte imbrique.
4.4 Agrgration
Toutes les requtes vues jusqu prsent pouvaient tre interprtes comme une suite doprations effectues tuple tuple. De mme le rsultat tait toujours constitu de valeurs issues de tuples individuels. Les fonctionnalits dagrgation de SQL permettent dexprimer des conditions sur des groupes de tuples, et de constituer le rsultat par agrgation de valeurs au sein de chaque groupe. La syntaxe SQL fournit donc : 1. Le moyen de partitioner 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 : cest la relation toute entire. Sans mme dnir de groupe, on peut utiliser les fonctions dagrgation.
4.4.1 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 effectue le cumul. Exemple dutilisation de ces fonctions : SELECT COUNT(nomStation), AVG(tarif), MIN(tarif), MAX(tarif) FROM Station
73
Remarque importante : on ne peut pas utiliser simultanment dans la clause SELECT des fonctions dagrgation et des noms dattributs (sauf dans le cas dun GROUP BY, voir plus loin). La requte suivante est incorrecte (pourquoi ?). SELECT nomStation, AVG(tarif) FROM Station A condition de respecter cette rgle, on peut utiliser les ordres SQL les plus complexes. Exemple : Combien de places a rserv Mr Kerouac pour lensemble des sjours ?. SELECT FROM WHERE AND SUM (nbPlaces) Client, Sejour nom = Kerouac id = idClient
4.4.2 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 partitioner 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 : afcher les rgions avec le nombre de stations. SELECT region, COUNT(nomStation) FROM Station GROUP BY region Donc ici on constitue un groupe pour chaque rgion. Puis on afche 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. Exemple ici lattribut region ; 2. le rsultat dune fonction dagrgation applique au groupe : ici COUNT(nomStation). Bien entendu il est possible dexprimer des ordres SQL complexes et dappliquer un GROUP BY au rsultat. De plus, il nest pas ncessaire de faire gurer tous les attributs du GROUP BY dans la clause SELECT. Exemple : on souhaite consulter le nombre de places reserves, par client. SELECT FROM WHERE GROUP BY nom, SUM (nbPlaces) Client, Sejour id = idClient id, nom
Linterprtation est simple : (1) on excute dabord la requte SELECT ... FROM ... WHERE, puis (2) on prend le rsultat et on le partitione, enn (3) on calcule le rsultat des fonctions. A lissue de ltape (2), on peut imaginer une relation qui nest pas en premire forme normale : on y trouverait des tuples avec les attributs du GROUP BY sous forme de valeur atomique, puis des attributs de type ensemble (donc interdits dans le modle relationnel). Cest pour se ramener en 1FN que lon doit appliquer des fonctions dagrgation ces ensembles. Exercice : pourquoi grouper sur id, nom ? Quels sont les autres choix possibles et leurs inconvnients ?
4.5. MISES--JOUR
74
4.4.3 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 : on souhaite consulter le nombre de places reserves, par client, pour les clients ayant rserv plus de 10 places. SELECT FROM WHERE GROUP BY HAVING nom, SUM (nbPlaces) Client, Sejour id = idClient nom 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.5 Mises--jour
Les commandes de mise--jour (insertion, destruction, modication) sont considrablement plus simples que les requtes.
4.5.1 Insertion
Linsertion seffectue avec 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 lequels 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 gurer dans une clause INSERT. Les v1, ... vn sont les valeurs des attributs. Exemple de linsertion dun tuple dans la table Client. INSERT INTO Client (id, nom, prenom) VALUES (40, Moriarty, Dean) Donc, lissue de cette insertion, 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 : on a cr une table Sites (lieu, region) et on souhaite y copier les couples (lieu, region) dj existant 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.
4.5.2 Destruction
La destruction seffectue avec la clause DELETE dont la syntaxe est : DELETE FROM R WHERE condition R est bien entendu la table, et condition est toute condition valide pour une clause WHERE. En dautres termes, si on effectue, avant la destruction, la requte SELECT * FROM R WHERE condition
75
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 : destruction de tous les clients dont le nom commence par M. DELETE FROM Client WHERE nom LIKE M%
4.5.3 Modication
La modication seffectue avec 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 : augmenter le prix des activits de la station Passac de 10%. UPDATE Activite SET prix = prix * 1.1 WHERE nomStation = Passac Une remarque importante : toutes les mises--jour ne deviennent dnitives qu lissue dune validation par commit. Entretemps elles peuvent tre annules par rollback. Voir le cours sur la concurrence daccs.
4.6 Exercices
Exercice 17 Reprendre les expressions algbriques du premier exercice du chapitre algbre, et les exprimer en SQL. Exercice 18 Donnez lexpression SQL des requtes suivantes, ainsi que le rsultat obtenu avec la base du chapitre Le langage SQL. 1. Nom des stations ayant strictement plus de 200 places. 2. Noms des clients dont le nom commence par P ou dont le solde est suprieur 10 000. 3. Quelles sont les rgions dont lintitul comprend (au moins) deux mots ? 4. Nom des stations qui proposent de la plonge. 5. Nom des clients qui sont alls Santalba. 6. Donnez les couples de clients qui habitent dans la mme rgion. Attention : un couple doit apparatre une seule fois. 7. Nom des rgions qua visit Mr Pascal. 8. Nom des stations visites par des europens. 9. Qui nest pas all dans la station Farniente ? 10. Quelles stations ne proposent pas de la plonge ? 11. Combien de sjours ont eu lieu Passac ? 12. Donner, pour chaque station, le nombre de sjours qui sy sont drouls. 13. Donner les stations o se sont drouls au moins 3 sjours. 14.

Les clients qui sont alls dans toutes les stations.
4.6. EXERCICES
Exercice 19 (Valeurs nulles) On considre la table suivante : NomStation Gratuite NullePart STATION Capacit Lieu 80 Guadeloupe 150 Rgion Antilles Tarif 2000
76
1. Donnez les rsultats des requtes suivantes (rappel : le || est la concatnation de chanes de caractres.). (a) SELECT nomStation FROM Station WHERE tarif >200 (b) SELECT tarif * 3 FROM Station WHERE nomStation LIKE %l% AND lieu LIKE % (c) SELECT Lieu = || lieu FROM Station WHERE capacite >= 100 OR tarif >= 1000 (d) SELECT Lieu = || lieu FROM Station WHERE NOT (capacite <100 AND tarif <1000) 2. Les deux dernires requtes sont-elles quivalentes (i.e. donnent-elles le mme rsultat quel que soit le contenu de la table) ? 3. Supposons que lon ait conserv une logique bivalue (avec TRUE et FALSE) et adopt la rgle suivante : toute comparaison avec un NULL donne FALSE. Obtient-on des rsultats quivalents ? Cette rgle est-elle correcte ? 4. Mme question, en supposant que toute comparaison avec NULL donne TRUE.
Exercice 20 On reprend la requte constituant la liste des stations avec leurs activits, lgrement modie. SELECT S.nomStation, tarif, libelle, prix FROM Station S, Activites A, Sejour WHERE S.nomStation = A.nomStation 1. La table Sejour est-elle ncessaire dans le FROM ? 2. Quobtient-on dans les trois cas suivants : (1) la table Sejour contient 1 tuple, (2) la table Sejour contient 100 000 tuples, (3) la table Sejour est vide.

3. Soit trois tables R, S et T ayant chacune un seul attribut A. On veut calculer R
(S
T).
(a) La requte suivante est-elle correcte ? Expliquez pourquoi. SELECT R.A FROM R, S, T WHERE R.A=S.A OR R.A=T.A (b) Donnez la bonne requte.
CHAPITRE 5. SCHMAS RELATIONNELS
77
Chapitre 5
Schmas relationnels
Sommaire
5.1 Schmas . . . . . . . . . . . . . . . . . . 5.1.1 Dnition dun schma . . . . . . 5.1.2 Utilisateurs . . . . . . . . . . . . Contraintes et assertions . . . . . . . . . Vues . . . . . . . . . . . . . . . . . . . . 5.3.1 Cration et interrogation dune vue 5.3.2 Mise jour dune vue . . . . . . . Triggers . . . . . . . . . . . . . . . . . . 5.4.1 Principes des triggers . . . . . . . 5.4.2 Syntaxe . . . . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 78 78 79 81 81 82 83 83 83 84
5.2 5.3
5.4
5.5
Ce chapitre prsente lenvironnement dun utilisateur travaillant avec un SGBD relationnel. On se place donc 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 Ofciel des spectacles et le schma Agence de voyage . En toute rigueur il faudrait donc distinguer linstance de schma de la base de donnes qui est un sur-ensemble. Comme on se situe en gnral dans un et un seul schma, on peut utiliser les deux termes de manire quivalente. Le schma est le principal concept tudi dans ce chapitre. Outre les tables, un schma peut comprendre des vues, des contraintes de diffrents types, des triggers ( reexes ) 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 ici. Dans tout ce chapitre, on basera les exemples sur le schma Ofciel qui est rappel ci-dessous. Cinma (nomCinma, numro, rue, ville) Salle (nomCinma, no, capacit, climatise) Horaire (idHoraire, heureDbut, heureFin) Sance (idFilm, nomCinma, noSalle, idHoraire, tarif) Film (idFilm, titre, anne, genre, rsum, idMES) Artiste (id, nom, prnom, anneNaissance) Rle (idActeur, idFilm, nomRle)

5.1. SCHMAS
78
5.1 Schmas
Cette section dcrit la notion de schma au sens SQL2, ainsi que le systme de droits daccs un schma destin garantir la scurit de la base.
5.1.1 Dnition dun schma

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 voyage . CREATE CREATE CREATE ... CREATE ... CREATE ... CREATE ... SCHEMA agence_de_voyage TABLE Station (... TABLE Client (... VIEW .... ASSERTION ... TRIGGER ...

Deux schmas diffrents 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_des_spectacles 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 norme SQL2 dnit deux niveaux suprieurs au schma : les catalogues et les groupes (cluster). Ils correspondent respectivement aux niveaux dunicit de nom de schma, et daccessibilit une table dans une requte. Donc un utilisateur ne peut spcier dans sa requte que les tables du cluster courant.
5.1.2 Utilisateurs
Laccs une base de donnes est restreint, pour des raisons videntes 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 Suivie de lentre du mot de passe demande 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 schmas que lutilisateur a luimme 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 propritaire du schma. Par dfaut, on na aucun droit.
79
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 voici la syntaxe : GRANT ON TO [WITH <privilege> <element du schema> <utilisateur> 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. Voici la commande permettant Marc de consuter les lms. GRANT SELECT ON Film TO Marc; On peut dsigner tous les utilisateurs avec le mot-cl PUBLIC, et tous les privilges avec lexpression ALL PRIVILEGES. GRANT ALL PRIVILEGES ON Film TO PUBLIC On supprime un droit avec la commande REVOKE dont la syntaxe est semblable celle de GRANT. REVOKE SELECT ON Film FROM Marc
5.2 Contraintes et assertions

Nous revenons maintenant de manire plus approfondie sur les contraintes portant sur le contenu des tables. Il est trs important de spcier les contraintes dans le schma, an que le SGBD puisse les prendre en charge. Cela vite deffectuer des contrles de manire rptitive (et souvent lacunaire) dans les applications qui accdent la base. Les contraintes (essentielles) portant sur les cls simples, primaires et trangres ont dj t vues dans le chapitre 2. Les contraintes dcrites ici sont moins spciques et portent sur les valeurs des attributs ou plus globalement sur le contenu dune ou plusieurs relations. La commande CHECK (condition) permet dexprimer toute contrainte portant soit sur un attribut, soit sur un tuple. La condition elle-mme peut tre toute expression suivant la clause WHERE dans une requte SQL. Les contraintes les plus courantes sont celles consistant restreindre un attribut un ensemble de valeurs, mais on peut trouver des contraintes arbitrairement complexes, faisant rfrence dautres relations. Dans ce cas, on doit obligatoirement utiliser des sous-requtes.
5.2. CONTRAINTES ET ASSERTIONS
80
Exemple simple : on restreint les valeurs possibles des attributs capacit et climatise dans la table Salle. CREATE TABLE Salle (nomCinema no capacite climatisee PRIMARY KEY FOREIGN KEY
VARCHAR (30) NOT NULLL, INTEGER, INTEGER CHECK (capacite 300), CHAR(1) CHECK (climatisee IN (O,N)), (nomCinema, no), nomCinema REFERENCES Cinema)

Il sagit de contraintes portant sur des valeurs dattributs. A chaque insertion dun tuple, ou mise--jour de ce tuple affectant un des attributs contraints, le contrle sera effectu. La rgle est que la condition ne doit pas svaluer FALSE (donc la valeur UNKNOWN est accepte). Voici un autre exemple illustrant lutilisation dune sous-requte : on souhaite remplacer la contrainte FOREIGN KEY par une clause CHECK. CREATE TABLE Salle (nomCinema VARCHAR (30) NOT NULLL, no INTEGER, capacite INTEGER CHECK (capacite 300), climatisee CHAR(1) CHECK (climatisee IN (O,N)), PRIMARY KEY (nomCinema, no), CHECK (nomCinma IN (SELECT nom FROM Cinema)))
Il sagit dune illustration simple dune clause CHECK avec sous-requte, mais elle est incorrecte pour garantir lintgrit rfrentielle. Pourquoi ? (penser aux vnements qui dclenchent respectivement les contrles des clauses CHECK et FOREIGN KEY). Au lieu dassocier une contrainte un attribut particulier, on peut la dnir globalement. Dans ce cas la contrainte peut faire rfrence nimporte quel attribut de la table et est teste tuple tuple. Exemple : toute salle de plus de 300 places doit tre climatise : CREATE TABLE Salle (nomCinema VARCHAR (30) NOT NULLL, no INTEGER, capacite INTEGER, climatisee CHAR(1), PRIMARY KEY (nomCinema, no), FOREIGN KEY nomCinema REFERENCES Cinema, CHECK (capacit 300 OR Climatis = O))
Lutilisation des sous-requtes nest pas recommande, cause du problme soulign prcdemment : la contrainte peut tre satisfaite au moment de linsertion du tuple, et ne plus ltre aprs. Exemple : la grande salle du Rex doit rester la plus grande ! CREATE TABLE Salle (nomCinema VARCHAR (30) NOT NULLL, no INTEGER, capacite INTEGER, climatisee CHAR(1), PRIMARY KEY (nomCinema, no), FOREIGN KEY nomCinema REFERENCES Cinema, CHECK (capacit (SELECT Max(capacite) FROM Salle WHERE nomCinema = Rex)))
81
Problme : si on diminue la taille de la salle du Rex, la contrainte peut ne plus tre respecte. Il est donc prfrable de ne pas utiliser la clause CHECK pour des contraintes impliquant dautres tables. Il est possible, et recommand, de donner un nom aux contraintes avec la clause CONSTRAINT. CONSTRAINT clim CHECK (capacite < 300 OR climatisee = O) Cela facilite la comprhension des messages, et permet de modier ou de dtruire une contrainte : ALTER TABLE Salle DROP CONSTRAINT clim
5.3 Vues
Cette section est consacre lune des fonctionnalits les plus remarquables des SGBD relationnels : les vues. Comme nous lavons vu dans la partie consacre SQL, une requte produit toujours une relation. Cela suggre la possibilit dajouter au schma des tables virtuelles qui ne sont rien dautres que le rsultat de requtes stockes. De telles tables sont nommes des vues dans la terminologie relationnelle. On peut interroger des vues comme des tables stockes. Une vue ninduit aucun stockage puisquelle nexiste pas physiquement, et permet dobtenir une reprsentation diffrente des tables sur lesquelles elle est base.
5.3.1 Cration et interrogation dune vue

Une vue est tout point comparable une table : en particulier on peut linterroger par SQL. La grande diffrence est quune vue est le rsultat dune requte, avec la caractristique essentielle que ce rsultat est rvalu chaque fois que lon accde la vue. En dautre termes une vue est dynamique : elle donne une reprsentation dle de la base au moment de lvaluation de la requte. Une vue est essentiellemnt une requte laquelle on a donn un nom. La syntaxe de cration dune vue est trs simple : CREATE VIEW <nom-vue> AS <requte> [WITH CHECK OPTION] Exemple : on peut crer une vue qui ne contient que les cinmas parisiens : CREATE VIEW ParisCinemas AS SELECT * FROM Cinema WHERE ville = Paris On peut aussi en proter pour restreindre la vision des cinmas parisiens leur nom et leur nombre de salles. CREATE VIEW SimpleParisCinemas AS SELECT nom, COUNT(*) AS nbSalles FROM Cinema c, Salle s WHERE ville = Paris AND c.nom = s.nomCinema GROUP BY c.nom Enn un des intrts des vues est de donner une reprsentation dnormalise de la base, en regroupant des informations par des jointures. Par exemple on peut crer une vue Casting donnant explicitement les titres des lms, leur anne et les noms et prnoms des acteurs. CREATE SELECT FROM WHERE AND VIEW Casting (film, annee, acteur, prenom) AS titre, annee, nom, prenom Film f, Role r, Artiste a f.idFilm = r.idFilm r.idActeur = a.idArtiste

5.3. VUES
82
Remarque : on a donn explicitement des noms dattributs au lieu dutiliser les attributs de la clause SELECT. Maintenant, on peut utiliser les vues et les tables dans des requtes SQL. Par exemple la requte Quels acteurs ont tourn un lm en 1997 sexprime par : SELECT acteur, prenom FROM Casting WHERE annee = 1997 On peut ensuite donner des droits en lecture sur cette vue pour que cette information limite soit disponible tous. GRANT SELECT ON Casting TO PUBLIC

5.3.2 Mise jour dune vue

Lide de modier une vue peut sembler trange puisquune vue na pas de contenu. En fait il sagit bien entendu de modier la table qui sert de support la vue. Il existe de svres restrictions sur les droits dinsrer ou de mettre-jour des tables travers les vues. Un exemple suft pour comprendre le problme. Imaginons que lon souhaite insrer une ligne dans la vue Casting. INSERT INTO CASTING (film, annee, acteur, prenom) VALUES (Titanic, 1998, DiCaprio, Leonardo); Cet ordre sadresse une vue issue de trois tables. Il ny a clairement pas assez dinformation pour alimenter ces tables de manire cohrente, et linsertion nest pas possible (de mme que toute mise jour). De telles vues sont dites non modiables. Les rgles dnissant les vues modiables sont trs strictes. 1. La vue doit tre base sur une seule table. 2. Toute colonne non rfrence dans la vue doit pouvoir tre mise NULL ou disposer dune valeur par dfaut. 3. On ne peut pas mettre--jour un attribut qui rsulte dun calcul ou dune opration. Il est donc tout fait possible dinsrer, modier ou dtruire la table Film au travers de la vue ParisCinema. INSERT INTO ParisCinema VALUES (1876, Breteuil, 12, Cite, Lyon) En revanche, en admettant que la ville est dnie NOT NULL, il nest pas possible dinsrer dans SimpleParisCinemas. Linsertion prcdente illustre une petite subtilit : on peut insrer dans une vue, sans tre en mesure de voir la ligne insre au travers de la vue par la suite ! An dviter ce genre dincoherence, SQL2 propose loption WITH CHECK OPTION qui permet de garantir que toute ligne insre dans la vue satisfait les critres de slection de la vue. CREATE VIEW ParisCinemas AS SELECT * FROM Cinema WHERE ville = Paris WITH CHECK OPTION Linsertion donne en exemple ci-dessus devient impossible. Enn on dtruit une vue avec la syntaxe courante SQL : DROP VIEW ParisCinemas
83
5.4 Triggers
Le mcanisme de triggers (que lon peut traduire par dclencheur ou rexe) implant dans de nombreux SGBD nest pas voqu dans la norme SQL2 mais constitue un des points de discussion de la norme SQL3. Un trigger est une procdure qui est dclenche par des vnements de mise--jour spcis par lutilisateur et ne sexcute que quand une condition est satisfaite. On peut considrer les triggers comme une extension du systme de contraintes propos par la clause CHECK : la diffrence de cette dernire, lvnement dclencheur est explictement indiqu, et laction nest pas limite la simple alternative acceptation/rejet. Les possibilits offertes sont trs intressantes. Citons : 1. La possibilit dviter les risques dincohrence dus la prsence de redondance. 2. Lenregistrement automatique de certains vvenements (auditing). 3. La spccication de contraintes lies lvolution des donnes (exemple : le prix dune sance ne peut quaugmenter). 4. Toute rgle complexe lie lenvironnement dexcution (restrictions sur les horaires, les utilisateurs, etc).
5.4.1 Principes des triggers

Le modle dexcution des triggers est bas sur la squence Evnement-Condition-Action (ECA) que lon peut dcrire ainsi : 1. un trigger est dclench par un vnement, spci par le programmeur, qui est en gnral une insertion, destruction ou modication sur une table ; 2. la premire action dun trigger est de tester une condition : si cette condition ne svalue pas TRUE, lexcution sarrte ; 3. enn laction proprement dite peut consister en toute opration sur la base de donnes : les SGBD fournissent un langage impratif permettant de crer de vritables procdures. Une caractristique importante de cette procdure (action) est de pouvoir manipuler simultanment les valeurs ancienne et nouvelle de la donne modie, ce qui permet de faire des tests sur lvolution de la base. Parmi les autres caractristiques importantes, citons les deux suivantes. Tout dabord un trigger peut tre excut au choix une fois pour un seul ordre SQL, ou chaque ligne concerne par cet ordre. Ensuite laction dclenche peut intervenir avant lvnement, ou aprs. Lutilisation des triggers permet de rendre une base de donnes dynamique : une opration sur la base peut en dclencher dautres, qui elles-mmes peuvent entraner en cascade dautres rexes. Ce mcanisme nest pas sans danger cause des risques de boucle innie.
5.4.2 Syntaxe
Voici tout dabord un exemple de trigger qui maintient la capacit dun cinma chaque mise--jour sur la table Salle. 1 CREATE TRIGGER CumulCapacite AFTER UPDATE ON Salle FOR EACH ROW WHEN (new.capacite != old.capacite) BEGIN UPDATE Cinema SET capacite = capacite - :old.capacite WHERE nom = :new.nomCinema; END;
+ :new.capacite
1. Tous les exemples qui suivent utilisent la syntaxe des triggers Oracle, trs proche de celle de SQL3.
5.5. EXERCICES
84
Pour garantir la validit du cumul, il faudrait crer des triggers sur les vnements UPDATE et INSERT. Une solution plus concise (mais plus coteuse) est de recalculer systmatiquement le cumul : dans ce cas on peut utiliser un trigger qui se dclenche globalement pour la requte : CREATE TRIGGER CumulCapaciteGlobal AFTER UPDATE OR INSERT OR DELETE ON Salle BEGIN UPDATE Cinema C SET capacite = (SELECT SUM (capacite) FROM Salle S WHERE C.nom = S.nomCinema); END; La syntaxe de cration dun trigger est la suivante : CREATE trigger <nom-trigger> <quand> <vnements> ON <table> [FOR EACH ROW [WHEN <condition>]] BEGIN <action> END; / Les choix possibles sont : quand peut tre BEFORE ou AFTER. vnements spcie DELETE, UPDATE ou INSERT spars par des OR. FOR EACH ROW est optionnel. En son absence le trigger est dclench une fois pour toute requte modiant la table, et ce sans condition. Sinon condition est toute condition boolenne SQL. De plus on peut rrfrencer les anciennes et nouvelles valeurs du tuple courant avec la syntaxe new.attribut et old.attribut respectivement. action est une procdure qui peut tre implante, sous Oracle, avec le langage PL/SQL. Elle peut contenir des ordres SQL mais pas de mise--jour de la table courante. Les anciennes et nouvelles valeurs du tuple courant sont rfrences par :new.attr et :old.attr. Il est possible de modier new et old. Par exemple :new.prix=500; forcera lattribut prix 500 dans un BEFORE trigger. Remarque : la disponibilit de new et old dpend du contexte. Par exemple new est NULL dans un trigger dclench par DELETE.
5.5 Exercices
Exercice 21 On reprend le schma suivant dcrivant une bibliothque avec des livres et leurs auteurs. 1. Livre (titreLivre, anne, diteur, chiffreAffaire) 2. Chapitre (titreLivre, titreChapitre, nbPages) 3. Auteur (nom, prnom, anneNaissance) 4. Redaction (nomAuteur, titreLivre, titreChapitre) Indiquez comment exprimer les contraintes suivantes sur le schma relationnel, avec la syntaxe SQL2. 1. Lanne de parution dun livre est toujours connue.

2. Le nombre de pages dun chapitre est suprieur 0. 3. Un diteur doit faire partie de la liste {Seuil, Gallimard, Grasset}
85
Exercice 22 On veut crer un ensemble de vues sur la base Agence de voyages qui ne donne que les informations sur les stations aux Antilles. Il existe un utilisateur, lambda, qui ne doit pouvoir accder qu cet ensemble de vues, et en lecture uniquement. 1. Dnir la vue StationAntilles qui est identique Station, sauf quelle ne montre que les stations aux Antilles. 2. Dnir la vue ActivitAntilles donnant les activits proposes dans les stations de StationAntilles 3. Dnir la vue SejourAntilles avec les attributs nomClient, prnomClient, ville, station, dbut. Cette vue donne un rsum des sjours effectus dans les stations aux Antilles. 4. Dans quelles vues peut-on insrer ? Sur quelles vues est-il utile de mettre la clause WITH CHECK OTPION ? 5. Donner les ordres GRANT qui ne donnent lutilisateur lambda que la possibilit de voir les informations sur les vues Antilles.

Exercice 23 Une vue sur une table
qui ne comprend pas la cl primaire de
Exercice 24 Les cinmas changent rgulirement les lms qui passent dans leurs salles. On souhaite garder lhistorique de ces changements, an de connatre la succesion des lms proposs dans chaque salle. Voici lordre de cration de la table Sance. CREATE TABLE Seance (idFilm nomCinema noSalle idHoraire PRIMARY KEY FOREIGN KEY FOREIGN KEY FOREIGN KEY INTEGER NOT NULL, VARCHAR (30) NOT NULL, INTEGER NOT NULL, INTEGER NOT NULL, (idFilm, nomCinema, noSalle, idHoraire), (nomCinema, noSalle) REFERENCES Salle, (idFilm) REFERENCES Film, (idHoraire) REFERENCES Horaire);
Chaque fois que lon modie le code du lm dans une ligne de cette table, il faut insrer dans une table AuditSeance lidentiant de la sance, le code de lancien lm et le code du nouveau lm. 1. Donnez lordre de cration de la table AuditSance. 2. Donnez le trigger qui alimente la table AuditSance en fonction des mises jour sur la table Sance. Exercice 25 Supposons quun systme propose un mcanisme de triggers, mais pas de contrainte dintgrit rfrentielle. On veut allors implanter ces contraintes avec des triggers. Donner les triggers qui implantent la contrainte dintgrit rfrentielle entre Artiste et Film. Pour simplier, on suppose quil ny a jamais de valeur nulle.
est-elle modiable ?
5.5. EXERCICES
86
CHAPITRE 6. PROGRAMMATION AVEC SQL
87
Chapitre 6
Programmation avec SQL

Sommaire
6.1 Interfaage avec le langage C . . . . . . . . 6.1.1 Un exemple complet . . . . . . . . . 6.1.2 Dveloppement en C/SQL . . . . . . 6.1.3 Autres commandes SQL . . . . . . . Linterface Java/JDBC . . . . . . . . . . . . 6.2.1 Principes de JDBC . . . . . . . . . . 6.2.2 Le plus simple des programmes JDBC 6.2.3 Exemple dune applet avec JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 87 90 92 93 93 94 96
6.2
Ce chapitre prsente lintgration de SQL et dun langage de programmation classique. Lutilisation conjointe de deux langages rsulte de linsufsance de SQL en matire de traitement de donnes : on ne sait pas faire de boucle, de tests, etc. On utilise donc SQL pour extraire les donnes de la base, et le C (ou tout autre langage) pour manipuler ces donnes. La difcult principale consiste transcrire des donnes stockes selon des types SQL en donnes manipules par le langage de programmation La prsentation reste volontairement trs succincte : il sagit dillustrer le mcanisme de cohabitation entre les deux langages. Lobjectif est donc simplement de montrer comment on se connecte, comment on extrait des donnes de la base, et de donner quelques indications et conseils sur la gestion des erreurs, la structuration du code et les erreurs viter.
6.1 Interfaage avec le langage C

Le contenu consiste essentiellement dtailler un programme rel qui peut sexcuter sous le SGBD Oracle. Linterface SQL/C est normalise dans SQL2, et lexemple que lon va trouver ensuite est trs proche de cette norme.
6.1.1 Un exemple complet

Pour commencer, voici un exemple complet. Il suppose quil existe dans la base une table Film dont voici le schma (voir film.sql) : CREATE TABLE film (ID_film Titre Annee ID_Realisateur NUMBER(10) NOT NULL, VARCHAR (30), NUMBER(4), NUMBER(10));
Voici un programme qui se connecte et recherche le lm did 1. Bien entendu les numros en n de ligne sont destins aux commentaires. #include <stdio.h>
6.1. INTERFAAGE AVEC LE LANGAGE C
88
EXEC SQL INCLUDE sqlca; typedef char asc31[31]; int main (int argc, char* argv[]) { EXEC SQL BEGIN DECLARE SECTION; EXEC SQL TYPE asc31 IS STRING(31) REFERENCE; int ora_id_film, ora_id_mes, ora_annee; char user_id = /; asc31 ora_titre; short vi1, vi2, vi3; EXEC SQL END DECLARE SECTION; EXEC SQL WHENEVER SQLERROR goto sqlerror; EXEC SQL CONNECT :user_id; ora_id_film = 1; ora_id_mes = 0; ora_annee = 0; strcpy (ora_titre,""); EXEC SQL SELECT titre, annee, id_realisateur INTO :ora_titre:vi1, :ora_annee:vi2, :ora_id_mes:vi3 FROM film WHERE id_film = 1; printf ("Titre : %s Annee : %d Id mes %d ora_titre, ora_annee, ora_id_mes); \n",
(1) (2)
(3) (2)
(2) (4) (3) (5) (6) (7)
(8)
sqlerror: if (sqlca.sqlcode != 0) fprintf (stderr,"Erreur NO %d : %s\n", sqlca.sqlcode, sqlca.sqlerrm.sqlerrmc); }
(9)
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 lien avec les librairies pertinentes. Voici les commentaires pour chaque partie du programme ci-dessus. 1. cette ligne est spcique Oracle aui 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 INCLUDE. 2. Le principal 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 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.
89
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 suivi de la variable indicatrice. Attention le SGBD gnre une erreur si on lit une valeur nulle sans utiliser de variable indicatrice. 9. Gestion des erreurs : le champ sqlcode de la structure sqlca et mis jour aprs chaque ordre SQL. Quand il vaut 0, cest quon na pas rencontr derreur. La valeur 1403 (spcique Oracle) indique quaucune ligne na t trouve. Toute valeur ngative indique un erreur, auquel cas le message se trouve dans sqlca.sqlerrm.sqlerrmc. A peu prs lessentiel de ce qui est sufsant 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, jusqua EXEC SQL WHENEVER SQLERROR ... */ 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; 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 ... */
90
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 sparer le code grant les accs la base du code implantant lapplication proprement dite. Quelques suggestions sont donnes dans la section suivante.
6.1.2 Dveloppement en C/SQL

La recherche dinformation dans une table est une bonne occasion disoler une partie bien spcique du code en crant une fonction charge daccder cette table, de vrier la validit des donnes extraites de la base, deffectuer les conversions ncessaires, 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 les stratgies qui me semblent les plus 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 effectue 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 ... /* 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 */
91
*/
Donc la fonction appelante ne voit rien de linterface SQL et peut se consacrer uniquement la manipulation des donnes. Recherche par intervalle On peut suivre peu prs les mmes principes, ceci prs quil faut : 1. Passer en paramtre les critres de recherche. 2. Grer louverture et la fermeture 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 variable 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 effectue 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 } }

Voici comment on utilise cette fonction. Film film; int cle_min, cle_max; ... while (BoucleFilms (&film, cle_min, cle_max)) { .... }
92
Notez quavec lutilisation combine des fonctions et des structures, non seulement on clarie beaucoup le code, mais on rend trs facile lajout dune nouvelle donne. Il suft de modier la structure et limplantation de la fonction de lecture. Tout le reste est inchang.
6.1.3 Autres commandes SQL

Voici, titre de complment, les principales fonctionnalits dccs une base de donnes et leur expression en C/SQL. Validation et annulation 1. Validation : EXEC SQL COMMIT WORK; 2. Anulation : EXEC SQL ROLLBACK WORK; Si on ne fait pas de COMMIT explicite, Oracle effectue un ROLLBACK la n du programme. UPDATE, DELETE, INSERT On utilise ces commandes selon une syntaxe tout fait semblable celle du SELECT. 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 scene est inconnu */ ...
93
6.2 Linterface Java/JDBC

JDBC (acronyme qui signie probablement Java Database Connectivity par analogie avec ODBC), est un ensemble de classes Java qui permet de se connecter une base de donnes distante sur le rseau, et dinterroger cette base an den extraire des donnes. JDBC offre quelques diffrences notables par rapport une solution CGI ou une interface web propritaire et spcique un systme particulier : JDBC offre une intgration trs troite du client et des modules chargs de laccs la base. Cela permet de limiter le trac rseau. JDBC est compltement indpendant de tout SGBD : la mme application peut tre utilise pour accder une base ORACLE, SYBASE, MySQL, etc. Consquences : pas besoin dapprendre une nouvelle API quand on change de systme, et rutilisation totale du code. Enn, JDBC est relativement simple, beaucoup plus simple par exemple que linterface C+SQL propose par les SGBD relationnels. Cette prsentation ne couvre pas tous les aspects de JDBC. Il existe un livre, trs correct, qui donne une prsentation presque exhaustive : George Reese, Database programming with JDBC and Java, OReilly. Une traduction en franais est disponible. Dans la suite de ce texte vous trouverez une description des principes de JDBC, et une introduction ses fonctionnalits, essentiellement base sur des exemples simples utilisant un accs une base MySQL ou ORACLE. Le code est disponible sur le site http://sikkim.cnam.fr/oracle.html.
6.2.1 Principes de JDBC

Lutilisation de JDBC se fait dans le cadre de code Java. Ce peut tre un programme classique (voir lexemple ci-dessous) ou une applet destine tre transfre sur un site client via le Web. Le client peut alors interroger une ou plusieurs bases distantes au travers du rseau : ce dernier aspect est le plus original et le plus intressant.
DriverManager Connexion ORACLE Requetes SQL Connexion SYBASE Driver ORACLE Driver SYBASE
Serveur ORACLE
Reseau
Serveur SYBASE
Applet Java avec JDBC
Les SGBD serveurs
F IG . 6.1 Mise en uvre des drivers JDBC
La gure 6.1 montre les couches logicielles utilises lors dune connexion distance des bases de donnes. Lapplet comprend du code java standard, et une partie base sur les classes JDBC qui permet deffectuer des requtes SQL. Le dialogue avec la base distante se fait par lintermdiaire dune connexion, qui elle-mme utilise les services dun driver. Le driver communique avec un serveur sur la machine hbergeant la base de donnes.
6.2. LINTERFACE JAVA/JDBC

Connexion
94
Quand une requte doit tre excute, elle le fait par lintermdiaire dune connexion. Une connexion est un objet Java de la classe Connection qui est charg de dialoguer avec une base de donnes. Dans le cas o on souhaite accder plusieurs bases de donnes, comme montr sur la gure 6.1, il faut autant dobjets Connection. Une connexion correspond la notion de transaction : on effectue des requtes ou des mises--jour que lon valide ou annule ensuite. On peut donc ouvrir plusieurs connexions sur une mme base si on souhaite grer plusieurs transactions simultanment. Drivers Quand on veut tablir une connexion avec une base distante, on doit passer par lintermdiaire dun driver. Le driver est la partie de JDBC qui est spcique un SGBD particulier comme ORACLE ou SYBASE. Le driver ORACLE sait comment dialoguer avec un serveur ORACLE, mais est incapable dchanger des donnes avec un serveur SYBASE. Pour accder un SGBD particulier, il suft dinstancier un object de la classe Driver propre ce SGBD. Ce nest pas en contradiction avec lindpendance du code Java. Tous les drivers ont la mme interface et sutilisent de la mme faon. On peut, de manire totalement dynamique (par exemple au moment de lexcution de lapplet) choisir la base laquelle on veut accder, et instancier le driver correspondant. Il existe plusieurs types de drivers. Le choix dpend de lutilisation de JDBC. En local, pour une application, ou en distribu, pour une applet. Dans ce dernier cas on utilise un driver de type 3 ou 4 qui ne ncessite pas linstallation dun logiciel spcique sur le client. Le driver utilis dans les exemples ci-dessous et le driver thin MySQL, de type 4, qui communique directement avec le serveur MySQL par des sockets. Serveur Dernier lment de cette architecture : le SGBD doit grer un serveur sur la machine hte, qui reoit, interprte et excute les demandes du driver. Il existe plusieurs solutions possibles, qui dpendent du type de driver utilis. Ce qui importe, du point de vue de lutilisateur dune applet JDBC, cest de connatre le nom de la machine hte, et le numro du port sur lequel le serveur est en coute. Pour MySQL, le port est en gnral le 3306, pour ORACLE le 1521. Dans ce qui suit, nous prendrons lexemple de la machine cartier.cnam.fr hbergeant une base de donnes MySQL dont le nom est Films. Comme son nom lindique, cette base contient des donnes diverses et varies sur des lms, des metteurs en scne, des acteurs, etc. Le serveur est en coute sur le port 3306. Important : quand on utilise une applet, les rgles de scurit Java limitent les possibilits douverture de socket pour dialoguer avec dautres machines. La rgle, par dfaut, est de nautoriser un dialogue par socket quavec la machine qui hberge le serveur httpd. Cela signie ce serveur et le serveur MySQL ou ORACLE doivent tre situs sur le mme hte. Au lieu dutiliser un navigateur, on peut toujours tester une applet avec le programme appletviewer qui ne passe pas par le rseau et nest donc pas soumis aux rgles de scurit Java.

6.2.2 Le plus simple des programmes JDBC

Voici un premier programme JDBC (ce nest pas une applet !). Il se connecte la base, recherche lensemble des lms, et afche les titres lcran. // Dabord on importe le package JDBC import java.sql.*; class films { public static void main (String args []) throws SQLException { Connection conn ;
95
// Chargement du driver de MySQL DriverManager.registerDriver(new org.gjt.mm.mysql.Driver()); // Connection la base try { conn = DriverManager.getConnection ("jdbc:mysql://localhost/Films", "visiteurFilms", "mdpVisiteur"); // Excution de la requte qui ramne les titres des films Statement stmt = conn.createStatement (); ResultSet rset = stmt.executeQuery ("select titre from Film"); // Affichage du rsultat while (rset.next ()) System.out.println (rset.getString (1)); } catch (SQLException e) { System.out.println ("Problme quelque part !!!"); System.out.println (e.getMessage()); } } } Le programme commence par importer le package java.sql.* qui correspond lensemble des classes JDBC 1 . La premire instruction consiste instancier le driver MySQL, et lenregistrer dans le DriverManager. Ce dernier est alors prt utiliser ce driver si on demande une connexion une base MySQL. Cest justement ce que fait linstruction suivante : on instancie un objet de la classe Connection en lui passant en paramtres :
Une URL contenant les coordonnes de la base. Ici on indique le driver MySQL dont le nom est org.gjt.mm.mysql.Driver( le nom de la machine (ici localhost), et le nom de la base (Films). Le format de lURL dpend de chaque driver. Le nom et le mot de passe de lutilisateur qui se connecte la base. Ici, il sagit dun compte qui peut seulement effectuer des lectures dans la base. Il est important de noter que linstanciation du driver et la connexion (ainsi que toutes les requtes qui suivent) peuvent chouer pour quantit de raisons. Dans ce cas une exception de type SQLException est leve. Il est indispensable de placer les instructions dans des blocs try et de grer les exceptions. Il ne reste plus qu effectuer une requte pour tester la connexion. Une requte (au sens large : interrogation ou mise jour) correspond un objet de la classe Statement. Cet objet doit avoir t cr par un objet Connection, ce qui le rattache automatiquement lune des transactions en cours. La mthode executeQuery, comme son nom lindique, excute une requte (dinterrogation) place dans une chane de caractres. Le rsultat est plac dans un objet ResultSet qui, comme son nom lindique encore une fois, contient lensemble des lignes du rsultat. Un objet ResultSet correspond peu prs la notion de curseur employe systmatiquement dans les interfaces entre un langage de programmation et SQL. Un curseur permet de rcuprer les lignes du rsultat la demande, une par une. Ici on appelle simplement la mthode boolenne next qui renvoie true tant que le rsultat na pas t parcouru entirement. Chaque appel next positionne le curseur sur une nouvelle ligne.
1. Attention : ce package nexiste en standard quavec la version 1.1 du JDK. Pour la version 1.0, les classes JDBC font partie du package comprenant le driver, fourni par chaque SGBD.
96
Finalement, la classe ResultSet propose un ensemble de mthodes get*** qui prennent un numro dattribut en entre et renvoient la valeur de cet attribut. Toute erreur de type ou dindice renvoie une SQLException. Il est facile de se convaincre, la lecture de ce petit programme, de la simplicit de JDBC. Lutilisation de quelques classes bien conues permet de saffranchir de tous les dtails techniques fastidieux que lon trouve, par exemple, dans les protocoles dchange C/SQL.
6.2.3 Exemple dune applet avec JDBC

Voici maintenant un exemple complet dune applet JDBC. Le but de cette applet est de permettre la saisie du titre dun lm et de lhoraire souhait, et la partie JDBC se charge de rechercher dans la base les lms qui satisfont les critres de slection. Description de lapplet Lapplet sappelle JdbcFilms et se trouve dans le chier JdbcFilms.java. On inclut la demande dexcution dans une page HTML, dont voici le contenu : <html> <head> <title>Illustration dune Applet JDBC</title> </head> <body> Cette page contient un exemple dune applet permettant de se connecter MySQL (ou ORACLE) par lintermdiaire dun driver JDBC, et dinterroger une base de donnes. <p> Le code source de cette applet est dans <a href="JdbcFilms.java">JdbcFilms.java</a>. Attention au nom du driver, ainsi qu la chane de connexion. <P> Saisissez un titre de film, complet, ou partiel en plaant le caractre %. Indiquez galement un intervalle dannes. <hr> <CENTER><applet code="JdbcFilms" width=700 height=200> </applet> </CENTER> <hr> </BODY> </HTML> Le code Java/JDBC Voici le code complet de lapplet. La majeure partie correspond la cration de linterface graphique. Le code JDBC lui mme est trs rduit.
// Import du package JDBC. import java.sql.*; // Import des packages de base import java.awt.*;

import java.io.*; import java.util.*; public class JdbcFilms extends java.applet.Applet { // La requete String requete; int nb_lignes; // Les boutons pour excuter ou effacer Button bouton_exe, bouton_eff; // Les champs ditables TextField titre_f, anMax, anMin; // La fentre o on affiche le rsultat TextArea fenetre_res; // La connexion la base de donnes Connection conn = null; ResultSet rset; // Linitialisation de lapplet cre linterface graphique public void init () { this.setLayout (new BorderLayout ()); Panel p = new Panel (); p.setLayout (new FlowLayout (FlowLayout.LEFT)); bouton_exe = new Button ("Excuter la requte"); p.add (bouton_exe); bouton_eff = new Button ("Effacer tout"); p.add (bouton_eff); this.add ("North", p); Panel p2 = new Panel(); Label titre_l = new Label ("Titre du film: ", Label.LEFT); p2.add (titre_l); titre_f = new TextField ("%", 20); p2.add (titre_f); Label periode_l = new Label ("Priode. De", Label.LEFT); p2.add (periode_l); anMin = new TextField ("1900", 4); anMax = new TextField ("2100", 4); p2.add(anMin); Label anmax_l = new Label (""); p2.add (anmax_l); p2.add(anMax); this.add ("South", p2); fenetre_res = new TextArea (30, 700); this.add ("Center", fenetre_res); // Chargement du driver, et cration dune connexion try { DriverManager.registerDriver(new org.gjt.mm.mysql.Driver());
97

//DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver()); //conn = DriverManager.getConnection // ("jdbc:oracle:thin:@celsius.cnam.fr:1521:CNAMTP", // "scott", "tiger"); } catch (SQLException e) { fenetre_res.appendText (e.getMessage () + "\n"); } } /** Mthode dclenche quand on appuie sur le bouton */ public boolean action (Event ev, Object arg) { if (ev.target == bouton_exe) { try { // Cration de la requte conn = DriverManager.getConnection ("jdbc:mysql://cartier.cnam.fr/Films", "visiteurFilms", "mdpVisiteur"); Statement stmt = conn.createStatement (); requete = "select titre, annee, codePays, prenom, + " from Film f, Artiste a " + " where titre LIKE " + titre_f.getText() + " and f.idMES = a.id " + " and annee between " + anMin.getText() + " and " + anMax.getText(); // Execution de la requte nb_lignes =0; rset = stmt.executeQuery (requete); // Affichage du rsultat while (rset.next ()) { fenetre_res.appendText ( "Film: " + rset.getString (1) + ", " + rset.getString (2) + ", " + rset.getString (3) + " Ralis par " + rset.getString (4) + " " + rset.getString (5) + "\n"); nb_lignes++; } if (nb_lignes == 0) fenetre_res.appendText ( "Rien trouv pour les films " + titre_f.getText() + " et la priode " + anMin.getText() + "/" + anMax.getText()); } catch (Exception e) { // Caramba: pb quelque part fenetre_res.appendText ("Erreur rencontre !\n"); nom"
98

fenetre_res.appendText (e.getMessage () + "\n"); } return true; } else if (ev.target == bouton_eff) { fenetre_res.setText (" "); titre_f.setText("%"); anMin.setText ("1900"); anMax.setText ("2100"); return true; } else return false; } }
99
100
101
Deuxime partie
Aspects systmes
CHAPITRE 7. TECHNIQUES DE STOCKAGE
103
Chapitre 7
Techniques de stockage
Sommaire
7.1 Stockage de donnes . . . . . . . . 7.1.1 Supports . . . . . . . . . . . 7.1.2 Fonctionnement dun disque 7.1.3 Optimisations . . . . . . . . 7.1.4 Technologie RAID . . . . . Fichiers . . . . . . . . . . . . . . . 7.2.1 Enregistrements . . . . . . . 7.2.2 Blocs . . . . . . . . . . . . 7.2.3 Organisation dun chier . . Oracle . . . . . . . . . . . . . . . . 7.3.1 Fichiers et blocs . . . . . . . 7.3.2 Les tablespaces . . . . . . . 7.3.3 Cration des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 104 105 107 110 112 113 115 118 120 121 123 127
7.2
7.3
Une base de donnes est constitue, matriellement, dun ou plusieurs chiers volumineux stocks sur un support non volatile. Le support le plus couramment employ est le disque magntique ( disque dur ) qui prsente un bon compromis en termes de capacit de stockage, de prix et de performance. Il y a deux raisons principales lutilisation de chiers. Tout dabord il est courant davoir affaire des bases de donnes dont la taille dpasse de loin celle de la mmoire principale. Ensuite et cest la justication principale du recours aux chiers, mme pour des bases de petite taille une base de donnes doit survivre larrt de lordinateur qui lhberge, que cet arrt soit normal ou d un incident matriel. Laccs des donnes stockes sur un priphrique, par contraste avec les applications qui manipulent des donnes en mmoire centrale, est une des caractristiques essentielles dun SGBD. Elle implique notamment des problmes potentiels de performance puisque le temps de lecture dune information sur un disque est considrablement plus lev quun accs en mmoire principale. Lorganisation des donnes sur un disque, les structures dindexation mises en uvre et les algorithmes de recherche utiliss constituent donc des aspects trs importants des SGBD. Un bon systme se doit dutiliser au mieux les techniques disponibles an de minimiser les temps daccs. Il doit aussi offrir ladministrateur des outils de paramtrage et de contrle qui vont lui permettre dexploiter au mieux les ressources matrielles et logicielles dun environnement donn. Dans ce chapitre nous dcrivons les techniques de stockage de donnes et leur transfert entre les diffrents niveaux de mmoire dun ordinateur. Dans une premire partie nous dcrivons les aspects matriels lies au stockage des donnes par un ordinateur. Nous dtaillons successivement les diffrents types de mmoire utilises, en insistant particulirement sur le fonctionnement des disques magntiques. Nous abordons ensuite les mcanismes de transfert dun niveau de mmoire un autre, et leur optimisation. La deuxime partie de ce chapitre est consacre lorganisation des donnes sur disque. Nous y abordons les notions denregistrement, de bloc et de chier, ainsi que leur reprsentation physique.

7.1. STOCKAGE DE DONNES
104
7.1 Stockage de donnes

Un systme informatique offre plusieurs mcanismes de stockage de linformation, ou mmoires. Ces mmoires se diffrencient par leur prix, leur rapidit, le mode daccs aux donnes (squentiel ou par adresse) et enn leur durabilit. Les mmoires volatiles perdent leur contenu quand le systme est interrompu, soit par un arrt volontaire, soit cause dune panne. Les mmoires non volatiles, commes les disques ou les bandes magntiques, prservent leur contenu mme en labsence dalimentation lectrique.
7.1.1 Supports
Dune manire gnrale, plus une mmoire est rapide, plus elle est chre et consquence directe plus sa capacit est rduite. Les diffrentes mmoires utilises par un ordinateur constituent donc une hirarchie (gure 7.1), allant de la mmoire la plus petite mais la plus efcace la mmoire la plus volumineuse mais la plus lente. 1. la mmoire cache est utilise par le processeur pour stocker ses donnes et ses instructions ; 2. la mmoire vive, ou mmoire principale stocke les donnes et les processus constituant lespace de travail de la machine ; toute donne ou tout programme doit dabord tre charg en mmoire principale avant de pouvoir tre trait par un processeur ; 3. les disques magntiques constituent le principal priphrique de type mmoire ; ils offrent une grande capacit de stockage tout en gardant des accs en lecture et en criture relativement efcaces ; 4. enn les bandes magntiques sont des supports trs conomiques mais leur lenteur les destine plutt aux sauvegardes.
Processeur Mmoire cache Mmoire vive Disque Bandes
Mmoire primaire (volatile) Mmoire secondaire Mmoire tertiaire
F IG . 7.1 Hirarchie des mmoires
La mmoire vive et les disques sont les principaux niveaux considrer pour des applications de bases de donnes. Une base de donnes est peu prs toujours place sur disque, pour les raisons de taille et de persistance dj voques, mais les donnes doivent imprativement tre places en mmoire vive pour tre traites. Dans lhypothse (raliste) o seule une petite fraction de la base peut rsider en mmoire centrale, un SGBD doit donc en permanence effectuer des transferts entre mmoire principale et mmoire secondaire pour satisfaire les requtes des utilisateurs. Le cot de ces transferts intervient de manire prpondante dans les performances du systme. La technologie voluant rapidement, il est dlicat de donner des valeurs prcises pour la taille et les temps daccs des diffrentes mmoires. Le tableau 7.1 propose quelques ordres de grandeur. On peut retenir quen 2001, un ordinateur est quip de quelques centaines de mgaoctets de mmoire vive (typiquement 256 Mo lheure o ces lignes sont crites) et que les disques stockent quelques gigaoctets (typiquement 6 10 Go). En contrepartie, le temps daccs une information en mmoire vive est de lordre de 10 nanosecondes ( ) tandis que le temps daccs sur un disque est de lordre de 10 millisecondes ( ), ce qui reprsente un ratio approximatif de 1 000 000 entre les performances respectives de ces deux supports ! Il est clair dans ces conditions que le systme doit tout faire pour limiter les accs au disque.


Type mmoire Mmoire cache Mmoire principale Mmoire secondaire (disque) Mmoire tertiaire (bande/CD) Taille (en Mo) Env. 1 Mo Mo (Gygaoctets) (Traoctets) Temps daccs (secondes) (10 nanosec.) (10-100 nanosec.) (10 millisec.) 1 seconde
105
TAB . 7.1 Caractristiques des diffrentes mmoires
7.1.2 Fonctionnement dun disque

Une disque est une surface circulaire magntise capable denregistrer des informations numriques. La surface magntise peut tre situe dun seul ct ( simple face ) ou des deux cts ( simple face ) du disque. Les disques sont diviss en secteurs, un secteur constituant la plus petite surface dadressage. En dautres termes, on sait 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. Dispositif La petite information stocke sur un disque est un bit qui peut valoir 0 ou 1. Les bits sont groups par 8 pour former des octets, et une suite doctets forme un cercle ou piste sur la surface du disque. Un disque est entran dans un mouvement de rotation rgulier par un axe. Une tte de lecture (deux si le disque est double-face) vient se positionner sur une des pistes du disque et y lit ou crit les donnes. Le nombre minimal doctets lus par une tte de lecture est physiquement dni par la taille dun secteur (en gnral 512 octets). Cela tant le systme dexploitation peut choisir, au moment de linitialisation du disque, de xer une unit dentre/sortie 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.
piste blocs axe bras

disque cylindre tte de lecture Contrleur disque donnes
disque rotation dplacement des ttes
F IG . 7.2 Un disque magntique
Toute lecture ou toute criture sur les disques seffectue par blocs. Mme si la lecture ne concerne quune donne occupant 4 octets, tout le bloc contenant ces 4 octets sera transmis en mmoire centrale. Cette caractristique est fondamentale pour lorganisation des donnes sur le disque. Un des objectifs du SGBD est de faire en sorte que quand il est ncessaire de lire un bloc de 4096 octets pour accder un entier de 4 octets, les 4094 octets constituant le reste du bloc ont de grandes chances dtre utiles court terme et se trouveront donc dj charge en mmoire centrale quand le systme en aura besoin. Cette motivation est la base du mcanisme de regroupement qui fonde, notamment, les structures dindex et de hachage.

106
La tte de lecture nest pas entrane dans le mouvement de rotation. Elle se dplace dans un plan xe qui lui permet de se rapprocher ou de sloigner de laxe de rotation des disques, et daccder une des pistes. Pour limiter le cot de lensemble de ce dispositif et augmenter la capacit de stockage, les disques sont empils et partagent le mme axe de rotation (voir gure 7.2). Il y a autant de ttes de lectures que de disques (deux fois plus si les disques sont double face) et toutes les ttes sont positionnes solidairement dans leur plan de dplacement. tout moment, les pistes accessibles par les ttes sont donc les mmes pour tous les disques de la pile, ce qui constitue une contrainte dont il faut savoir tenir compte quand on cherche optimiser le placement des donnes. Lensemble des pistes accessibles un moment donn constitue le cylindre. La notion de cylindre correspond donc toutes les donnes disponibles sans avoir besoin de dplacer les ttes de lecture. Enn le dernier lment du dispositif est le contrleur qui sert dinterface avec le systme dexploitation. Le contrleur reoit du systme des demandes de lecture ou dcriture, et les transforme en mouvements appropris des ttes de lectures, comme expliqu ci-dessous. Accs aux donnes Un disque est une mmoire accs direct. Contrairement une bande magntique par exemple, il est possible daccder un information situe nimporte o sur le disque sans avoir parcourir squentiellement tout le support. Laccs direct est fond sur une adresse donne chaque bloc au moment de linitialisation du disque par le systme dexploitation. Cette adresse est gnralement compose des trois lments suivants : 1. le numro du disque dans la pile ou le numro de la surface si les disques sont double-face ; 2. le numro de la piste ; 3. le numro du bloc sur la piste. La lecture dun bloc, tant donn 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 xe, cest le disque qui tourne) ; transfert du bloc. La dure dune opration de lecture est donc la somme des temps consacrs chacune des 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 peu devenir important quand des milliers de blocs doivent tre lus. Le mcanisme dcriture est peu prs semblable la lecture, mais peu prendre un peu plus de temps si le contrleur vrie que lcriture sest faite correctement. Le tableau 7.2 donne les spcications dun disque en 2001, telles quon peut les trouver sur le site de nimporte quel constructeur (ici Seagate, www.seagate.com). Les chiffres donnent un ordre de grandeur pour les performances dun disque, tant bien entendu que les disques destins aux serveurs sont beaucoup plus performants que ceux destins aux ordinateurs personnels. Le modle donn en exemple dans le tableau 7.2 appartient au mileu de gamme. Le disque comprend 17 783 secteurs de 512 octets chacun, la multiplication des deux chiffres donnant bien la capacit totale de 9,1 Go. Les secteurs tant rpartis sur 3 disques double-face, ll y a donc secteurs par surface. Le nombre de secteurs par piste nest pas constant, car les pistes situes prs de laxe sont bien entendu beaucoup plus petite que elles situes prs du bord du disque. On ne peut, partir des spcications, que calculer le nombre moyen de secteurs par piste, qui est gal . On peut donc estimer quune piste stocke en moyenne octets. Ce chiffre donne le nombre doctets qui peuvent tre lus sans dlai de latence ni dlai de positionnement. Ce quil faut surtout noter, cest que les temps donns pour le temps de latence et le dlai de rotation ne sont que des moyennes. Dans le meilleur des cas, les ttes sont positionnes sur la bonne piste, et le bloc lire est celui qui arrive sous la tte de lecture. Le bloc peut alors tre lu directement, avec un dlai rduit au temps de transfert.


Caractristique Capacit Taux de transfert Cache Nbre de disques Nbre de ttes Nombre total secteurs (512 octets) Nombre de cylindres Vitesse de rotation Dlai de latence Temps de positionnement moyen Dplacement de piste piste Performance 9,1 Go 80 Mo par seconde 1 Mo 3 6 17 783 438 9 772 10 000 rpm (rotations par minute) En moyenne 3 ms 5.2 ms 0.6 ms
107
TAB . 7.2 Spcications du disque Cheetah 18LP (source www.seagate.com) Ce temps de transfert peut tre considr comme ngligeable dans le cas dun bloc unique, comme le montre le raisonnement qui suit, bas sur les performances du tableau 7.2. Le disque effectue 10000 rotations par minute, ce qui correspond 166,66 rotations par seconde, soit une rotation toutes les 0,006 secondes (6 ms). Cest le temps requis pour lire une piste entirement. Cela donne galement le temps moyen de latence de 3 ms. Pour lire un bloc sur une piste, il faudrait tenir compte du nombre exact de secteurs, qui varie en fonction de la position exacte. En prenant comme valeur moyenne 303 secteurs par piste, et une taille de bloc gale 4 096 soit huit secteurs, on obtient le temps de transfert moyen pour un bloc :
Le temps de transfert ne devient signicatif que quand on lit plusieurs blocs conscutivement. Notez quand mme que les valeurs obtenues restent beaucoup plus leves que les temps daccs en mmoire principale qui svaluent en nanosecondes. Dans une situation moyenne, la tte nest pas sur la bonne piste, et une fois la tte positionne (temps moyen 5.2 ms), il faut attendre une rotation partielle pour obtenir le bloc (temps moyen 3 ms). Le temps de lecture est alors en moyenne de 8.2 ms, si on ignore le temps de transfert.
7.1.3 Optimisations
Maintenant que nous avons une ide prcise du fonctionnement dun disque, il est assez facile de montrer que pour un mme volume de donnes, le temps de lecture peut varier considrablement en fonction de facteurs tels que le placement sur le disque, lordre des commandes dentres/sorties ou la prsence des donnes dans une mmoire cache. Toutes les techniques permettant de rduire le temps pass accder au disque sont utilises intensivement par les SGBD qui, rptons-le, voient leurs performances en grande partie conditionns par ces accs. Nous tudions dans cette section les principales techniques doptmisation mises en uvre dans une architecture simple comprenant un seul disque et un seul processeur. Nous verrons dans la partie suivante consacre la technologie RAID, comment on peut tirer parti de lutilisation de plusieurs disques. Regroupement Prenons un exemple simple pour se persuader de limportance dun bon regroupement des donnes sur le disque : le SGBD doit lire 5 chanes de caractres de 1000 octets chacune. Pour une taille de bloc gale 4096 octets, deux blocs peuvent sufre. La gure 7.3 montre deux organisations sur le disque. Dans la premire chaque chane est place dans un bloc diffrent, et les blocs sont rpartis alatoirement sur les pistes du disque. Dans la seconde organisation, les chanes sont rassembls dans deux blocs qui sont conscutifs sur une mme piste du disque. La lecture dans le premier cas implique 5 dplacements des ttes de lecture, et 5 dlais de latence ce qui donne un temps de ms. Dans le second cas, on aura un dplacement, et un dlai de latence pour la lecture du premier bloc, mais le bloc suivant pourra tre lu instantanment, pour un temps total de 8,2 ms.
108
(a)
(b)
F IG . 7.3 Mauvaise et bonne organisation sur un disque
Les performances obtenues sont dans un rapport de 1 5, le tempsminimal sobtenant en combinant deux optimisations : regroupement et contigut. Le regroupement consiste placer dans le mme bloc des donnes qui ont de grandes chances dtres lues au mme moment. Les critres permettant de dterminer le regroupement des donnes constituent un des fondements des structures de donnes en mmoire secondaire qui seront tudies par la suite. Le placement dans des blocs contigus est une extension directe du principe de regroupement. Il permet deffectuer des lectures squentielles qui, comme le montre lexemple ci-dessus, sont beaucoup plus performantes que les lectures alatoires car elles vitent des dplacements de ttes de lecture. Plus gnralement, le gain obtenu dans la lecture de deux donnes et est dautant plus important que les donnes sont proches , sur le disque, cette proximit tant dnie comme suit, par ordre dcroissant :
le niveau de proximit suivant est obtenu quand les donnes sont places dans deux blocs conscutifs ; quand les donnes sont dans deux blocs situs sur la mme piste du mme disque, elles peuvent tre lues par la mme tte de lecture, sans dplacement de cette dernire, et en une seule rotation du disque ; ltape suivante est le placement des deux blocs dans un mme cylindre, qui vite le dplacement des ttes de lecture ; enn si les blocs sont dans deux cylindres distincts, la proximit est dnie par la distance (en nombre de pistes) parcourir. Les SGBD essaient doptimiser la proximit des donnes au moment de leur placement sur le disque. Une table par exemple devrait tre stocke sur une mme piste ou, dans le cas o elle occupe plus dune piste, sur les pistes dun mme cylindre, an de pouvoir effectuer efcacement un parcours squentiel. Pour que le SGBD puisse effectuer ces optimisations, il doit se voir coner, la cration de la base, un espace important sur le disque dont il sera le seul grer lorganisation. Si le SGBD se contentait de demander au systme dexploitation de la place disque quand il en a besoin, le stockage physique obtenu serait extrmement fragment. Squencement En thorie, si un chier occupant blocs est stock contiguement sur une mme piste, la lecture squentielle de ce chier sera en ignorant le temps de transfert approximativement fois plus efcace que si tous les blocs sont rpartis alatoirement sur les pistes du disque. Cet analyse doit cependant tre relativise car un systme est souvent en situation de satisfaire simultanment plusieurs utilisateurs, et doit grer leurs demandes concuramment. Si un utilisateur demande la lecture du chier tandis que lutilisateur demande la lecture du chier , le systme alternera probablement les lectures des
la proximit maximale est obtenue quand ensembles ;
et
sont dans le mme bloc : elles seront alors toujours lues

Mmoire tampon L(116), L(223), L(118), L(224), L(117) L(117) L(223) L(118) L(224) L(116)
109
Contrleur disque
L(116), L(117), L(118), L(223), L(224) Squenceur
F IG . 7.4 Squencement des entres/sorties
blocs des deux chiers. Mme sils sont tous les deux stocks squentiellement, des dplacements de tte de lecture interviendront alors et minimiseront dans une certaine mesure cet avantage. Le systme dexploitation, ou le SGBD, peuvent rduire cet inconvnient en conservant temporairement les demandes dentres/sorties dans une zone tampon (cache) et en rorganisant (squencement) lordre des accs. La gure 7.4 montre le fonctionnement dun squenceur. Un ensemble dordres de lectures est reu, L(1-16) dsignant par exemple la demande de lecture du bloc 16 sur la piste 1. On peut supposer sur cet exemple que deux utilisateurs effectuent sparment des demandes dentre/sortie qui simbriquent quand elles sont transmises vers le contrleur. Pour viter les accs alatoires qui rsultent de cette imbrication, les demandes daccs sont stockes temporairement dans un cache. Le squenceur les trie alors par piste, puis par bloc au sein de chaque piste, et transmet la liste ordonne au contrleur du disque. Dans notre exemple, on se place donc tout dabord sur la piste 1, et on lit squentiellement les blocs 16, 17 et 18. Puis on passe la piste 2 et on lit les blocs 23 et 24. Nous laissons au lecteur, titre dexercice, le soin de dterminer le gain obtenu. Une technique systmatique pour systmatiser cette stratgie est celle dite de lascenseur . Lide est que les ttes de lecture se dplacent rgulirement du bord de la surface du disque vers laxe de rotation, puis reviennent de laxe vers le bord. Le dplacement seffectue piste par piste, et chaque piste le squenceur transmet au contrleur les demandes dentres/sorties pour la piste courante. Cet algorithme rduit au maximum de temps de dplacement des ttes puisque ce dplacement seffectue systmatiquement sur la piste adjacente. Il est particulirement efcace pour des systmes avec de trs nombreux processus demandant chacun quelques blocs de donnes. En revanche il peut avoir des effets assez dsagrables en prsence de quelques processus gros consommateurs de donnes. Le processus qui demande des blocs sur la piste 1 alors que les ttes viennent juste de passer la piste 2 devra attende un temps respectable avant de voir sa requte satisfaite. Mmoire tampon La dernire optimisation, trs largement utilise dans tous les SGBD, est lutilisation de mmoires tampon, ou buffer. Un buffer est un ensemble de blocs en mmoire principale qui sont des copies des blocs sur le disque. Quand le systme demande accder un bloc, une premire inspection a lieu dans le buffer. Si le bloc sy trouve dj, une lecture a t vite. Sinon on effectue la lecture et on stocke la page dans le buffer. Lide est donc simplement de maintenir en mmoire principale une copie aussi large que possible du disque, mme si une grande partie des blocs mis ainsi dans un buffer nest pas directement utile. Une part importante du paramtrage et de ladministration dune base de donnes consiste spcier quelle est la part de la mmoire disponible qui peut tre attribue en permanence au SGBD. Plus cette mmoire est importante, et plus il sera possible dy conserver une partie signicative de la base, avec des gains importants en terme de performance. Quand il reste de la place dans les buffers, on peut lutiliser en effectuant des lectures en avance (read ahead, ou prefetching). Une application typique de ce principe est donne par la lecture dune table. Comme nous le verrons au moment de ltude des algorithmes de jointure, il est frquent davoir lire une table squentiellement, bloc bloc. Il sagit dun cas o, mme si un moment donn on na besoin que dun ou de quelques blocs, on sait que toute la table devra tre parcourue. Il vaut mieux alors, au moment o on effectue une lecture sur une piste, charger en mmoire tous


Gestionnaire de mmoire cache Table de hachage Lecture disque Demande de bloc Mmoire centrale
110
blocs
F IG . 7.5 Mmoire cache
les blocs de la relation, y compris ceux qui ne serviront que dans quelques temps et peuvent tre placs dans un buffer en attendant.
7.1.4 Technologie RAID

Le stockage sur disque est une des fonctionnalits les plus sensibles dun SGBD, et ce aussi bien pour des questions de performances que pour des raisons de scurit. Un dfaillance en mmoire centrale na en effet quun impact limit : au pire les donnes modies mais non encore crites sur disque seront perdues. Si un disque est endommag en revanche, toutes les donnes sont perdues et il faut recourir une sauvegarde. Cela reprsente un risque, une perte dinformation (tout ce qui a t fait depuis la dernire sauvegarde est prvu) et une perte de temps due lindisponibilit du systme pendant la rcuparion de la sauvegarde. Le risque augmente statistiquement avec le nombre de disques utilis. La dure de vie moyenne dun disque (temps moyen avant une panne) tant de lordre dune dizaine danne, le risque de panne pour un disque parmi 100 peut tre grossirement estim 120/100=1,2 mois. Si la dfaillance dun disque entrane une perte de donnes, ce risque peut tre considr comme trop important. La technologie RAID (pour Redundant Array of Independent Disks) a pour objectif principal de limiter les consquences des pannes en rpartissant les donnes sur un grand nombre de disques, et de manire sassurer que la dfaillance de lun des disques nentrane ni perte de donnes, ni mme lindisponibilit du systme. Il existe plusieurs niveaux RAID (de 0 6), chacun correspondant une organisation diffrente des donnes et donc des caractristiques diffrentes. Le niveau 0 est simplement celui du stockage sur un seul disque, avec les risques discuts prcdemment. Nous prsentons ci-dessous les caractristiques des principaux niveaux. Duplication (RAID 1) Le RAID 1 applique une solution brutale : toutes les entres/sorties seffectuent en parallle sur deux disques. Les critures ne sont pas simultanes an dviter quune panne lectrique ne vienne interrompre les ttes de lecture au moment o elles crivent le mme bloc, qui serait alors perdu. Lcriture a donc dabord lieu sur le disque principal, puisque sur le second (dit disque miroir ). Le RAID 1 est coteux puisquil ncessite deux fois plus despace que de donnes. Il permet certaines optimisations en lecture : par exemple la demande daccs un bloc peut tre tre transmise au disque dont la tte de lecture est la plus proche de la piste contenant le bloc. Les performances sont galement amliores en criture car deux demandes de deux processus distincts peuvent tre satisfaites en parallle. En revanche il ny a pas damlioration du taux de transfert puisque les donnes ne sont pas rparties sur les disques. Rpartition et parit (RAID 4) Ce niveau combine deux techniques. La premire consiste traiter les disques comme un seul trs grand disque, et rpartir les donnes sur tous les disques. Lunit de rpartition est le bloc. Si on a 4 disques et des donnes occupant

111
5 blocs, on crira le premier bloc sur le premier disque, le second bloc sur le deuxime disque, et ainsi de suite. Le cinquime bloc est crit sur le premier disque et le cycle recommence. Lavantage de cette rpartition est damliorer les performances en lecture. Si un seul bloc de donnes est demand, une lecture sur un des disques sufra. Si en revanche les 2, 3 ou 4 premiers blocs de donnes sont demands, il sera possible de combiner des lectures sur lensemble des disques. Le temps de rponse est alors celui dun lecture dun seul bloc. Plus gnralement, quand de trs larges volumes doivent tre lus, il est possible de rpartir en parallle la lecture sur les disques, avec un temps de lecture divis par , et un dbit multipli par . Lautre aspect du RAID 4 est une gestion intelligente de la redondance en stockant non pas une duplication des donnes, mais un bit de parit. Lide est la suivante : pour disques de donnes, on va ajouter un disque de contrle qui permettra de rcuprer les donnes en cas de dfaillance de lun (un seul) des disques. On suppose que les disques ont la mme taille et la mme structure (taille de blocs, pistes, etc). chaque bit du disque de contrle peuvent donc tre associs les bits des disques de donnes situs la mme position. Si il y a un nombre pair de 1 parmi ces bit, le bit de parit vaudra 1, sinon il vaudra 0. Exemple 5 Supposons quil y ait 3 disques de donnes, et que le contenu du premier octet de chaque disque soit le suivant : D1: 11110000 D2: 10101010 D3: 00110011 Alors il suft de prendre chaque colonne et de compter le nombre de 1 dans la colonne. La valeur du bit de parit est . Pour la premire colonne on a , et le bit de parit vaut 0. Voici le premier octet du disque de contrle. DC: 01101001 Si on considre les quatre disques dans lexemple prcdent, le nombre de bits 1 pour chaque position est pair. Il y a deux 1 pour la premire et la seconde position, 4 pour la troisime, etc. La reconstruction de lun des disques aprs une panne devient alors trs facile puisquil suft de rtablir la parit en se basant sur les informations des autres disques et du disque de contrle. Supposons par exemple que le disque 2 tombe en panne. On dispose des informations suivantes : D1: 11110000 D3: 00110011 DC: 01101001 On doit affecter des 0 et des 1 aux bits du disque 2 de manire rtablir un nombre pair de 1 dans chaque colonne. Pour la premire position, il faut mettre 1, pour la seconde 0, pour la troisime 1, etc. On reconstitue ainsi facilement la valeur initiale 10101010. Les lectures seffectuent de manire standard, sans tenir compte du disque de contrle. Pour les critures il faut mettre jour le disque de contrle pour tenir compte de la modication des valeurs des bits. Une solution peu lgante est de lire, pour toute criture dun bloc sur un disque, les valeurs des blocs correspondant sur les autres disques, de recalculer la parit et de mettre jour le disque de contrle. Cette solution est tout fait inefcace puisquelle ncessite entres/sorties. Il est nettement prfrable deffectuer le calcul en tenant compte de la valeur du bloc avant la mise jour. En calculant la parit des valeurs avant et aprs mise jour, on obtient un 1 pour chaque bit dont la valeur a chang. Il suft alors de reporter ce changement sur le disque de contrle. Exemple 6 Reprenons lexemple prcdent, avec trois disques D1, D2, D3, et le disque de contrle DC. D1: 11110000 D2: 10101010 D3: 00110011 DC: 01101001

7.2. FICHIERS
112
Supposons que D1 soit mis jour et devienne 10011000. On doit calculer la parit des valeurs avant et aprs mise jour : avant : 11110000 aprs : 10011000 On obtient loctet 01101000 qui indique que les positions 2, 3, et 5 ont t modies. Il suft de reporter ces modications sur le disque de contrle en changeant les 0 en 1, et rciproquement, pour les positions 2, 3 et 5. On obtient nalement le rsultat suivant. D1: 10011000 D2: 10101010 D3: 00110011 DC: 00000001
En rsum le RAID 4 offre un mcanisme de redondance trs conomique en espace, puisque un seul disque supplmentaire est ncessaire quel que soit le nombre de disques de donnes. En contrepartie il ne peut tre utilis dans le cas improbable o deux disques tombent simultanment en panne. Un autre inconvnient possible est la ncessit deffectuer une E/S sur le disque de contrle pour chaque criture sur un disque de donnes, ce qui implique quil y a autant dcritures sur ce disque que sur tous les autres runis. Rpartition des donnes de parit (RAID 5) Dans le RAID 4, le disque de contrle a tendance a devenir le goulot dtranglement du systme puisque quil doit supporter fois plus dcritures que les autres. Le RAID 5 propose de remdier ce problme en se basant sur une remarque simple : si cest le disque de contrle lui-mme qui tombe en panne, il est possible de le reconstituer en fonction des autres disques. En dautres termes, pour la recontruction aprs une panne, la distinction disque de contrle/disque de donnes nest pas pertinente. Do lide de ne pas ddier un disque aux donnes de parit, mais de rpartir les blocs de parit sur les disques. La seule modication apporter par rapport au RAID 5 est de savoir, quand on modie un bloc sur un disque , quel est le disque qui contient les donnes de parit pour ce bloc. Il est possible par exemple de dcider que pour le bloc , cest le disque qui stocke le bloc de parit. Dfaillances simultanes (RAID 6) Le dernier niveau de RAID prend en compte lhypothse dune dfaillance simultane dau moins deux disques. Dans un tel cas linformation sur la parit devient inutile pour reconstituer les disques : si la parit est 0, linformation perdue peut tre soit 00, soit 11 ; si la parit est 1, linformation perdue peut tre 01 ou 10. Le RAID 6 sappuie sur une codication plus puissante que la parit : les codes de Hamming ou les codes de Reed-Solomon. Nous ne prsentons pas ces techniques ici : elles sont dcrites par exemple dans [GUW00]. Ces codes permettent de reconstituer linformation mme quand plusieurs disques subissent des dfaillances, le prix payer tant une taille plus importante que la simple parit, et donc lutilisation de plus de disques de contrles.
7.2 Fichiers
Il nest jamais inutile de rappeler quune 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. La gestion de chier est un aspect commun aux systmes dexploitation et aux SGBD. En thorie le SGBD pourrait sappuyer sur les fonctionnalits du systme dexploitation qui lhbrge, mais cette solution soulve quelques inconvnients 1. il est dlicat, en terme dimplantation, de dpendre de modules qui peuvent varier dun systme lautre ;


Type SMALLINT INTEGER BIGINT FLOAT DOUBLE PRECISION NUMERIC (M, D) DECIMAL (M, D) CHAR(M ) VARCHAR(M ) BIT VARYING DATE TIME DATETIME Taille en octets 2 4 8 4 8 M, (D+2 si M D) M, (D+2 si M D) M L+1 avec L M 8 6 14

113
TAB . 7.3 Types SQL et tailles (en octets) 2. les diteurs de SGBD peuvent ne pas se satisfaire des techniques daccs aux donnes proposes par le systme ; 3. enn les systmes grent en gnral une mmoire tampon qui peut tre gnante pour les SGBD, notamment pour tout ce qui concerne la concurrence daccs (rappelons quun commit doit garantir lcriture des donnes sur le disque). Sauf exception (par exemple MySQL qui a choisi le parti-pris dune simplicit maximale), les SGBD ont donc leur propre module de gestion de chiers et de mmoire cache. Leurs principes gnraux sont dcrits dans ce qui suit.
7.2.1 Enregistrements
Pour le systme dexploitation, un chier est une suite doctets rpartis sur un ou plusieurs blocs. Les chiers grs par un SGBD sont un peu plus structurs. Ils sont constitus denregistrements (records en anglais) qui reprsentent physiquement les entits du SGBD. Selon le modle logique du SGBD, ces entits peuvent tre des n-uplets dans une relation, ou des objets. Nous nous limiterons au premier cas dans ce qui suit. Un n-uplet dans une table relationnelle est constitu dune liste dattributs, chacun ayant un type. ce n-uplet correspond un enregistrement, constitu de champs (eld en anglais). Chaque type dattribut dtermine la taillle du champ ncessaire pour stocker une instance du type. Le tableau 7.3 donne la taille habituelle utilise pour les principaux types de la norme SQL, tant entendu que les systmes sont libres de choisir le mode de stockage. La taille dun n-uplet est, en premire approximation, la somme des tailles des champs stockant ses attributs. En pratique les choses sont un peu plus compliques. Les champs et donc les enregistrements peuvent tre de taille variable par exemple. Si la taille de lun de ces enregistrements de taille variable, augmente au cours dune mise jour, il faut pouvoir trouver un espace libre. Se pose galement la question de la reprsentation des valeurs NULL. Nous discutons des principaux aspects de la reprsentation des enregistrements dans ce qui suit. Champs de tailles xe et variable Comme lindique le tableau 7.3, les types de la norme SQL peuvent tre diviss en deux catgories : ceux qui peuvent tre reprsents par un champ une taille xe, et ceux qui sont reprsents par un champ de taille variable. Les types numriques (entiers et ottants) sont stocks au format binaire sur 2, 4 ou 8 octets. Quand on utilise un type DECIMAL pour xer la prcision, les nombres sont en revanche stocks sous la forme dune chane de caractres. Par exemple un champ de type DECIMAL(12,2) sera stock sur 12 octets, les deux derniers correspondant aux deux dcimales. Chaque octet contient un caractre reprsentant un chiffre. Les types DATE et TIME peuvent tre simplement reprsents sous la forme de chanes de caractres, aux formats respectifs AAAAMMJJ et HHMMSS.

7.2. FICHIERS
114
Le type CHAR est particulier : il indique une chane de taille xe, et un CHAR(5) sera donc stock sur 5 octets. Se pose alors la question : comment est reprsente la valeur Bou ? Il y a deux solutions : on complte les deux derniers caractres avec des blancs ; on complte les deux derniers caractres avec un caractre conventionnel. La convention adopte inue sur les comparaisons puisque dans un cas on a stock Bou (avec deux blancs), et dans lautre Bou sans caractres de terminaison. Si on utilise le type CHAR il est important dtudier la convention adopte par le SGBD. On utilise beaucoup plus souvent le type VARCHAR(n) qui permet de stocker des chanes de longueur variable. Il existe (au moins) deux possibilits : le champ est de longueur , le premier octet contenant un entier indiquant la longueur exacte de la chane ; si on stocke Bou dans un VARCHAR(10), on aura donc 3Bou, le premier octet stockant un 3 au format binaire, les trois octets suivants des caratres B, o et u, et les 7 octets suivants restant inutiliss ;
Noter quen reprsentant un entier sur un octet, on limite la taille maximale dun VARCHAR 255. Une variante qui peut lever cette limite consiste remplacer loctet initial contenant la taille par un caractre de terminaison de la chane (comme en C). Le type BIT VARYING peut tre reprsent comme un VARCHAR, mais comme linformation stocke ne contient pas que des caractres cods en ASCII, on ne peut pas utiliser de caractre de terminaison puisquon ne saurait par le distinguer des caractres de la valeur stocke. On prxe donc le champ par la taille utile, sur 2, 4 ou 8 octets selon la taille maximale autoris pour ce type. On peut utiliser un stockage optimis dans le cas dun type numr dont les instances ne peuvent prendre leur (unique) valeur que dans un ensemble explicitement spci (par exemple avec une clause CHECK). Prenons lexemple de lensemble de valeurs suivant : {valeur1, valeur2, ... valeurN} Le SGBD doit contrler, au moment de laffectation dune valeur un attribut de ce type, quelle appartient bien lensemble numr {valeur1, valeur2, ... valeurN}. On peut alors stocker lindice de la valeur, sur 1 ou 2 octets selon la taille de lensemble numr (au maximum 65535 valeurs pour 2 octets). Cela reprsente un gain despace, notamment si les valeurs consistent en chanes de caractres. En-tte denregistrement De mme que lon prxe un champ de longueur variable par sa taille utile, il est souvent ncessaire de stocker quelques informations complmentaires sur un enregistrement dans un en-tte. Ces informations peuvent tre ; la taille de lenregistrement, sil est de taille variable ; un pointeur vers le schma de la table, pour savoir quel est le type de lenregistrement ; la date de dernire mise jour ; etc On peut galement utiliser cet en-tte pour les valeurs NULL. Labsence de valeur pour un des attributs est en effet dlicate grer : si on ne stocke rien, on risque de perturber le dcoupage du champ, tandis que si on stocke une valeur conventionnelle, on perd de lespace. Une solution possible consiste crer un masque de bits, un pour chaque champ de lenregistrement, et donner chaque bit la valeur 0 si le champ est NULL, et 1 sinon. Ce masque peut tre stock
le champ est de longueur de lespace.
, avec
; ici on ne stocke pas les octets inutiliss, ce qui permet dconomiser
115
dans len-tte de lenregistrement, et on peut alors se permettre de ne pas utiliser despace pour une valeur NULL, tout en restant en mesure de dcoder correctement la chane doctets constituant lenregistrement. Exemple 7 Prenons lexemple dune table Film avec les attributs id de type INTEGER, titre de type VARCHAR(50) et annee de type INTEGER. Regardons la reprsentation de lenregistrement (123, Vertigo, NULL) (donc lanne est inconnue). Lidentiant est stock sur 4 octets, et le titre sur 8 octets, dont un pour la longueur. Len-tte de lenregistrement contient un pointeur vers le schma de la table, sa longueur totale (soit 4 + 8), et un masque de bits 110 indiquant que le troisime champ est NULL. La gure 7.6 montre cet enregistrement : notez quen lisant len-tte, on sait calculer ladresse de lenregistrement suivant.
entte id titre
12 110 1237 v e r t i go pointeur
F IG . 7.6 Exemple dun enregistrement avec en-tte
7.2.2 Blocs
Le stockage des enregistrements dans un chier doit tenir compte du dcoupage en blocs de ce chier. En gnral il est possible de placer plusieurs enregistrements dans un bloc, et on veut viter quun enregistrement chevauche deux blocs. Le nombre maximal denregistrements de taille pour un bloc de taille est donn par o la notation dsigne le plus grand entier infrieur . Prenons lexemple dun chier stockant une table qui ne contient pas dattributs de longueur variable en dautres termes, elle nutilise pas les types VARCHAR ou BIT VARYING. Les enregistrements ont alors une taille xe obtenue en effectuant la somme des tailles de chaque attribut. Supposons que cette taille soit loccurrence 84 octets, et que la taille de bloc soit 4096 octets. On va de plus considrer que chaque bloc contient un en-tte de 100 octets pour stocker des informations comme lespace libre disponible dans le bloc, un chanage avec dautres blocs, etc. On peut donc placer enregistrements dans un bloc. Notons quil reste dans chaque bloc octets inutiliss dans chaque bloc.
Blocs 12
...
Fichier F1 Enregistrements Entte bloc
...
46
F IG . 7.7 Fichier avec blocs et enregistrements
Le transfert en mmoire de lenregistrement 563 de ce chier est simplement effectu en dterminant dans quel bloc il se trouve (soit ), en chargeant le douzime bloc en mmoire centrale et en prenant dans ce bloc lenregistrement. Le premier enregistrement du bloc 12 a le numro , et le dernier enregistrement le numro . Lenregistrement 563 est donc lavant-dernier du bloc, avec pour numro interne le 46 (voir gure 7.7).

# !
7.2. FICHIERS
116
Le petit calcul qui prcde montre comment on peut localiser physiquement un enregistrement : par son chier, puis par le bloc, puis par la position dans le bloc. En supposant que le chier est cod par F1, ladresse de lenregistrement peut tre reprsente par F1.12.46. Il y a beaucoup dautres modes dadressage possibles. Linconvnient dutiliser une adresse physique par exemple est que lon ne peut pas changer un enregistrement de place sans rendre du mme coup invalides les pointeurs sur cet enregistrement (dans les index par exemple). Pour permettre le dplacement des enregistrements on peut combiner une adresse logique qui identie un enregistrement indpendamment de sa localisation. Une table de correspondance permet de grer lassociation entre ladresse physique et ladresse logique (voir gure 7.8). Ce mcanisme dindirection permet beaucoup de souplesse dans lorganisation et la rorganisation dune base puisquil il suft de rfrencer systmatiquement un enregistrement par son adresse logique, et de modier ladresse physique dans la table quand un dplacement est effectu. En revanche il entrane un cot additionnel puisquil faut systmatiquement inspecter la table de correspondance pour accder aux donnes.
F1 12
...
Adresse Adresse logique physique #90887 F1.12.46
46
...
F IG . 7.8 Adressage avec indirection
Une solution intermdiaire combine adressages physique et logique. Pour localiser un enregistrement on donne ladresse physique de son bloc, puis, dans le bloc lui-mme, on gre une table donnant la localisation au sein du bloc ou, ventuellement, dans un autre bloc. Reprenons lexemple de lenregistrement F1.12.46. Ici F1.12 indique bien le bloc 12 du chier F1. En revanche 46 est une identication logique de lenregistrement, gre au sein du bloc. La gure 7.9 montre cet adressage deux niveaux : dans le bloc F1.12, lenregistrement 46 correspond un emplacement au sein du bloc, tandis que lenregistrement 57 a t dplac dans un autre bloc.
Bloc F1.12 46 57
En-tte Espace libre
16
indirection
Enregistrements
F IG . 7.9 Combinaison adresse logique/adresse physique
Noter que lespace libre dans le bloc est situ entre len-tte du bloc et les enregistrements eux-mmes. Cela permet daugmenter simultanment ces deux composantes au moment dune insertion par exemple, sans avoir effectuer de rorganisation interne du bloc.
117
Ce mode didentication offre beaucoup davantages, et est utilis par ORACLE par exemple. Il permet de rorganiser souplement lespace interne un bloc. Enregistrements de taille variable Une table qui contient des attributs VARCHAR ou BIT VARYING est reprsente par des enregistrements de taille variable. Quand un enregistrement est insr dans le chier, on calcule sa taille non pas daprs le type des attributs, mais daprs le nombre rel doctets ncessaires pour reprsenter les valeurs des attributs. Cette taille doit de plus tre stocke au dbut de lemplacement pour que le SGBD puise dterminer le dbut de lenregistrement suivant. Il peut arriver que lenregistrement soit mis jour, soit pour complter la valeur dun attribut, soit pour donner une valeur un attribut qui tait initialement NULL. Dans un tel cas il est possible que la place initialement rserve soit insufsante pour contenir les nouvelles informations qui doivent tre stockes dans un autre emplacement du mme chier. Il faut alors crer un chanage entre lenregistrement initial et les parties complmentaires qui ont d tre cres. Considrons par exemple le scnario suivant, illustr dans la gure 7.10 :
Bloc F1.12 16 46 57 16 Bloc F1.12 46 57 16 Bloc F1.12 46 57
(a) Situation initiale
(b) Aprs agrandissement de lenregistrement 46
(c) Dplacement de lenregistrement 46
F IG . 7.10 Mises jour dun enregistrement de taille variable
1. on insre dans la table Film un lm Marnie , sans rsum ; lenregistrement correspondant est stock dans le bloc F1.12, et prend le numro 46 ; 2. on insre un autre lm, stock lemplacement 47 du bloc F1.12 ; 3. on saperoit alors que le titre exact est Pas de printemps pour Marnie , ce qui peut se corriger avec un ordre UPDATE : si lespace libre restant dans le bloc est sufsant, il suft deffectuer une rorganisation interne pendant que le bloc est en mmoire centrale, rorganisation qui a un cot nul en terme dentres/sorties ; 4. enn on met nouveau lenregistrement jour pour stocker le rsum qui tait rest NULL : cette fois il ne reste plus assez de place libre dans le bloc, et lenregistrement doit tre dplac dans un autre bloc, tout en gardant la mme adresse. Au lieu de dplacer lenregistrement entirement (solution adopte par Oracle par exemple), on pourrait le fragmenter en stockant le rsum dans un autre bloc, avec un chanage au niveau de lenregistrement (solution adopte par MySQL). Le dplacement (ou la fragmentation) des enregistrements de taille variable est videmment pnalisante pour les performances. Il faut effectuer autant de lectures sur le disque quil y a dindirections (ou de fragments), et on peut donc assimiler le cot dune lecture dun enregistrement en parties, fois le cot dun enregistrement compact. Comme nous le verrons plus loin, un SGBD comme Oracle permet de rserver un espace disponible dans chaque bloc pour lagrandissement des enregistrements an dviter de telles rorganisations. Les enregistrements de taille variable sont un peu plus compliqus grer que ceux de taille xe. Les programmes accdant au chier doivent prendre en compte les en-ttes de bloc ou denregistrement pour savoir o commence et o nit un enregistrement donn.

7.2. FICHIERS
118
En contrepartie, un chier contenant des enregistrements de taille variable utilise souvent mieux lespace qui lui est attribu. Si on dnissait par exemple le titre dun lm et les autres attributs de taille variable comme des CHAR et pas comme des VARCHAR, tous les enregistrements seraient de taille xe, au prix de beaucoup despace perdu puisque la taille choisie correspond souvent des cas extrmes rarement rencontrs un titre de lm va rarement jusqu 50 octets.
7.2.3 Organisation dun chier

Les systmes dexploitation organisent les chiers quils grent dans une arborescence de rpertoires. Chaque rpertoire contient un ensemble de chiers identifs de manire unique (au sein du rpertoire) par un nom. Il faut bien distinguer lemplacement physique du chier sur le disque et son emplacement logique dans larbre des rpertoires du systme. Ces deux aspects sont indpendants : il est possible de changer le nom dun chier ou de modier son rpertoire sans que cela affecte ni son emplacement physique ni son contenu. Quest-ce quune organisation de chier ? Du point de vue du SGBD, un chier est une liste de blocs, regroups sur certaines pistes ou rpartis alatoirement sur lensemble du disque et chans entre eux. La premire solution est bien entendu prfrable pour obtenir de bonnes performances, et les SGBD tentent dans la mesure du possible de grer des chiers constitus de blocs conscutifs. Quand il nest pas possible de stocker un chier sur un seul espace contigu (par exemple un seul cylindre du disque), une solution intermdiaire est de chaner entre deux de tels espaces. 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 enregistrements du chier. Cela implique quil y ait peu, ou pas, despace vide dans le chier. Temps. Une bonne organisation doit favoriser les oprations sur un chier. En pratique, en sintresse plus particulirement la recherche dun enregistrement, notamment parce que cette opration conditionne lefcacit de la mise jour et de la destruction. Il ne faut pas pour autant ngliger le cot des insertions. Lefcacit en espace peut tre mesure comme le rapport entre le nombre de blocs utiliss et le nombre minimal de blocs ncessaire. Si, par exemple, il est possible de stocker 4 enregistrements dans un bloc, un stockage optimal de 1000 enregistrements occupera 250 blocs. Dans une mauvaise organisation il ny aura quun enregistrement par bloc et 1000 blocs seront ncessaires. Dans le pire des cas lorganisation autorise des blocs vides et la taille du chier devient indpendante du nombre denregistrements. Il est difcile de garantir une utilisation optimale de lespace tout moment cause des destructions et modications. Une bonne gestion de chier doit avoir pour but entre autres de rorganiser dynamiquement le chier an de prserver une utilisation satisfaisante de lespace. Lefcacit 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 des cas lire tous les blocs du chier pour trouver un enregistrement, ce qui donne une complexit linaire. Certaines organisations permettent deffectuer des recherches en temps souslinaire : arbres-B (temps logarithmique) et hachage (temps constant). Une bonne organisation doit raliser un bon compromis pour les quatres principaux types doprations : 1. insertion dun enregistrement ; 2. recherche dun enregistrement ; 3. mise jour dun enregistrement ; 4. destruction dun enregistrement.
119
Dans ce qui suit nous discutons de ces quatre oprations sur la structure la plus simple qui soit, le chier squentiel (non ordonn). Le chapitre suivant est consacr aux techniques dindexation et montrera comment on peut optimiser les oprations daccs un chier squentiel. Dans un chier squentiel (sequential le ou heap le), les enregistrements sont stocks dans lordre dinsertion, et la premire place disponible. Il nexiste en particulier aucun ordre sur les enregistrements qui pourrait faciliter une recherche. En fait, dans cette organisation, on recherche plutt une bonne utilisation de lespace et de bonnes performances pour les oprations de mise jour. Recherche La recherche consiste trouver le ou les enregistrements satisfaisant un ou plusieurs critres. On peut rechercher par exemple tous les lms parus en 2001, ou bien ceux qui sont parus en 2001 et dont le titre commence par V, ou encore nimporte quelle combinaison boolenne de tels critres. La complexit des critres de slection ninue pas sur le cot de la recherche dans un chier squentiel. Dans tous les cas on doit partir du dbut du chier, lire un par un tous les enregistrements en mmoire centrale, et effectuer ce moment l le test sur les critres de slection. Ce test seffectuant en mmoire centrale, sa complexit peut tre considre comme ngligeable par rapport au temps de chargement de tous les blocs du chier. Quand on ne sait par priori combien denregistrements on va trouver, il faut systmatiquement parcourir tout le chier. En revanche, si on fait une recherche par cl unique, on peut sarrter ds que lenregistrement est trouv. Le cot moyen est dans ce cas gal , tant le nombre de blocs. Si le chier est tri sur le champ servant de critre de recherche, il est possible deffectuer un recherche par dichotomie qui est beaucoup plus efcace. Prenons lexemple de la recherche du lm Scream. Lalgorithme est simple : 1. prendre le bloc au milieu du chier ; 2. si on y trouve Scream la recherche est termine ; 3. sinon, soit les lms contenus dans le bloc prcdent Scream dans lordre lexicographique, et la recherche doit continuer dans la partie droite, du chier, soit la recherche doit continuer dans la partie gauche ; 4. on recommence ltape (1), en prenant pour espace de rercherche la moiti droite ou gauche du chier, selon le rsultat de ltape 2. Lalgorithme est rcursif et permet de diminuer par deux, chaque tape, la taille de lespace de recherche. Si cette taille, initialement, est de blocs, elle passe ltape 1, ltape 2, et plus gnralement ltape . Au pire, la recherche se termine quand il ny a plus quun seul bloc explorer, autrement dit quand est tel que . On en dduit le nombre maximal dtapes : cest le plus petit tel que , soit , soit . Pour un chier de 100 Mo, un parcours squentiel implique la lecture des 25 000 blocs, alors quune recherche par lectures de blocs !! Le gain est considrable. dichotomie ne demande que Lalgorithme dcrit ci-dessus se heurte cependant en pratique deux obstacles. 1. en premier lieu il suppose que le chier est organis dun seul tenant, et quil est possible chaque tape de calculer le bloc du milieu ; en pratique cette hypothse est trs difcile satisfaire ; 2. en second lieu, le maintien de lordre dans un chier soumis des insertions, suppressions et mises jour est trs difcile obtenir. Cette ide de se baser sur un tri pour effectuer des recherches efcaces est la source de trs nombreuses structures dindex qui seront tudies dans le chapitre suivant. Larbre-B, en particulier, peut tre vu comme une structure rsolvant les deux problmes ci-dessus. Dune part il se base sur un systme de pointeurs dcrivant, chaque tape de la recherche, lemplacement de la partie du chier qui reste explorer, et dautre part il utilise une algorithmique qui lui permet de se rorganiser dynamiquement sans perte de performance.
@ $
5 $
$
$

7.3. ORACLE
Mises jour
120
Au moment o on doit insrer un nouvel enregistrement dans un chier, le problme est de trouver un bloc avec un espace libre sufsant. Il est hors de question de parcourir tous blocs, et on ne peut pas se permettre dinsrer toujours la n du chier car il faut rutiliser les espaces rendus disponibles par les destructions. La seule solution est de garder une structure annexe qui distingue les blocs pleins des autres, et permette de trouver rapidement un bloc avec de lespace disponible. Nous prsentons deux structures possibles. La premire est une liste doublement chane des blocs libres (voir gure 7.11). Quand de lespace se libre dans un bloc plein, on linsre la n de la liste chane. Inversement, quand un bloc libre devient plein, on le supprime de la liste. Dans lexemple de la gure 7.11, en imaginant que le bloc 8 devienne plein, on chainera ensemble les blocs 3 et 7 par un jeu classique de modication des adresses. Cette solution ncessite deux adresses (bloc prcdent et bloc suivant) dans len-tte de chaque bloc, et ladresse du premier bloc de la liste dans len-tte du chier.
F IG . 7.11 Gestion des blocs libres avec liste chane
Un inconvnient de cette structure est quelle ne donne pas dindication sur la quantit despace disponible dans les blocs. Quand on veut insrer un enregistrement de taille volumineuse, on risque davoir parcourir une partie de la liste et donc de lire plusieurs blocs avant de trouver celui qui dispose dun espace sufsant. La seconde solution repose sur une structure spare des blocs du chier. Il sagit dun rpertoire qui donne, pour chaque page, un indicateur O/N indiquant sil reste de lespace, et un champ donnant le nombre doctets (gure 7.12). Pour trouver un bloc avec une quantit despace libre donne, il suft de parcourir ce rpertoire.
libre ? O N O espace adresse 1 123 2 ... 1089 7 7
1 3
F IG . 7.12 Gestion des blocs libres avec rpertoire
Le rpertoire doit lui-mme tre stock dans une ou plusieurs pages associes au chier. Dans la mesure o lon ny stocke que trs peu dinformations par bloc, sa taille sera toujours considrablement moins lve que celle du chier lui-mme, et on peut considrer que le temps daccs au rpertoire est ngligeable compar aux autres oprations.
7.3 Oracle
Le systme de reprsentation physique dOracle est assez riche et repose sur une terminologie qui porte facilement confusion. En particulier les termes de reprsentation physique et reprsentation logique ne sont pas employs dans le sens que nous avons adopt jusqu prsent. Pour des raisons de clart, nous adaptons quand cest ncessaire la terminologie dOracle pour rester cohrent avec celle que nous avons employe prcdemment.

121
Un systme Oracle (une instance dans la documentation) stocke les donnes dans un ou plusieurs chiers. Ces chiers sont entirement attribus au SGBD. Ils sont diviss en blocs dont la taille paramtrable peut varier de 1K 8K. Au sein dun chier des blocs conscutifs peuvent tre regroups pour former des extensions (extent). Enn un ensemble dextensions permettant de stocker un des objets physiques de la base (une table, un index) constitue un segment. Il est possible de paramtrer, pour un ou plusieurs chiers, le mode de stockage des donnes. Ce paramtrage comprend, entre autres, la taille des extensions, le nombre maximal dextensions formant un segment, le pourcentage despace libre laiss dans les blocs, etc. Ces paramtres, et les chiers auxquels il sapplique, portent le nom de tablespace. Nous revenons maintenant en dtail sur ces concepts.
7.3.1 Fichiers et blocs

Au moment de la cration dune base de donnes, il faut attribuer Oracle au moins un chier sur un disque. Ce chier constitue lespace de stockage initial qui contiendra, au dpart, le dictionnaire de donnes. La taille de ce chier est choisie par le DBA, et dpend de lorganisation physique qui a t choisie. On peut allouer un seul gros chier et y placer toutes les donnes et tous les index, ou bien restreindre ce chier initial au stockage du dictionnaire et ajouter dautres chiers, un pour les index, un pour les donnes, etc. Le deuxime type de solution est sans doute prfrable, bien quun peu plus complexe. Il permet notamment, en plaant les chiers sur plusieurs disques, de bien rpartir la charge des contrleurs de disque. Une pratique courante et recommande par Oracle est de placer un chier de donnes sur un disque et un chier dindex sur un autre. La rpartition sur plusieurs disques permet en outre, grce au paramtrage des tablespaces qui sera tudi plus loin, de rgler nement lutilisation de lespace en fonction de la nature des informations donnes ou index qui y sont stockes. Les blocs ORACLE Le bloc est la plus petite unit de stockage gre par ORACLE. La taille dun bloc peut tre choisie au moment de linitialisation dune base, et correspond obligatoirement un multiple de la taille des blocs du systme dexploitation. titre dexemple, un bloc dans un systme comme Linux occupe 1024 octets, et un bloc ORACLE occupe typiquement 4 096 ou 8 092 octets.
Bloc Oracle Entte (adresse du bloc, type du segment) Tables reprsentes dans le bloc Adresses des enregistrements Espace libre Enregistrements
F IG . 7.13 Structure dun bloc Oracle
La structure dun bloc est identique quel que soit le type dinformation qui y est stock. Elle est constitue des cinq parties suivantes (voir gure 7.13) : lentte (header) contient ladresse du bloc, et son type (donnes, index, etc) ; le rpertoire des tables donne la liste des tables pour lesquelles des informations sont stockes dans le bloc ; le rpertoire des enregistrements contient les adresses des enregistrements du bloc ; un espace libre est laiss pour faciliter linsertion de nouveaux enregistrements, ou lagrandissement des enregistrements du bloc (par exemple un attribut NULL auquel on donne une valeur par un UPDATE).
7.3. ORACLE
enn lespace des donnes contient les enregistrements.
122
Les trois premires parties constituent un espace de stockage qui nest pas directement ddi aux donnes (ORACLE le nomme loverhead). Cet espace perdu occupe environ 100 octets. Le reste permet de stocker les donnes des enregistrements. Les paramtres PCTFREE et PCTUSED La quantit despace libre laisse dans un bloc peut tre spcie grce au paramtre PCTFREE, au moment de la cration dune table ou dun index. Par exemple une valeur de 30% indique que les insertions se feront dans le bloc jusqu ce que 70% du bloc soit occup, les 30% restant tant rservs aux ventuels agrandissements des enregistrements. Une fois que cet espace disponible de 70% est rempli, ORACLE considre quaucune nouvelle insertion ne peut se faire dans ce bloc. Notez quil peut arriver, pour reprendre lexemple prcdent, que des modications sur les enregistrements (mise NULL de certains attributs par exemple) fassent baisser le taux doccupation du bloc. Quand ce taux baisse en dessous dune valeur donne par le paramtre PCTUSED, ORACLE considre que le bloc est nouveau disponible pour des insertions. En rsum, PCTFREE indique le taux dutilisation maximal au-del duquel les insertions deviennent interdites, et PCTUSED indique le taux dutilisation minimal en-de duquel ces insertions sont nouveau possibles. Les valeurs de ces paramtres dpendent de lapplication, ou plus prcisment des caractristiques des donnes stockes dans une table particulire. Une petite valeur pour PCTFREE permet aux insertions de remplir plus compltement le bloc, et peut donc mieux exploiter lespace disque. Ce choix peut tre valable pour des donnes qui sont rarement modies. En contrepartie une valeur plus importante de PCTFREE va occuper plus de blocs pour les mmes donnes, mais offre plus de exibilit pour des mises jour frquentes. Voici deux scnarios possibles pour spcier PCTUSED et PCTFREE. Dans le premier, PCTFREE vaut 30%, et PCTUSED 40% (notez que la somme de ces deux valeurs ne peut jamais excder 100%). Les insertions dans un bloc peuvent donc seffectuer jusqu ce que 70% du bloc soit occup. Le bloc est alors retir de la liste des blocs disponibles pour des insertions, et seules des mises jour (destructions ou modications) peuvent affecter son contenu. Si, la suite de ces mises jour, lespace occup tombe en-dessous de 40%, le bloc est nouveau marqu comme tant disponible pour des insertions. Dans ce premier scnario, on accepte davoir beaucoup dexpace innoccup, au pire 60%. Lavantage est que le cot de maintenance de la liste des blocs disponibles pour linsertion est limit pour ORACLE. Dans le second scnario, PCTFREE vaut 10% (ce qui est dailleurs la valeur par dfaut), et PCTUSED 80%. Quand le bloc est plein 90%, les insertions sarrtent, mais elles reprennent ds que le taux doccupation tombe sous 80%. On est assur dune bonne utilisation de lespace, mais le travail du SGBD est plus important (et donc pnalis) puisque la gestion des blocs disponibles/indisponibles devient plus intensive. De plus, en ne laissant que 10% de marge de manuvre pour dventuelles extensions des enregistrements, on sexpose ventuellement la ncessit de chaner les enregistrements sur plusieurs blocs. Enregistrements Un enregistrement est une suite de donnes stocks, quelques variantes prs, comme dcrit dans le tableau 7.3, . Le page 113. Par exemple les donnes de type CHAR(n) sont stockes dans un tableau doctets de longueur premier octet indique la taille de la chane, qui doit donc tre comprise entre 1 et 255. Les octets suivants stockent les caractres de la chanes, complts par des blancs si la longueur de cette dernire est infrieure la taille maximale. Pour les donnes de type VARCHAR(n) en revanche, seuls les octets utiles pour la reprsentation de la chane sont stocks. Cest un cas o une mise jour largissant la chane entrane une rorganisation du bloc. Chaque attribut est prcd de la longueur de stockage. Dans Oracle les valeurs NULL sont simplement reprsentes par une longueur de 0. Cependant, si les derniers attributs dun enregistrement sont NULL, ORACLE se contente de placer une marque de n denregistrement, ce qui permet dconomiser de lespace. Chaque enregistrement est identi par un ROWID, comprenant trois parties : 1. le numro du bloc au sein du chier ; 2. le numro de lenregistrement au sein du bloc ;

3. enn lidentiant du chier.
123
Un enregistrement peut occuper plus dun bloc, notamment sil contient les attributs de type LONG. Dans ce cas ORACLE utilise un chanage vers un autre bloc. Un situation comparable est celle de lagrandissement dun enregistrement qui va au-del de lespace libre disponible. Dans ce cas ORACLE effctue une migration : lenregistrement est dplac en totalit dans un autre bloc, et un pointeur est laiss dans le bloc dorigine pour ne pas avoir modier ladresse de lenregistrement (ROWID). Cette adresse peut en effet tre utilise par des index, et une rorganisation totale serait trop coteuse. Migration et chanage sont bien entendu pnalisants pour les performances. Extensions et segments Une extension est un suite contigu (au sens de lemplacement sur le disque) de blocs. En gnral une extension est affecte un seul type de donnes (par exemple les enregistrements dune table). Comme nous lavons vu en dtail, cette contigut est un facteur essentiel pour lefcacit de laccs aux donnes, puisquelle vite les dplacements des ttes de lecture, ainsi que le dlai de rotation. Le nombre de blocs dans une extension peut tre spci par ladministrateur. Bien entendu des extensions de tailles importante favorisent de bonnes performances, mais il existe des contreparties : 1. si une table ne contient que quelques enregistrements, il est inutile de lui allouer une extension contenant des milliers de blocs ; 2. lutilisation et la rorganisation de lespace de stockage peuvent tre plus difciles pour des extensions de grande taille. Les extensions sont lunit de stockage constituant les segments. Si on a par exemple indiqu que la taille des extensions est de 50 blocs, un segment (de donnes ou dindex) consistera en extensions de 50 blocs chacune. Il existe quatre types de segments : 1. les segments de donnes contiennent les enregistrements des tables, avec un segment de ce type par table ; 2. les segments dindex contiennent les enregistrements des index ; il y a un segment par index ; 3. les segments temporaires sont utiliss pour stocker des donnes pendant lexcution des requtes (par exemple pour les tris) ; 4. enn les segments rollbacks contiennent les informations permettant deffectuer une reprise sur panne ou lannulation dune transaction ; il sagit typiquement des donnes avant modication, dans une transaction qui na pas encore t valide. Une extension initiale est alloue la cration dun segment. De nouvelles extensions sont alloues dynamiquement (autrement dit, sans intervention de ladministrateur) au segment au fur et mesure des insertions : rien ne peut garantir quune nouvelle extension est contigu avec les prcdentes. En revanche une fois quune extension est affecte un segment, il faut une commande explicite de ladministrateur, ou une destruction de la table ou de lindex, pour que cette extension redevienne libre. Quand ORACLE doit crer une nouvelle extension et se trouve dans lincapacit de constituer un espace libre sufsant, une erreur survient. Cest alors ladministrateur daffecter un nouveau chier la base, ou de rorganiser lespace dans les chiers existant.
7.3.2 Les tablespaces

Un tablespace est un espace physique constitu de un (au moins) ou plusieurs chiers. Une base de donnes ORACLE est donc organise sous la forme dun ensemble de tablespace, sachant quil en existe toujours un, cr au moment de linitialisation de la base, et nomm SYSTEM. Ce tablespace contient le dictionnaire de donnes, y compris les procdures stockes, les triggers, etc. Lorganisation du stockage au sein dun tablespace est dcrite par de nombreux paramtres (taille des extensions, nombre maximal dextensions, etc) qui sont donns la cration du tablespace, et peuvent tre modis par la suite.
7.3. ORACLE
124
Cest donc au niveau de tablespace (et pas au niveau du chier) que ladministrateur de la base peut dcrire le mode de stockage des donnes. La cration de plusieurs tablespaces, avec des paramtres de stockage individualiss, offre de nombreuses possibilits : 1. adaptation du mode de stockage en fonction dun type de donnes particulier ; 2. affectation dun espace disque limit aux utilisateurs ; 3. contrle sur la disponibilit de parties de la base, par mise hors service dun ou plusieurs tablespaces ; 4. enn et surtout rpartition des donnes sur plusieurs disques an doptimiser les performances. Un exemple typique est la sparation des donnes et des index, si possible sur des disques diffrents, an doptimiser la charge des contrleurs de disque. Il est galement possible de crer des tablespaces ddies aux donnes temporaires ce qui vite de mlanger les enregistrements des tables et ceux temporairement crs au cours dune opration de tri. Enn un tablespace peut tre plac en mode de lecture, les critures tant interdites. Toutes ces possibilits donnent beaucoup de exibilit pour la gestion des donnes, aussi bien dans un but damliorer les performances que pour la scurit des accs. Au moment de la cration dun tablespace, on indique les paramtres de stockage par dfaut des tables ou index qui seront stocks dans ce tablespace. Lexpression par dfaut signie quil est possible, lors de la cration dune table particulire, de donner des paramtres spciques cette table, mais que les paramtres du tablespace sappliquent si on ne le fait pas. Les principaux paramtres de stockage sont : 1. la taille de lextension initiale (par dfaut 5 blocs) ; 2. la taille de chaque nouvelle extension (par dfaut 5 blocs galement) ; 3. le nombre maximal dextensions, ce qui donne donc, avec la taille des extensions, le nombre maximal de blocs allous une table ou index ; 4. la taille des extensions peut crotre progressivement, selon un ratio indiqu par PCTINCREASE ; une valeur de 50% pour ce paramtre indique par exemple que chaque nouvelle extension a une taille suprieure de 50% la prcdente. Voici un exemple de cration de tablespace. CREATE TABLESPACE TB1 DATAFILE fichierTB1.dat SIZE 50M DEFAULT STORAGE ( INITIAL 100K NEXT 40K MAXEXTENTS 20, PCTINCREASE 20); La commande cre un tablespace, nomm TB1, et lui affecte un premier chier de 50 mgaoctets. Les paramtres de la partie DEFAULT STORAGE indiquent, dans lordre : 1. la taille de la premire extension alloue une table (ou un index) ; 2. la taille de la prochaine extension, si lespace allou la table doit tre agrandi ; 3. le nombre maximal dextensions, ici 20 ; 4. enn chaque nouvelle extension est 20% plus grande que la prcdente.

125
En supposant que la taille dun bloc est 4K, on obtient une premire extension de 25 blocs, une seconde de 10 blocs, une troisime de blocs, etc. Le fait dindiquer une taille maximale permet de contrler que lespace ne sera pas utilis sans limite, et sans contrle de ladministrateur. En contrepartie, ce dernier doit tre prt prendre des mesures pour rpondre aux demandes des utilisateurs quand des messages sont produits par ORACLE indiquant quune table a atteint sa taille limite. Voici un exemple de tablespace dni avec un paramtrage plus souple : dune part il ny a pas de limite au nombre dextensions dune table, dautre part le chier est en mode auto-extension , ce qui signie quil stend automatiquement, par tranches de 5 mgaoctets, au fur et mesure que les besoins en espace augmentent. La taille du chier est elle-mme limite 500 mgaoctets. CREATE TABLESPACE TB2 DATAFILE fichierTB2.dat SIZE 2M AUTOEXTEND ON NEXT 5M MAXSIZE 500M DEFAULT STORAGE (INITIAL 128K NEXT 128K MAXEXTENTS UNLIMITED); Il est possible, aprs la cration dun tablespace, de modier ses paramtres, tant entendu que la modication ne sapplique pas aux tables existantes mais celles qui vont tre cres. Par exemple on peut modier le tablespace TB1 pour que les extensions soient de 100K, et le nombre maximal dextensions port 200. ALTER TABLESPACE TB1 DEFAULT STORAGE ( NEXT 100K MAXEXTENTS 200); Voici quelque-unes des diffrentes actions disponibles sur un tablespace : 1. On peut mettre un tablespace hors-service, soit pour effectuer une sauvegarde dune partie de la base, soit pour rendre cette partie de la base indisponible. ALTER TABLESPACE TB1 OFFLINE; Cette commande permet en quelque sorte de traiter un tablespace comme une sous-base de donnes. 2. On peut mettre un tablespace en lecture seule. ALTER TABLESPACE TB1 READ ONLY; 3. Enn on peut ajouter un nouveau chier un tablespace an daugmenter sa capacit de stockage. ALTER TABLESPACE ADD DATAFILE fichierTB1-2.dat SIZE 300 M; Au moment de la cration dune base, on doit donner la taille et lemplacement dun premier chier qui sera affect au tablespace SYSTEM. chaque cration dun nouveau tablespace par la suite, il faudra crer un chier qui servira despace de stockage initial pour les donnes qui doivent y tre stockes. Il faut bien noter quun chier nappartient qu un seul tablespace, et que, ds le moment o ce chier est cr, son contenu est exlusivement gr par ORACLE, mme si une partie seulement est utilise. En dautres termes il ne faut pas affecter un chier de 1 Go un tablespace destin seulement contenir 100 Mo de donnes, car les 900 Mo restant ne servent alors rien. ORACLE utilise lespace disponible dans un chier pour y crer de nouvelles extensions quand la taille des donnes augmente, ou de nouveaux segments quand des tables ou index sont crs. Quand un chier est plein ou, pour dire les choses plus prcisment, quand ORACLE ne trouve pas assez despace disponible pour crer un nouveau segment ou une nouvelle extension , un message derreur avertit ladministrateur qui dispose alors de plusieurs solutions : crer un nouveau chier, et laffecter au tablespace (voir la commande ci-dessus) ; modier la taille dun chier existant ; enn, permettre un ou plusieurs chiers de crotre dynamiquement en fonction des besoins, ce qui peu simplier la gestion de lespace.

7.3. ORACLE
Comment inspecter les tablespaces
126
ORACLE fournit un certain nombre de vues dans son dictionnaire de donnes pour consulter lorganisation physique dune base, et lutilisation de lespace. La vue DBA_EXTENTS donne la liste des extensions ; La vue DBA_SEGMENTS donne la liste des segments ; La vue DBA_FREE_SPACE permet de mesurer lespace libre ; La vue DBA_TABLESPACES donne la liste des tablespaces ; La vue DBA_DATA_FILES donne la liste des chiers. Ces vues sont gres sous le compte utilisateur SYS qui est rserv ladministrateur de la base. Voici quelques exemples de requtes permettant dinspecter une base. On suppose que la base contient deux tablespace, SYSTEM avec un chier de 50M, et TB1 avec deux chiers dont les tailles repectives sont 100M et 200M. La premire requte afche les principales informations sur les tablespaces. SELECT tablespace_name "TABLESPACE", initial_extent "INITIAL_EXT", next_extent "NEXT_EXT", max_extents "MAX_EXT" FROM sys.dba_tablespaces; TABLESPACE ---------SYSTEM TB1 INITIAL_EXT ----------10240000 102400 NEXT_EXT -------10240000 50000 MAX_EXT ------99 200
On peut obtenir la liste des chiers dune base, avec le tablespace auquel ils sont affects : SELECT file_name, bytes, tablespace_name FROM sys.dba_data_files; FILE_NAME -----------fichier1 fichier2 fichier3 BYTES ---------5120000 10240000 20480000 TABLESPACE_NAME ------------------SYSTEM TB1 TB1
Enn on peut obtenir lespace disponible dans chaque tablespace. Voici par exemple la requte qui donne des informtions statistiques sur les espaces libres du tablespace SYSTEM. SELECT tablespace_name, file_id, COUNT(*) "PIECES", MAX(blocks) "MAXIMUM", MIN(blocks) "MINIMUM", AVG(blocks) "AVERAGE", SUM(blocks) "TOTAL" FROM sys.dba_free_space WHERE tablespace_name = SYSTEM GROUP BY tablespace_name, file_id; TABLESPACE ---------SYSTEM FILE_ID ------1 PIECES -----2 MAXIMUM ------2928 MINIMUM ------115 AVERAGE ------1521.5 SUM -----3043
127
SUM donne le nombre total de blocs libres, PIECES montre la fragmentation de lespace libre, et MAXIMUM donne lespace contigu maximal. Ces informations sont utiles pour savoir sil est possible de crer des tables volumineuses pour lesquelles on souhaite rserver ds le dpart une extension de taille sufsante.
7.3.3 Cration des tables

Tout utilisateur ORACLE ayant les droits sufsants peut crer des tables. Notons que sous ORACLE la notion dutilisateur et celle de base de donnes sont lies : un utilisateur (avec des droits appropris) dispose dun espace permettant de stocker des tables, et tout ordre CREATE TABLE effectu par cet utilisateur cre une table et des index qui appartiennent cet utilisateur. Il est possible, au moment o on spcie le prol dun utilisateur, dindiquer dans quels tablespaces il a le droit de placer des tables, de quel espace total il dispose sur chacun de ces tablespaces, et quel est le tablespace par dfaut pour cet utilisateur. Il devient alors possible dinclure dans la commande CREATE TABLE des paramtres de stockage. Voici un exemple : CREATE TABLE Film (...) PCTFREE 10 PCTUSED 40 TABLESPACE TB1 STORAGE ( INITIAL 50K NEXT 50K MAXEXTENTS 10 PCTINCREASE 25 ); On indique donc que la table doit tre stocke dans le tablespace TB1, et on remplace les paramtres de stockage de ce tablespace par des paramtres spciques la table Film. Par dfaut une table est organise squentiellement sur une ou plusieurs extensions. Les index sur la table sont stocks dans un autre segment, et font rfrence aux enregistrements grce au ROWID. Il est galement possible dorganiser sous forme dun arbre, dune table de hachage ou dun regroupement cluster avec dautres tables. Ces structures seront dcrites dans le chapitre consacr lindexation.
7.3. ORACLE
128
CHAPITRE 8. INDEXATION
129
Chapitre 8
Indexation
Sommaire
8.1 Indexation de chiers . . . . . . . 8.1.1 Index non-dense . . . . . . . 8.1.2 Index dense . . . . . . . . . 8.1.3 Index multi-niveaux . . . . . Larbre-B . . . . . . . . . . . . . . 8.2.1 Prsentation intuitive . . . . 8.2.2 Recherches avec un arbre-B+ Hachage . . . . . . . . . . . . . . . 8.3.1 Principes de base . . . . . . 8.3.2 Hachage extensible . . . . . Les index bitmap . . . . . . . . . . Indexation dans Oracle . . . . . . 8.5.1 Arbres B+ . . . . . . . . . . 8.5.2 Arbres B . . . . . . . . . . . 8.5.3 Indexation de documents . . 8.5.4 Tables de hachage . . . . . . 8.5.5 Index bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 131 133 134 135 135 137 139 140 143 145 146 146 147 147 147 148
8.2
8.3
8.4 8.5
Quand une table est volumineuse, un parcours squentiel est une opration relativement lente et pnalisante pour lexcution des requtes, notamment dans le cas des jointures o ce parcours squentiel doit parfois tre effectu rptitivement. La cration dun index permet damliorer considrablement les temps de rponse en crant des chemins daccs aux enregistrements beaucoup plus directs. Un index permet de satisfaire certaines requtes (mais pas toutes) portant sur un ou plusieurs attributs (mais pas tous). Il ne sagit donc jamais dune mthode universelle qui permettrait damliorer indistinctement tous les types daccs une table. Lindex peut exister indpendamment de lorganisation du chier de donnes, ce qui permet den crer plusieurs si on veut tre en mesure doptimiser plusieurs types de requtes. En contrepartie la cration sans discernement dun nombre important dindex peut tre pnalisante pour le SGBD qui doit grer, pour chaque opration de mise jour sur une table, la rprcussion de cette mise jour sur tous les index de la table. Un choix judicieux des index, ni trop ni trop peu, est donc un des facteurs essentiels de la performance dun systme. Ce chapitre prsente les structures dindex les plus classiques utilises dans les systmes relationnels. Aprs un introduction prsentant les principes de base des index, nous dcrivons en dtail une structure de donnes appele arbre-B qui est la fois simple, trs performante et propre optimiser plusieurs types de requtes : recherche par cl, recherche par intervalle, et recherche avec un prxe de la cl. Le B vient de balanced en anglais, et signie que larbre est quilibr : tous les chemins partant de la racine vers une feuille ont la mme longueur. Larbre B est utilis dans tous les SGBD relationnels.

8.1. INDEXATION DE FICHIERS

titre Vertigo Brazil Twin Peaks Underground Easy Rider Psychose Greystoke Shining Annie Hall Jurasic Park Metropolis Manhattan Reservoir Dogs Impitoyable Casablanca Smoke anne 1958 1984 1990 1995 1969 1960 1984 1980 1977 1992 1926 1979 1992 1992 1942 1995 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
130
TAB . 8.1 La table indexer Une structure concurrente de larbre B est le hachage qui offre, dans certains cas, des performances suprieures, mais ne couvre pas autant doprations. Nous verrons galement dans ce chapitre des structures dindex ddies des donnes non-traditionnelles pour lesquels larbre B nest pas adapt. Ce sont les index bitmap pour les entrepts de donnes, et les index spatiaux pour les donnes gographiques. Pour illustrer les techniques dindexation dune table nous prendrons deux exemples. Exemple 8 Le premier est destin illustrer les structures et les algorithmes sur un tout petit ensemble de donnes, celui de la table Film, avec les 16 lignes du tableau 8.1. Nous ne donnons que les deux attributs titre et anne qui seront utiliss pour lindexation.
Exemple 9 Le deuxime exemple est destin montrer, avec des ordres de grandeur ralistes, lamlioration obtenue par des structures dindex, et les caractristiques, en espace et en temps, de ces structures. Nous supposerons que la table contient 1 000 000 lms, la taille de chaque enregistrement tant de 120 octets. Pour une taille de bloc de 4 096 octets, on aura donc au mieux 34 enregistrements par bloc. Il faut donc 29 412 blocs ( ) occupant un peu plus de 120 Mo (120 471 552 octets, le surplus tant imputable lespace perdu dans chaque bloc). Cest sur ce chier de 120 Mo que nous allons construire nos index.
8.1 Indexation de chiers

Le principe de base dun index est de construire une structure permettant doptimiser les recherches par cl sur un chier. Le terme de cl doit tre compris ici au sens de critre de recherche , ce qui diffre de la notion de cl primaire dune table. Les recherches par cl sont typiquement les slections de lignes pour lesquelles la cl a une certaine valeur. Par exemple : SELECT * FROM Film WHERE titre = Vertigo La cl est ici le titre du lm, que rien nempche par ailleurs dtre galement la cl primaire de la table. En pratique, la cl primaire est un critre de recherche trs utilis.
131
Outre les recherches par valeur, illustres ci-dessus, on veut frquemment optimiser des recherches par intervalle. Par exemple : SELECT * FROM Film WHERE annee BETWEEN 1995 AND 2002 Ici la cl de recherche est lanne du lm, et lexistence dun index bas sur le titre ne sera daucune utilit. Enn les cls peuvent tre composes de plusieurs attributs, comme, par exemple, les nom et prnom des artistes. SELECT * FROM Artiste WHERE nom = Alfred AND prenom=Hitchcock Pour toutes ces requtes, en labsence dun index appropri, il nexiste quune solution possible : parcourir squentiellement le chier (la table) en testant chaque enregistrement. Sur notre exemple, cela revient lire les 30 000 blocs du chier, pour un cot qui peut tre de lordre de 30 secondes si le chier est trs mal organis sur le disque (chaque lecture comptant alors pour environ 10 ms). Un index permet dviter ce parcours squentiel. La recherche par index deffectue en deux tapes : 1. le parcours de lindex doit fournir ladresse de lenregistrement ; 2. par accs direct au chier en utilisant ladresse obtenue prcdemment, on obtient lenregistrement (ou le bloc contenant lenregistrement, ce qui revient au mme en terme de cot). Il existe des variantes ce schma, notamment quand lindex est plaant et inuence lorganisation du chier, mais globalement nous retrouverons ces deux tapes dans la plupart des structures.
8.1.1 Index non-dense

Nous commenons par considrer le cas dun chier tri sur la cl primaire (il ny a donc quun seul enregistrement pour une valeur de cl). Dans ce cas restreint il est possible, comme nous lavons vu dans le chapitre 7, deffectuer une recherche par dichotomie qui sappuie sur une division rcursive du chier, avec des performances thoriques trs satisfaisantes. En pratique la recherche par dichotomie suppose que le chier est constitu dune seule squence de blocs, ce qui permet chaque tape de la rcursion de trouver le bloc situ au mileu de lespace de recherche. Si cette condition est facile satisfaire pour un tableau en mmoire, elle lest beaucoup moins pour un chier occupant plusieurs dizaines, voire centaines de mgaoctets. La premire structure que nous tudions permet deffectuer des recherches sur un chier tris, mme si ce chier est fragment. Lindex est lui-mme un chier, contenant des enregistrements [valeur, Adr] o valeur dsigne une valeur de la cl de recherche, et Adr ladresse dun bloc. On utilise parfois le terme dentre pour dsigner un enregistrement dans un index. Toutes les valeurs de cl existant dans le chier de donnes ne sont pas reprsentes dans lindex : on dit que lindex est non-dense. On tire parti du fait que le chier est tri sur la cl pour ne faire gurer dans lindex que les valeurs de cl des premiers enregistrements de chaque bloc. Comme nous allons le voir, cette information est sufsante pour trouver nimporte quel enregistrement. La gure 8.1 montre un index non-dense sur le chier des 16 lms, la cl tant le titre du lm. On suppose que chaque bloc du chier de donnes contient 4 enregistrements, ce qui donne un minimum de 4 blocs. Il suft alors de quatre paires [titre, Adr] pour indexer le chier. Les titres utiliss sont ceux des premiers enregistrements de chaque bloc, soit respectivement Annie Hall, Greystoke, Metropolis et Smoke. Si on dsigne par la liste ordonne des cls dans lindex, il est facile de constater quun enregistrement dont la valeur de cl est est stock dans le bloc associ la cl telle que . Supposons que lon recherche le lm Shining. En consultant lindex on constate que ce titre est compris entre Metropolis et Smoke. On en dduit donc que Shining se trouve dans le mme bloc que Metropolis. Il suft de lire ce bloc et dy rechercher lenregistrement. Le mme algorithme sapplique aux recherches bases sur un prxe de la cl (par exemple tous les lms dont le titre commence par V).
% &$ !"!

132
Annie Hall
Greystoke Metropolis Smoke
Annie Hall Brazil Casablanca Easy Rider
1977 ...... 1984 ... 1942 ... 1969 ... Greystoke Jurassic Park Impitoyable Manhattan 1984 1992 1992 1979 ... ... ... ...
Smoke Twin Peaks Underground Vertigo Metropolis 1926 Psychose 1960 Reservoir Dogs 1992 Shining 1980 ... ... ... ...
1995 1990 1995 1958
... ... ... ...
F IG . 8.1 Un index non dense
Le cot dune recherche dans lindex est considrablement plus rduit que celui dune recherche dans le chier principal. Dune part les enregistrements dans lindex sont beaucoup plus petits que ceux du chier de donnes puisque seule la cl (et un pointeur) y gurent. Dautre part lindex ne comprend quun enregistrement par bloc. Exemple 10 Considrons lexemple 9 de notre chier contenant un million de lms (voir page 130). Il est constitu de 29 142 blocs. Supposons quun titre de lms occupe 20 octets en moyenne, et ladresse dun bloc 8 octets. La taille de lindex est donc octets, comparer aux 120 Mo du chier de donnes. Le chier dindex tant tri, il est bien entendu possible de recourir une recherche par dichotomie pour trouver ladresse du bloc contenant un enregistrement. Une seule lecture suft alors pour trouver lenregistrement lui-mme. Dans le cas dune recherche par intervalle, lagorithme est trs semblable : on recherche dans lindex ladresse de lenregistrement correspondant a borne infrieure de lintervalle. On accde alors au chier grce cette adresse et il suft de partir de cet emplacement et deffectuer un parcours squentiel pour obtenir tous les enregistrements cherchs. La recherche sarrte quand on trouve un enregistrement donc la cl est suprieure la borne suprieure de lintervalle. Exemple 11 Supposons que lon recherche tous les lms dont le titre commence par une lettre entre J et P. On procde comme suit : 1. on recherche dans lindex la plus grande valeur strictement infrieure J : pour lindex de la gure 8.1 cest Greystoke ; 2. on accde au bloc du chier de donnes, et on y trouve le premier enregistrement avec un titre commenant par J, soit Jurassic Park ; 3. on parcourt la suite du chier jusqu trouver Reservoir Dogs qui est au-del de lintervalle de recherche, : tous les enregistrements trouvs durant ce parcours constituent le rsultat de la requte.

Le cot dune recherche par intervalle peut tre assimil, si nglige la recherche dans lindex, au parcours de la partie du chier qui contient le rsultat, soit , o dsigne le nombre denregistrements du rsultat, et le nombre denregistrements dans un bloc. Ce cot est optimal. Un index dense est extrmement efcace pour les oprations de recherche. Bien entendu le problme est de maintenir lordre du chier au cours des oprations dinsertions et de destructions, problme encore compliqu par la

133
ncessit de garder une troite correspondance entre lordre du chier de donnes et lordre du chier dindex. Ces difcults expliquent que ce type dindex soit peu utilis par les SGBD, au prot de larbre-B qui offre des performances comparables pour les recherches par cl, mais se rorganise dynamiquement.
8.1.2 Index dense

Que se passe-t-il quand on veut indexer un chier qui nest pas tri sur la cl de recherche ? On ne peut tirer parti de lordre des enregistrements pour introduire seulement dans lindex la valeur de cl du premier lment de chaque bloc. Il faut donc baser lindex sur toutes les valeurs de cl existant dans le chier, et les associer ladresse dun enregistrement, et pas ladresse dun bloc. Un tel index est dense. La gure 8.2 montre le mme chier contenant seize lms, tri sur le titre, et index maintenant sur lanne de parution des lms. On constate dune part que toutes les annes du chier de donnes sont reportes dans lindex, ce qui accrot considrablement la taille de ce dernier, et dautre part que la mme anne apparat autant quil y a de lms parus cette anne l.
Annie Hall Brazil Casablanca Easy Rider 1977 ...... 1984 ... 1942 ... 1969 ... ... ... ... ... ... ... ... ... ... ... ... ...
1926 1942 1958 1960 1969 1977 1979 1980 1984 1984 1990 1992 1992 1992 1995 1995
Greystoke 1984 Jurassic Park 1992 Impitoyable 1992 Manhattan 1979 Metropolis 1926 Psychose 1960 Reservoir Dogs 1992 Shining 1980 Smoke Twin Peaks Undergroun Vertigo 1995 1990 1995 1958
F IG . 8.2 Un index dense
Exemple 12 Considrons lexemple 9 de notre chier contenant un million de lms (voir page 130). Il faut crer une entre dindex pour chaque lm. Une anne occupe 4 octets, et ladresse dun bloc 8 octets. La taille de lindex est donc octets, soit seulement dix fois moins que les 120 Mo du chier de donnes. Un index dense peut coexister avec un index non-dense. Comme le suggrent les deux exemples qui prcdent, on peut envisager de trier un chier sur la cl primaire et de crer un index non-dense, puis dajouter des index dense pour les attributs qui servent frquemment de critre de recherche. On parle alors parfois dindex primaire et dindex secondaire, bien que ces termes soient moins prcis. Il est possible en fait de crer autant dindex denses que lon veut puisquils sont indpendants du chier de donnes. Cette remarque nest plus vraie dans le cas dun index non-dense puisquil sappuie sur le tri du chier et quun chier ne peut tre tri que dune seule manire. La recherche par cl ou par prxe avec un index dense est similaire celle dj prsente pour un index non-dense. Si la cl nest pas unique (cas des annes de parution des lms), il faut prendre garde lire dans lindex toutes les
134
entres correspondant au critre de recherche. Par exemple, pour rechercher tous les lms parus en 1992 dans lindex de la gure 8.2, on trouve dabord la premire occurence de 1992, pointant sur Jurasic Park, puis on lit en squence les entres suivantes dans lindex pour accder successivement Impitoyable puis Reservoir Dogs. La recherche sarrte quand on trouve lentre 1995 : lindex tant tri, aucun lm paru en 1992 ne peut tre trouv en continuant. Notez que rien ne garantit que les lms parus en 1992 sont situs dans le mme bloc : on dit que lindex est non-plaant. Cette remarque a surtout un impact sur les recherches par intervalle, comme le montre lexemple suivant.

1. on recherche dans lindex la premire valeur comprise dans lintervalle : pour lindex de la gure 8.2 cest 1958 ; 2. on accde au bloc du chier de donnes pour y prendre lenregistrement Vertigo : notez que cet enregistrement est plac dans le dernier bloc du chier ; 3. on parcourt la suite de lindex, en accdant chaque fois lenregistrement correspondant dans le chier de donnes, jusqu trouver une anne suprieure 1979 : on trouve successivement Psychose (troisme bloc), Easy Rider, Annie Hall (premier bloc) et Manhattan (deuxime bloc).
Pour trouver 5 enregistements, on a d accder aux quatre blocs. Le cot dune recherche par intervalle est, dans le pire des cas, gale , o dsigne le nombre denregistrements du rsultat (soit une lecture de bloc par enregistrement). Il est intressant de le comparer avec le cot dune recherche par intervalle avec un index non-dense : on a perdu le facteur de blocage obtenu par un regroupement des enregistrements dans un bloc. Retenons galement que la recherche dans lindex peut tre estime comme tout a fait ngligeable compare aux nombreux accs alatoires au chier de donnes pour lire les enregistrements.
8.1.3 Index multi-niveaux

Il peut arriver que la taille du chier dindex devienne elle-mme si grande que les recherches dans lindex en soit pnalises. La solution naturelle est alors dindexer le chier dindex lui-mme. Rappelons quun index est un chier constitu denregistrements [cl, Adr], tri sur la cl : ce tri nous permet dutiliser, ds le deuxime niveau dindexation, un index non-dense. Reprenons lexemple de lindexation des lms sur lanne de parution. Nous avons vus que la taille du chier tait seulement dix fois moindre que celle du chier de donnes. Mme sil est possible deffectuer une recherche par dichotomie, cette taille est pnalisante pour les oprations de recherche. On peut alors crer un deuxime niveau dindex, comme illustr sur la gure 8.3. On a suppos, pour la clart de lillustration, quun bloc de lindex de premier niveau ne contient que quatre entres [date, Adr]. Il faut donc quatre blocs (marqus par des traits gras) pour cet index. Lindex de second niveau est construit sur les valeurs de cls des premiers enregistrements des quatre blocs. Il suft donc dun bloc pour ce second niveau. Sil y avait deux blocs (par exemple parce que les blocs ne sont pas compltement pleins) on pourrait envisager de crer un troisime niveau, avec un seul bloc contenant deux entres pointant vers les deux blocs du second niveau, etc. Tout lintrt dun index multi-niveaux est de pouvoir passer, ds le second niveau, dune structure dense une structure non-dense. Si ce ntait pas le cas on ny gagnerait rien puisque tous les niveaux auraient la mme taille que le premier. Une recherche, par cl ou par intervalle, part toujours du niveau le plus lev, et reproduit dun niveau lautre les procdures de recherches prsentes prcdemment. Pour une recherche par cl, le cot est gal au nombre de niveaux de larbre. Exemple 14 On recherche le ou les lms parus en 1990. Partant du second niveau dindex, on slectionne la troisime entre correspondant la cl 1984. Lentre suivante a en effet pour valeur 1992, et ne pointe donc que sur des lms antrieurs cette date. La troisime entre mne au troisime bloc de lindex de premier niveau. On y trouve une entre avec la valeur 1990 (il pourrait y en avoir plusieurs). Il reste accder lenregistrement.
Exemple 13 Voici lalgorithme qui recherche tous les lms parus dans lintervalle

Annie Hall Brazil Casablanca Easy Rider Greystoke Jurassic Park Impitoyable Manhattan 1977 ...... 1984 ... 1942 ... 1969 ... 1984 1992 1992 1979 ... ... ... ... ... ... ... ... ... ... ... ...
135
1926 1969 1984 1992
1926 1942 1958 1960 1969 1977 1979 1980 1984 1984 1990 1992 1992 1992 1995 1995
Metropolis 1926 Psychose 1960 Reservoir Dogs 1992 Shining 1980 Smoke Twin Peaks Underground Vertigo 1995 1990 1995 1958
F IG . 8.3 Index multi-niveaux
Les index multi-niveaux sont trs efcaces en recherche, et ce mme pour des jeux de donnes de trs grande taille. Le problme est, comme toujours, la difcult de maintenir des chiers tris sans dgradation des performances. Larbre-B, tudi dans la section qui suit, 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 dinsertion et suppression subies par les donnes.
8.2 Larbre-B
Larbre-B est une structure dindex qui offre un excellent compromis pour les oprations de recheche par cl et par intervalle, ainsi que pour les mises jour. Ces qualits expliquent quil soit systmatiquement utilis par tous les SGBD, notamment pour indexer la cl primaire des tables relationnelles. Dans ce qui suit nous supposons que le chier des donnes stocke squentiellement les enregistrements dans lordre de leur cration et donc indpendamment de tout ordre lexicographique ou numrique sur lun des attributs. Notre prsentation est essentiellement consacre la variante de larbre-B dite larbre-B+ .
8.2.1 Prsentation intuitive

La gure 8.4 montre un arbre-B+ indexant notre collection de 16 lms. Lindex est organis en blocs de taille gale, ce qui ajoute une souplesse supplmentaire lorganisation en niveaux tudies prcdemment. En pratique un bloc peut contenir un assez grand nombre de titres de lms, mais pour la clart de lillustration nous supposerons que lon peut stocker au plus 4 titres dans un bloc. Notons quau sein dun mme bloc, les titres sont tris par ordre lexicographique. Les blocs sont chans entre eux de manire crer une structure arborescente qui, dans notre exemple, comprend deux niveaux. Le premier niveau consiste en un seul bloc, la racine de larbre. Il contient 3 titres et 4 chanages vers 4 blocs du second niveau. Larbre est construit de telle manire que les titres des lms dans ces 4 blocs sont organiss de la manire suivante.
8.2. LARBRE-B
136
Easy Rider Manhattan Shining
Index
Annie Hall Brazil Casablanca Easy Rider
Greystoke Impitoyable Jurassic Park Manhattan
Metropolis Psychose Reservoir Dogs Shining
Smoke Twin Peaks Underground Vertigo
Vertigo 1958 Brazil 1984 Twin Peaks 1990 Underground 1995 Easy Rider 1969 Psychose 1960 Donnes Greystoke 1984 Shining 1980 Annie Hall 1977 Jurassic Park 1992 Metropolis 1926
Manhattan 1979 Reservoir Dogs 1992 Impitoyable 1992 Casablanca 1942 Smoke 1995
F IG . 8.4 Le chier des lms, avec un index unique sur le titre.
1. dans le bloc situ gauche de Easy Rider, on ne trouve que des titres infrieurs ou gaux, selon lordre lexicographique, Easy Rider ; 2. dans le bloc situ entre Easy Rider et Manhattan, on ne trouve que des titres strictement suprieurs Easy Rider et infrieurs ou gaux Manhattan ; 3. et ainsi de suite : le dernier bloc contient des titres strictement suprieurs Shining. Le dernier niveau (le second dans notre exemple) est celui des feuilles de larbre. Il constitue un index dense alors que les niveaux suprieurs sont non-denses. ce niveau on associe chaque titre ladresse du lm dans le chier des donnes. tant donn cette adresse, on peut accder directement au lm sans avoir besoin deffectuer un parcours squentiel sur le chier de donnes. Dans la gure 8.4, nous ne montrons que quelques-uns de ces chanages (index, donnes). Il existe un deuxime chanage dans un arbre-B+ : les feuilles sont lies entre elles en suivant lordre lexicographique des valeurs quelles contiennent. Ce second chanage reprsent en pointills dans la gure 8.4 permet de rpondre aux recherches par intervalle. Lattribut titre est la cl unique de Film. Il ny a donc quune seule adresse associe chaque lm. On peut crer dautre index sur le mme chier de donnes. Si ces autres index ne sont pas construits sur des attributs formant une cl unique, on aura plusieurs adresses associs une mme valeur. La gure 8.6 montre un index construit sur lanne de parution des lms. Cet index est naturellement non-unique puisque plusieurs lms paraissent la mme anne. On constate par exemple que la valeur 1995 est associe deux lms, Smoke et Underground. La valeur 1995 est associ trois lms (non illustr sur la gure), etc. Ce deuxime index permet doptimiser des requtes utilisant lanne comme critre de recherche. Quand un arbre-B+ est cr sur une table, soit directement par la commande CREATE INDEX, soit indirectement avec loption PRIMARY KEY, un SGBD relationnel effectue automatiquement les oprations ncessaires au maintien de la structure : insertions, destructions, mises jour. Quand on insre un lm, il y a donc galement insertion dune nouvelle valeur dans lindex des titres et dans lindex des annes. Ces oprations peuvent tre assez coteuses, et la cration dun index, si elle optimise des oprations de recherche, est en contrepartie pnalisante pour les mises jour.
Greystoke
137
Brazil|Easy Rider
Psychose | Shining | Twin Peaks
Annie Hall
Casablanca
Impitoyable Jurassic Park
Manhattan Metropolis
Reservoir Dogs
Smoke
Vertigo Undeground
F IG . 8.5 Exemple
1958 1969 1984
Index
1926 1942 1958
1960 1969
1977 1979 1980 1984
1990 1992 1995
Vertigo 1958 Brazil 1984 Twin Peaks 1990 Underground 1995 Easy Rider 1969 Psychose 1960 Donnes Greystoke 1984 Shining 1980 Annie Hall 1977 Jurassic Park 1992 Metropolis 1926
Manhattan 1979 Reservoir Dogs 1992 Impitoyable 1992 Casablanca 1942 Smoke 1995
F IG . 8.6 Le chier des lms, avec un index unique.
8.2.2 Recherches avec un arbre-B+

Larbre-B+ supporte des oprations de recherche par cl, par prxe de la cl et par intervalle. Recherche par cl Prenons lexemple suivant : SELECT * FROM Film WHERE titre = Impitoyable En labsence dindex, la seule solution est de parcourir le chier. Dans lexemple de la gure 8.4, cela implique de lire inutilement 13 lms avant de trouver Impitoyable qui est en quatorzime position. Lindex permet de trouver
8.2. LARBRE-B
lenregistrement beaucoup plus rapidement.
138
on lit la racine de larbre : Impitoyable tant situ dans lordre lexicographique entre Easy Rider et Manhattan, on doit suivre le chanage situ entre ces deux titres ; on lit le bloc feuille dans lequel on trouve le titre Impitoyable associ ladresse de lenregistrement dans le chier des donnes ; il reste lire lenregistrement. Donc trois lectures sont sufsantes. Plus gnralement, le nombre daccs disques ncessaires pour une recherche par cl est gal au nombre de niveaux de larbre, plus une lecture pour accder au chier de donnes. Dans des conditions ralistes, le nombre de niveaux dun index est trs faible, mme pour de grands ensembles de donnes. Cette proprit est illustre par lexemple suivant. Exemple 15 Reprenons lexemple 9 de notre chier contenant un million de lms. Une entre dindex occupe 28 octets. On place donc entres (au maximum) dans un bloc. Il faut blocs pour le premier niveau de larbre-B+. Le deuxime niveau comprend 6 850 entres, une pour chaque bloc du premier niveau. Il faut donc blocs. Finalement, un troisime niveau, constitu dun bloc avec 47 entres suft pour complter larbre-B+. Quatre accs disques (trois pour lindex, un pour lenregistrement) sufsent pour une recherche par cl, alors quil faudrait parcourir les 30 000 blocs dun chier en labsence dindex. Le gain est dautant plus spectaculaire que le nombre denregistrements est lev. Voici une petite extrapolation montrant le nombre de lms indexs en fonction du nombre de niveaux dans larbre 1. 1. avec un niveau dindex (la racine seulement) on peut donc rfrencer 146 lms ;
4. enn avec quatre niveaux on index plus de 450 millions de lms. Il y a donc une croissance trs rapide exponentielle du nombre de lms indexs en fonction du nombre de niveaux et, rciproquement, une croissance trs faible logarithmique du nombre de niveaux en fonction du nombre denregistrements. Le cot dune recherche par cl tant proportionnel au nombre de niveaux et pas au nombre denregistrements, lindexation permet damliorer les temps de recherche de manire vraiment considrable. Lefcacit dun arbre-B+ dpend entre autres de la taille de la cl : plus celle-ci est petite, et plus lindex sera petit et efcace. Si on indexait les lms avec une cl numrique sur 4 octets (un entier), on pourrait rfrencer lms dans un bloc, et un index avec trois niveaux permettrait dindexer lms ! Du point de vue des performances, le choix dune chane de caractres assez longue comme cl des enregistrements est donc assez dfavorable. Recherche par intervalle Un arbre-B+ permet galement deffectuer des recherches par intervalle. Le principe est simple : on effectue une recherche par cl pour la borne infrieure de lintervalle. On obtient la feuille contenant cette borne infrieure. Il reste parcourir les feuilles de larbre, grce au chanage des feuilles, jusqu ce que la borne suprieure ait t rencontre ou dpasse. Voici une recherche par intervalle : SELECT * FROM Film WHERE annee BETWEEN 1960 AND 1975
1. Pour tre plus prcis le calcul qui suit devrait tenir compte du fait quun bloc nest pas toujours plein.
! !

3. avec trois niveaux on indexe
lms ;
2. avec deux niveaux on indexe 146 blocs de 146 lms chacun, soit
lms ;

!
!

!
139
On peut utiliser lindex sur les cls pour rpondre cette requte. Tout dabord on fait une recherche par cl pour lanne 1960. On accde alors la seconde feuille (voir gure 8.6) dans laquelle on trouve la valeur 1960 associe ladresse du lm correspondant (Psychose) dans le chier des donnes. On parcourt ensuite les feuilles en suivant le chanage indiqu en pointills dans la gure 8.6. On accde ainsi successivement aux valeurs 1969, 1977 (dans la troisime feuille) puis 1979. Arriv ce point, on sait que toutes les valeurs suivantes seront suprieures 1979 et quil nexiste donc pas de lm paru en 1975 dans la base de donnes. Toutes les adresses des lms constituant le rsultat de la requte ont t rcupres : il reste lire les enregistrements dans le chier des donnes. Cest ici que les choses se gtent : jusqu prsent chaque lecture dun bloc de lindex ramenait un ensemble dentres pertinentes pour la recherche. Autrement dit on bnciait du bon regroupement des entres : les cls de valeurs proches donc susceptibles dtre recherches ensembles sont proches dans la structure. Ds quon accde au chier de donnes ce nest plus vrai puisque ce chier nest pas organis de manire regrouper les enregistrements ayant des valeurs de cl proches. Dans le pire des cas, comme nous lavons soulign dj pour les index simples, il peut y avoir une lecture de bloc pour chaque lecture dun enregistrement. Laccs aux donnes est alors de loin la partie la plus pnalisante de la recherche par intervalle, tandis que le parcours de larbre-B+ peut tre considr comme nligeable. Recherche avec un prxe de la cl Enn larbre-B+ est utile pour une recherche avec un prxe de la cl : il sagit en fait dune variante des recherches par intervalle. Prenons lexemple suivant : SELECT * FROM Film WHERE titre LIKE M% On veut donc tous les lms dont le titre commence par M. Cela revient faire une recherche par intervalle sur toutes les valeurs comprises, selon lordre lexicographique, entre le M (compris) et le N (exclus). Avec lindex, lopration consiste effectuer une recherche par cl avec la lettre M, qui mne la seconde feuille (gure 8.4) dans laquelle on trouve le lm Manhattan. En suivant le chanage des feuilles on trouve le lm Metropolis, puis Psychose qui indique que la recherche est termine. Le principe est gnralisable toute recherche qui peut sappuyer sur la relation dordre qui est la base de la construction dun arbre-B+. En revanche une recherche sur un sufxe de la cl ( tous les lms terminant par S ) ou en appliquant une fonction ne pourra pas tirer parti de lindex et sera excute par un parcours squentiel. Cest le cas par exemple de la requte suivante : SELECT * FROM Film WHERE titre LIKE %e Ici on cherche tous les lms dont le titre se nit par e. Ce critre nest pas compatible avec la relation dordre qui est la base de la construction de larbre, et donc des recherches quil supporte. Le temps dexcution dune requte avec index peut savrer sans commune mesure avec celui dune recherche sans index, et il est donc trs important dtre conscient des situations o le SGBD pourra effectuer une recherche par lindex. Quand il y a un doute, on peut demander des informations sur la manire dont la requte est excute (le plan dexcution ) avec les outils de type EXPLAIN .

8.3 Hachage
Les tables de hachage sont des structures trs couramment utilises en mmoire centrale pour organiser des ensembles et fournir un accs peformant ses lments. Nous commenons par rappeler les principes du hachage avant dtudier les spcicits apportes par le stockage en mmoire secondaire.
8.3. HACHAGE
140
8.3.1 Principes de base

Lide de base du hachage est dorganiser un ensemble dlments daprs une cl, et dutiliser une fonction (dite de hachage) qui, pour chaque valeur de cl , donne ladresse dun espace de stockage o llement doit tre plac. En mmoire principale cet espace de stockage est en gnral une liste chane, et en mmoire secondaire un ou plusieurs blocs sur le disque. Exemple dune table de hachage Prenons lexemple de notre ensemble de lms, et organisons-le avec une table de hachage sur le titre. On va supposer que chaque bloc contient au plus quatre lms, et que lensemble des 16 lms occupe donc au moins 4 blocs. Pour garder une marge de manuvre on va affecter 5 blocs la collection de lms, et on numrote ces blocs de 0 4. Maintenant il faut dnir la rgle qui permet daffecter un lm lun des blocs. Cette rgle prend la forme dune fonction qui, applique un titre, va donner en sortie un numro de bloc. Cette fonction doit satisfaire les deux critres suivants : 1. le rsultat de la fonction, pour nimporte quelle chane de caractres, doit tre un adresse de bloc, soit pour notre exemple un entier compris entre 0 et 4 ; 2. la distribution des rsultats de la fonction doit tre uniforme sur lintervalle ; en dautres termes les probabilits un des 5 chiffres pour une chane de caractre quelconque doivent tre gales. Si le premier critre est relativement facile satisfaire, le second soulve quelques problmes car lensemble des chanes de caractres auxquelles on applique une fonction de hachage possde souvent des proprits statistiques spciques. Dans notre exemple, lensemble des titres de lm commencera souvent par Le ou La ce qui risque de perturber la bonne distribution du rsultat si on ne tient pas compte de ce facteur.
blocs entres
Jurassic Park 1992 Twin Peaks 1990 Easy Rider 1969
Annie Hall 1977 Underground 1995 Psychose 1960 Brazil 1984 Vertigo 1958 Greystoke 1984
0 1 2 3 4 Rpertoire Impitoyable 1992 Shining 1980 Smoke 1995
Manhattan 1979 Metropolis 1926 Casablanca 1942 Reservoir Dogs 1992
F IG . 8.7 Exemple dune table de hachage
Nous allons utiliser un principe simple pour notre exemple, en considrant la premire lettre du titre, et en lui affectant son rang dans lalphabet. Donc vaudra 1, vaudra , vaudra 8, etc. Ensuite, pour se ramener une valeur entre 0 et 4, on prendra simplement le reste de la division du rang de la lettre par 5 ( modulo 5 ). En rsum la fonction est dnie par : La gure 8.7 montre la table de hachage obtenue avec cette fonction. Tous les lms commenant par , , , , et sont affects au bloc 1 ce qui donne, pour notre ensemble de lms, Annie Hall, Psychose et Underground. les lettres

141
, , , et sont affectes au bloc 2 et ainsi de suite. Notez que la lettre a pour rang 5 et se trouve donc affecte au bloc 0. La gure 8.7 prsente, outre les cinq blocs stockant des lms, un rpertoire cinq 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, selon un mcanisme dj rencontr dans la partie du chapitre 7 consacre aux techniques dadressage de blocs (voir section 7.2.2, page 115). On peut raisonnablement supposer que sa taille est faible et quil peut donc rsider en mmoire principale. On est assur avec cette fonction dobtenir toujours un chiffre entre 0 et 4, mais en revanche la distribution risque de ne pas tre uniforme : si, comme on peut sy attendre, beaucoup de titres commencent par la lettre , le bloc 2 risque dtre surcharg. et lespace initialement prvu savrera insufsant. En pratique, on utilise un calcul beaucoup moins sensible ce genre de biais : on prend par exemple les 4 ou 8 premiers caractres de la chanes, on traite ces caractres commes des entiers dont on effectue la somme, et on dnit la fonction sur le rsultat de cette somme. Recherche dans une table de hachage La structure de hachage permet les recherches par titre, ou par le dbut dun titre. Reprenons notre exemple favori : SELECT * FROM Film WHERE titre = Impitoyable Pour valuer cette requte, il suft dappliquer la fonction de hachage la premire lettre du titre, , 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 tient en mmoire principale, on a donc pu efectuer cette recherche en lisant un seul bloc, ce qui est optimal. cet exemple rsume les deux avantages principaux dune table de hachage : 1. La structure noccupe aucun espace disque, contrairement larbre-B ; 2. elle permet deffectuer les recherches par cl par accs direct (calcul) au bloc susceptible de contenir les enrgistrements. Le hachage supporte galement toute recherche base sur la cl de hachage, et telle que le critre de recherche fourni puisse servir dargument la fonction de hachage. La requte suivante par exemple pourra tre value par accs direct avec notre fonction base sur la premire lettre du titre. SELECT * FROM Film WHERE titre LIKE M% En revanche, si on a utilis une fonction plus sophistique base sur tous les caractres dune chane (voir cidessus), la recherche par prxe nest plus possible. La hachage ne permet pas doptimiser les recherche par intervalle, puisque lorganisation des enregistrement ne sappuie pas sur lordre des cls. La requte suivante par exemple entrane laccs tous les blocs de la structure, mme si trois lms seulement sont concerns. SELECT * FROM Film WHERE titre BETWEEN Annie Hall AND Easy Rider Cette incapacit effectuer efcacement des recherches par intervalle doit mener prfrer larbre-B dans tous les cas o ce type de recherche est envisgeable. Si la cl est par exemple une date, il est probable que des recherche seront effectues sur un intervalle de temps, et lutilisation du hachage peut savrer un mauvais choix. Mais dans le cas, frquent, o on utilise une cl abstraite pour identier les enregistrements pas un numro squentiel indpendant de leurs attributs, le hachage est tout fait appropri car une recherche par intervalle ne prsente alors pas de sens et tous les accs se feront par la cl.
8.3. HACHAGE
Mises jour
142
Si le hachage peut offrir des performances sans quivalent pour les recherches par cl, il est du moins dans la version simple que nous prsentons pour linstant mal adapt aux mises jour. Prenons tout dabord le cas des insertions : comme on a valu au dpart la taille de la table pour dterminer le nombre de blocs ncessaire, cet esapec initial risque de ne plus tre sufsant quand des insertions conduisent dpasser la taille estime initialement. La seule solution est alors de chaner de nouveaux blocs. Cette situation est illustre dans la gure 8.8. On a insr un nouveau lm, Citizen Kane. La valeur donne par la fonction de hachage est 3, rang de la lettre dans laplhabet, mais le bloc 3 est dj plein.
blocs entres
Jurassic Park 1992 Twin Peaks 1990 Easy Rider 1969
Annie Hall 1977 Underground 1995 Psychose 1960 Brazil 1984 Vertigo 1958 Greystoke 1984
0 1 2 3 4 Rpertoire Impitoyable 1992 Shining 1980 Smoke 1995 Manhattan 1979 Metropolis 1926 Casablanca 1942 Reservoir Dogs 1992
Citizen Kane 1941
F IG . 8.8 Table de hachage avec page de dbordement
Il est impratif pourtant de stocker le lm dans lespace associ la valeur 3 car cest l que les recherches iront seffectuer. On doit alors chaner un nouveau bloc au bloc 3 et y stocker le nouveau lm. une entre dans la table, correspondant ladresse logique 3, sont associs maintenant deux blocs physiques, avec une dgradation potentielle des performances puisquil faudra, lors dune recherche, suivre le chanage et inspecter tous les enregistrements pour lesquels la fonction de hachage donne la valeur 3. Dans le pire des cas, une fonction de hachage mal conue affecte tous les enregistrements la mme adresse, et la structure dgnre vers un simple chier squentiel. Ce peut tre le cas, avec notre fonction base sur la premire lettre du titre, pour tous les lms dont le titre commence par . Autrement dit, ce type de hachage nest pas dynamique et ne permet pas, dune part dvoluer paralllement la croissance ou dcroissance des donnes, dautre part de sadapter aux dviations statistiques par rapport la normale. En rsum, les avantages et inconvnients du hachage statique, compar larbre-B, sont les suivantes : Avantages : (1) recherche par accs direct, en temps constant ; (2) noccupe pas despace disque. Inconvnients : (1) pas de recherche par intervalle ; (2) pas de dynamicit. Il nest pas inutile de rappeler quen pratique la hauteur dun arbre-B est de lordre de 2 ou 3 niveaux, ce qui relativise lavantage du hachage. Une recherche avec le hachage demande une lecture, et 2 ou 3 avec larbre B, ce qui nest pas vraiment signicatif. Cette considration explique que larbre-B, plus gnraliste et presque aussi efcace, soit employ par dfaut pour lindexation dans tous les SGBD relationnels. Enn signalons que le hachage est une structure plaante, et quon ne peut donc crer quune seule table de hachage pour un ensemble de donnes, les autres index tant obligatoirement des arbres B+. Nous prsentons dans ce qui suit des techniques plus avances de hachage dit dynamique qui permettent dobtenir une structure plus volutive. La caractristique comune de ces mthodes est dadapter le nombre dentres dans la
titre Vertigo Brazil Twin Peaks Underground Easy Rider Psychose Greystoke Shining (titre) 01110010 10100101 11001011 01001001 00100110 01110011 10111001 11010011

143
TAB . 8.2 Valeurs du hachage extensible pour les titres table de hachage de manire ce que le nombre de blocs corresponde approximativement la taille ncessaire pour stocker lensemble des enregistrements. On doit se retrouver alors dans une situation o il ny a quun bloc par entre en moyenne, ce qui garantit quon peut toujours accder aux enregistrements avec une seule lecture.
8.3.2 Hachage extensible

Nous prsentons tout dabord le hachage extensible sur une exemple avant den donner une description plus gnrale. Pour linstant la structure est tout fait identique celle que nous avons vue prcdemment, ceci prs que le nombre dentres dans le rpertoire est variable, et toujours gal une puissance de 2. Nous dbutons avec le cas minimal o ce nombre dentres est gal 2, avec pour valeurs respectives 0 et 1. Maintenant nous supposons donne une fonction de hachage dont le rsultat est toujours un entier sur 4 octets, soit 32 bits. La table 8.2 donne les 8 premiers bits des valeurs obtenues par application de cette fonction aux titres de nos lms. Comme il ny a que deux entres, nous nous intresons seulement au premier de ces 32 bits, qui peut valoir 0 ou 1. La gure 8.9 montre linsertion des cinq premiers lms de notre liste, et leur affectation lun des deux blocs. Le lm Vertigo par exemple a pour valeur de hachage 01110010 qui commence par 0, et se trouve donc affect la premire entre.
Vertigo Easy Rider Underground 0 1
Brazil Twin Peaks
F IG . 8.9 Hachage extensible avec 2 entres
Supposons, pour la clart de lexpos, que lon ne puisse placer que 3 enregistrements dans un bloc. Alors linsertion de Psychose, avec pour valeur de hachage 01110011, entraine le dbordement du bloc associ lentre 0. On va alors doubler la taille du rpertoire pour la faire passer quatre entres, avec pour valeurs respectives 00, 01, 10, 11, soit les combinaisons possibles de 0 et de 1 sur deux bits. Ce doublement de taille du rpertoire entraine la rorganisation suivante (gure 8.10) : 1. les lms de lancienne entre 0 sont rpartis sur les entres 00 et 01 en fonction de la valeur de leurs deux premiers bits : Easy Rider dont la valeur de hachage commence par 00 est plac dans le premier bloc, tandis que
8.3. HACHAGE
144
Easy Rider
00 01 10 11
Vertigo Underground Psychose Brazil Twin Peaks
F IG . 8.10 Doublement du rpertoire dans le hachage extensible
Vertigo, Underground et Psychose, dont les valeurs de hachage commencent par 01, sont places dans le second bloc. 2. les lms de lancienne entre 1 nont pas de raison dtre rpartis dans deux blocs puisquil ny a pas eu de dbordement pour cette valeur : on va donc associer le mme bloc aux deux entres 10 et 11. Maintenant on insre Greystoke (valeur 10111001) et Shining (valeur) 11010011. Tous deux commencent par 10 et doivent donc tre placs dans le troisime bloc qui dborde alors. Ici il nest cependant pas ncessaire de doubler le rpertoire puisquon est dans une situation o plusieurs entres de ce rpertoire pointent sur le mme bloc. On va donc allouer un nouveau bloc la structure, et lassocier lentre 11, lancien bloc restant associ la seule entre 10. Les lms sont rpartis dans les deux blocs, Brazil et Greystoke avec lentre 10, Twin Peaks et Shining avec lentre 11 (gure 8.11).
Easy Rider
00 01 10 11
Vertigo Underground Psychose Brazil Greystoke
Twin Peaks Shining
F IG . 8.11 Jeu de pointeurs pour viter de doubler le rpertoire
rang 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 titre Vertigo Brazil Twin Peaks Underground Easy Rider Psychose Greystoke Shining Annie Hall Jurasic Park Metropolis Manhattan Reservoir Dogs Impitoyable Casablanca Smoke genre Suspense Science-Fiction Fantastique Drame Drame Drame Aventures Fantastique Comdie Science-Fiction Science-Fiction Comdie Policier Western Drame Comdie ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
145
TAB . 8.3 Les lms et leur genre
8.4 Les index bitmap

Un index bitmap repose sur un principe trs diffrents de celui des arbres B+ Alors que dans ces derniers on trouve, pour chaque attribut index, les mmes valeurs dans lindex et dans la table, un index bitmap considre toutes les valeurs possibles pour cet attribut, que la valeur soit prsente ou non dans la table. Pour chacune de ces valeurs possibles, on stocke un tableau de bits (dit bitmap), avec autant de bits quil y a de lignes dans la table. Notons lattribut index, et la valeur dnissant le bitmap. Chaque bit associ une ligne a alors la signication suivante : si le bit est 1, lattribut sinon le bit est 0. Quand on recherche les lignes avec la valeur , il suft donc de prendre le bitmap associ , de chercher tous les bits 1, et daccder les enregistrements correspondant. Un index bitmap est trs efcace si le nombre de valeurs possible pour un attribut est faible. Exemple 16 Reprenons lexemple de nos 16 lms, et crons un index sur le genre (voir le table 8.3). Lutilisation dun arbre-B ne donnera pas de bons rsultats car lattribut est trop peu slectif (autrement dit une partie importante de la table peut tre slectionne quand on effectue une recherche par valeur). En revanche un index bitmap est tout fait appropri puisque le genre fait partie dun ensemble numr avec relativement peu de valeurs. Voici par exemple le bitmap pour les valeurs Drame , Science-Fiction et Comdie . Chaque colonne correspond lun des lms. 1 0 0 0 2 0 1 0 3 0 0 0 4 1 0 0 5 1 0 0 6 1 0 0 7 0 0 0 8 0 0 0 9 0 0 1 10 0 1 0 11 0 1 0 12 0 0 1 13 0 0 0 14 0 0 0 15 1 0 0 16 0 0 1 a pour valeur dans la ligne ;
Drame Science-Fiction Comdie
Pour la valeur Drame , on place le bit 1 pour les lms de rang 4, 5, 6 et 15. Tous les autres sont zro. Pour Science-Fiction les bits 1 sont aux rangs 2, 10 et 11. Bien entendu il ne peut y avoir quun seul 1 dans une colonne puisquun attribut ne peut prendre quune valeur. Un index bitmap est trs petite taille compar un arbre-B construit sur le mme attribut. Il est donc trs utile dans des applications de type Entrept de donnes grant de gros volumes, et classant les informations par des
8.5. INDEXATION DANS ORACLE
146
attributs catgoriels dnis sur de petits domaines de valeur (comme, dans notre exemple, le genre dun lm). Certains requtes peuvent alors tre excutes trs efcacement, parfois sans mme recourir la table. Prenons lexemple suivant : Combien y a-t-il de lm dont le genre est Drame ou Comdie ? . SELECT COUNT(*) FROM Film WHERE genre IN (Drame, Comdie) Pour rpondre cette requte, il suft de compter le nombre de 1 dans les bitmap associs ces deux valeurs !
8.5 Indexation dans Oracle

Oracle propose plusieurs techniques dindexation : arbres B, arbres B+, tables de hachage. Par dfaut la structure dindex est un arbre B+, stock 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 (hach cluster).
8.5.1 Arbres B+
La principale structure dindex utilise par Oracle est larbre B+, ce qui sexplique par les bonnes performances de cet index dans la plupart des situations (recherche, recherches par prxe, mises jour). Par dfaut un arbre B+ est cr la cl primaire de chaque table, ce qui offre un double avantage : 1. lindex permet doptimiser les jointures, comme nous le verrons plus tard ; 2. au moment dune insertion, lindex permet de vrier trs rapidement que la nouvelle cl nexiste pas dj. Oracle maintient automatiquement larbre B+ au cours des insertions, suppressions et mises jour affectant la table, et ce de manire transparente pour lutilisateur. Ce dernier, sil effectue des recherches par des attributs qui ne font pas partie de la cl, peut optimiser ses recherches 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 Artiste (nom, prenom) Cette commande ne fait pas partie de la norme SQL ANSI mais on la retrouve peu de choses prs dans tous les SGBD relationnels. Notons que Oracle cre le mme index si on spcie une clause UNIQUE(nom, prenom) dans le CREATE TABLE. La clause UNIQUE est optionnelle. On peut crer un index non-unique sur des attributs susceptibles de contenir la mme valeur pour deux tables diffrentes. Voici un exemple permettant doptimiser les recherches portant sur le genre dun lm. CREATE INDEX idxGenre ON Film (genre) Attention cependant la slectivit des recherches avec un index non-unique. Si, avec une valeur, on en arrive slectionner une partie importante de la table, lutilisation dun index napportera pas grand chose et risque mme de dgrader les performances. Il est tout fait dconseill par exemple de crer un index sur une valeur boolenne car une recherche squentielle sur le chier sera beaucoup plus efcace. Larbre B+ est plac dans le segment dindex associ la table. On peut indiquer dans la clause CREATE INDEX le tablespace o ce segment doit tre stock, et paramtrer alors ce tablespace pour optimiser le stockage des blocs dindex. Au moment de la cration dun index, Oracle commence par trier la table dans un segment temporaire, puis construit larbre B+ de bas en haut an dobtenir un remplissage des blocs conforme au paramtre PCTFREE du tablespace. Au niveau des feuilles de larbre B+, on trouve, pour chaque valeur, le (cas de lindex unique) ou les (cas de lindex non-unique) ROWID des enregistrements associs cette valeur.
147
8.5.2 Arbres B
Rappelons quun arbre-B consiste crer une structure dindex et stocker les enregistrements dans les nuds de lindex. Cette structure est plaante, et il ne peut donc y avoir quun seul arbre-B pour une table. Oracle nomme index-organized tables la structure darbre-B. Elle est toujours construite sur la cl primaire dune table, des index secondaires (en arbre-B+ cette fois) pouvant toujours tre ajouts sur dautres colonnes. la diffrence de ce qui se passe quand la table est stocke dans une structure squentielle, un enregistrement nest pas identi par son ROWID mais par sa cl primaire. En effet les insertions ou destructions entranent des rorganisations de lindex qui amnent dplacer les enregistrements. Les pointeurs dans les index secondaires, au niveau des feuilles, sont donc les valeurs de cl primaire des enregistrements. tant donn un cl primaire obtenue par traverse dun index secondaire, laccs se fait par recherche dans larbre-B principal, et non plus par accs direct avec le ROWID. Une table organise en arbre-B fournit un accs plus rapide pour les recherches bases sur la valeur de cl, ou sur un intervalle de valeur. La traverse dindex fournit en effet directement les enregistrements, alors quelle ne produit quune liste de ROWID dans le cas dun arbre-B+. Un autre avantage, moins souvent utile, est que les enregistrements sont obtenus tris sur la cl primaire, ce qui peut faciliter certaines jointures, ou les requtes comportant la clause ORDER BY. En contrepartie, Oracle met en garde contre lutilisation de cette structure quand les enregistrements sont de taille importante car on ne peut alors mettre que peu denregistrements dans un nud de larbre, ce qui risque de faire perdre lindex une partie de son efcacit. Pour crer une table en arbre-B, il faut indiquer la clause ORGANIZATION INDEXED au moment du CREATE TABLE. Voici lexemple pour la table Internaute, la cl primaire tant lemail. CREATE TABLE Internaute (email VARCHAR (...), ... PRIMARY KEY (email), ORGANIZATION INDEX)
8.5.3 Indexation de documents

Oracle ne fournit pas explicitement de structure dindex invers pour lindexation de documents, mais propose dutiliser une table en arbre-B. Rappelons quun index invers est construit sur une table contenant typiquement trois attributs : 1. le mot-cl apparaissant dans le ou les document(s) ; 2. lidentiant du ou des documents o gure le mot ; 3. des informations complmentaires, comme le nombre doccurrences. Il est possible de crer une table stocke squentiellement, et de lindexer sur le mot-cl. Linconvnient est que cest aors une arbre-B+ qui est cr, ce qui implique un accs supplmentaire par ROWID pour chaque recherche, et la duplication des cls dans lindex et dans la table. La structuration de cette table par un arbre-B est alors recommande car elle rsout ces deux problmes.
8.5.4 Tables de hachage

Les tables de hachage sont nommes hash cluster dans Oracle. Elles sont cres indpendamment de toute table, puis une ou plusieurs tables peuvent tre affectes au cluster. Pour simplier nous prendrons le cas o une seule table est affecte un cluster, ce qui correspond une organisation par hachage semblable semblable celle que nous avons prsente prcdemment. Il est important de noter que le hachage dans Oracle est statique.
8.5. INDEXATION DANS ORACLE
148
Remarque : Il existe dans Oracle un autre type de regroupement dit indexed cluster, qui nest pas prsent ici. Elle consiste grouper dans des blocs les lignes de plusieurs tables en fonction de leurs cls. La cration dune table de hachage seffectue en deux tapes. On dnit tout 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 HachFilms (id INTEGER) SIZE 500 HASHKEYS 500; CREATE TABLE Film (idFilm INTEGER, ... ) CLUSTER HachFilms (idFilm) La commande CREATE CLUSTER, combine avec la clause HASHKEYS, cre une table de hachage dnie par paramtres suivants : 1. la cl de hachage est spcie dans lexemple comme tant un id de type INTEGER : 2. le nombre dentres 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 type). Il est cependant possible pour ladministrateur de donner sa propre 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 4 096 octets, Oracle affectera alors entres de la table de hachage un mme bloc. Cela tant, si une entre ocupe elle seule tout le bloc, les autres seront insres dans un bloc de dbordement. Pour structurer une table en hachage, on laffecte 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 par extensible, cette technique est rserve des situations particulires.
8.5.5 Index bitmap

Oracle propose une indexation par index bitmap et suggre de lutiliser ds que la cardinalit dun attribut, dni comme le nombre moyen de rptition pour les valeurs de cet attribut, est gal ou dpasse cent. Par exemple une table avec un million de lignes et seulement 10 000 valeurs diffrentes dans une colonne, cette colonne peut avantageusement tre indexe par un index bitmap. Autrement dit ce nest pas le nombre de valeurs diffrentes qui est important, mais le ratio entre le nombre de lignes et ce nombre de valeurs. Loptimiseur dOracle prend en compte lindexation par index bitmap au mme titre que toutes les autres structures.

!
CHAPITRE 9. VALUATION DE REQUTES
149
Chapitre 9
valuation de requtes
Sommaire
9.1 Introduction loptimisation des performances . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 9.1.1 9.1.2 9.1.3 9.1.4 9.2 9.2.1 9.2.2 9.2.3 9.3 9.3.1 9.3.2 9.3.3 9.3.4 9.3.5 9.4 9.4.1 9.4.2 9.4.3 9.4.4 9.4.5 9.5 9.5.1 9.5.2 9.6 9.6.1 9.6.2 9.6.3 9.6.4 9.6.5 9.6.6 Oprations exprimes par SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Traitement dune requte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Mesure de lefcacit des oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Organisation du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Recherche dans un chier (slection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Quand doit-on utiliser un index ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Le tri externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Jointure par boucles imbriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Jointure par tri-fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Jointure par hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Jointure avec un index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Jointure avec deux index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Dcomposition en bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Traduction et rcriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Plans dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Modles de cot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Pipelinage ou matrialisation des rsultats intermdiaires . . . . . . . . . . . . . . . . . . . 179
Algorithmes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Algorithmes de jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Compilation dune requte et optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Oracle, optimisation et valuation des requtes . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Loptimiseur dORACLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Plans dexcution ORACLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Oprateurs daccs aux donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Algorithmes de jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Plans dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Plans dexcution ORACLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Utilisation de EXPLAIN et de TKPROF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Exercices dapplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9.1. INTRODUCTION LOPTIMISATION DES PERFORMANCES
150
Lobjectif de ce chapitre est de montrer comment un SGBD analyse, optimise et excute une requte. SQL tant un langage dclaratif dans lequel on nindique ni les algorithmes appliquer, ni les chemins daccs aux donnes, le systme a toute latitude pour dterminer ces derniers et les combiner de manire obtenir les meilleurs performances. Les modules chargs de ces tches (et notamment loptimiseur de requtes) ont donc un rle extrmement important puisque lefcacit dun SGBD est fonction, pour une grande part, du temps dexcution des requtes. Ces modules sont galement extrmement complexes et combinent des techniques prouves et des heuristiques propres chaque systme. Il est en effet reconnu quil est impossible de trouver en un temps raisonnable lalgorithme optimal pour excuter une requte donne. An dviter de consacrer des resources considrables loptimisation, ce qui se ferait au dtriment des autres tches du systme, les SGBD semploient donc trouver, en un temps limit, un algorithme raisonnablement bon. La comprhension des mcanismes dexcution et doptimisation fournit une aide trs prcieuse quand vient le moment danalyser le comportement dune application et dessayer de distinguer les goulets dtranglements. Comme nous lavons vu dans les chapitres consacres au stockage des donnes et aux index, des modications trs simples de lorganisation physique peuvent aboutir des amliorations (ou des dgradations) extrmement spectaculaires des performances. Ces constatations se transposent videmment au niveau des algorithmes dvaluation : le choix dutiliser ou non un index conditionne fortement les temps de rponse, sans que ce choix soit dailleurs vident dans toutes les circonsstances.
9.1 Introduction loptimisation des performances

Nous commenons par une description dassez haut niveau des diverses de traitement dune requte, suivie de quelques rappels sur les critres dvaluation de performance utiliss.
9.1.1 Oprations exprimes par SQL

La lecture de ce chapitre suppose le lecteur familier avec SQL et avec linterprtation dune requte SQL sous forme doprations ensemblistes appliques des tables (lalgbre relationnelle). Voici un bref rappel des notations utilises pour ces oprations :

1. La slection, note
, slectionne dans la table
tous les enregistrements satisfaisant le critre
Le noyau du langage SQL (en mettant part des extensions comme les fonctions, et les oprations de regroupement) permet dexprimer les mmes requtes quun petit langage de programmation contenant les seules oprations ci-dessus. Pour dcrire loptimisation, on traduit donc une requte SQL en une expression de lalgbre, ce qui permet alors de raisonner concrtement en termes doprations effectuer sur les tables.
9.1.2 Traitement dune requte

Le traitement dune requte seffectue en trois tapes (gure 9.1) : 1. Analyse de la requte : partir dun texte SQL, le systme vrie la correction syntaxique puis contrle la validit de la requte : existence des tables (ou vues) et des attributs (analyse smantique). Enn des normalisations sont effectues (par exemple en essayant de transformer une requte imbrique en requte plate) ainsi que des tests de cohrence (une clause WHERE avec le test 1 = 2 svalue toujours false).
5. La diffrence,
, calcule les enregistrements de
qui ne sont pas dans .
4. Lunion,
, effectue lunion des enregistrements des deux tables
et
3. La jointure, note
, calcule les paires denregistrements venant de
et , satisfaisant le critre ;
) 888 9994 2
2. La projection, note
, parcours tous les enregistrements de
et ne garde que les attributs
$ "!"
.
; ;
151
Le rsultat est un plan dexcution logique qui reprsente la requte sous la forme dune arbre compos des oprations de lalgbre relationnelle 1. 2. Optimisation : le plan logique est transform en un plan dexcution physique, comprenant les oprations daccs aux donnes et les algorithmes dexcution, places dans un ordre suppos optimal (ou quasi-optimal). Le choix du meilleur plan dpend des oprations physiques implantant les divers oprateurs de lalgbre, disponibles dans le processeur de requtes. Il dpend galement des chemins daccs aux chiers, cest--dire de lexistence dindex ou de tables de hachage. Enn il peut sappuyer sur des donnes statistiques enregistres ou estimes pour chaque relation (nombre denregistrements et de pages dans une relation, slectivit dun attribut, etc.). 3. Excution de la requte : le plan dexcution est nalement compil, ce qui fournit un programme dun type assez particulier. Lexcution de ce programme calcule le rsultat de la requte. Ce qui fait la particularit dun plan dexcution physique, cest en premier lieu quil sagit dun programme sous forme darbre, dans lequel chaque nud correspond une opration applique aux donnes issues des nuds infrieurs. Un mcanisme de transfert des donnes entre les nuds (pipelining) vite de stocker les rsultats intermdiaires. En second lieu, les oprations disponibles sont en nombre limites et constituent la bibliothque du processeur de requte pour crer des plans dexcution. Les principales oprations sont les algorithmes de jointure dont le choix conditionne souvent de manire dcisive lefcacit dune requte.
Requte SQL Traduction algbrique Optimisation Plan dexcution physique Evaluation requte Plan dexcution logique
F IG . 9.1 Les tapes de traitement dune requte
Les informations telles que lexistence et la spcication dindex sur une table et les donnes statistiques enregistres sont stockes dans le catalogue de la base. Celui-ci est galement reprsent sous forme de relations, gres par le systme, auxquelles ladministrateur accde simplement par des requtes SQL. Le contenu du catalogue, galement appel schma physique, est parfois dsign par le terme de mta-donnes ( des donnes sur des donnes ). Le catalogue est en gnral conserv en mmoire ce qui explique que le processus danalyse/optimisation, sil parat complexe, occupe en fait un temps ngligeable compar celui de lexcution qui est le seul engendrer des entres/sorties.
9.1.3 Mesure de lefcacit des oprations

Par valuation efcace, on entend gnralement valuation qui prend un temps le plus court possible. Loptimisation consiste trouver le plan qui minimisera le temps pris pour excuter la squence doprations. Il faut alors prendre en compte les principaux facteurs qui inuent sur ce temps dexcution, savoir : la mmoire centrale disponible ; le nombre daccs en mmoire secondaire ncessaire ; le nombre dutilisateurs accdant simultanment au systme.
1. Il sagit dune vue conceptuelle : les systmes ne sont pas requis dutiliser lalgbre, mais elle fournit pour nous un moyen simple et pratique dinterprter une requte en terme doprations sur des tables.
9.1. INTRODUCTION LOPTIMISATION DES PERFORMANCES
152
Les trois facteurs sont en partie lis. Par exemple la place disponible en mmoire centrale peut dpendre du nombre dutilisateurs. Le nombre de lectures en mmoire secondaire dpend du nombre de pages dj charges en mmoire principale, et donc de la taille de cette dernire. Il faut galement souligner que pour des applications transactionnelles, on peut chercher favoriser le dbit en nombre de transactions au dpens du temps dvaluation dune requte utilisateur, ce qui change les critres doptimisation. La complexit de prise en compte de tous ces facteurs implique que lon na aucune garantie sur loptimalit de la solution choisie. Loptimisation consiste en un certain nombre dheuristiques qui garantissent lexcution dune requte dans un dlai raisonnable. Parmi les nombreux autres facteurs, peut-tre moins important, entrant en jeu, citons les cas o lefcacit requise concerne larrive du premier rsultat (le temps de rponse ), plutt que le temps pour obtenir le rsultat total ( temps dvaluation ). Quand la taille du rsultat est importante, les stratgies doptimisation peuvent diffrer suivant quon cherche optimiser le temps de rponse ou le temps dvaluation. En particulier le pipelinage que nous verrons en n de la section sur loptimisation permet de favoriser le temps de rponse. Mesure du cot dune opration Le nombre de lectures/critures de page sur disque sera notre critre essentiel destimation du cot dune opration. Ce type destimation est justi par le fait quamener en mmoire centrale des enregistrements cote beaucoup plus cher que de les traiter en mmoire. Nous ne compterons jamais le cot dcriture du rsultat dune opration sur disque. En effet, dune part le nombre de pages crire sur disque, si ncessaire, peut tre facilement ajout : il dpend uniquement de la taille du rsultat et pas de lalgorithme. Dautre part, nous verrons dans la section sur le pipelinage que les rsultats intermdiaires ne sont pas ncessairement rcrits sur disque : chaque enregistrement est utilis par lopration suivante ds sa production. Un certain nombre de paramtres sont ncessaires pour lestimation du cot dune opration. Le premier est la et mesure en nombre de pages. est donc le nombre de pages en mmoire mmoire centrale disponible, note centrale destins contenir les entres dune opration et les rsultats intermdiaires. Le nombre de pages quoccupe sur disque une relation en entre dune opration est le deuxime paramtre, not . Enn le nombre denregistrements dune table est not .
9.1.4 Organisation du chapitre

Ce chapitre se concentre sur les tapes doptimisation et dexcution dune requte. La phase danalyse relve de techniques classiques danalyse syntaxique et de compilation, et ne prsente pas vraiment dintrt du point de vue des performances. Nous commenons (section 9.2, page 153) par dcrire les principaux algorithmes daccs et de manipulation des donnes : tri, slection, et surtout jointures. Nous expliquons ensuite (section 9.4, page 170) comment ces algorithmes sont combins durant la phase doptimisation pour former des plans dexcution. Enn le chapitre se conclut par une prsentation dtaille du mcanisme doptimisation et dvaluation des requtes dans le SGBD Oracle (section 9.5, page 181). Les exemples sont bass sur le schma de base de donnes suivant, les champs en gras indiquant comme dhabitude la cl primaire : Film (idFilm, titre, anne, genre, rsum, idMES, codePays) Artiste (idArtiste, nom, prnom, anneNaissance) Role (idActeur, idFilm, nomRle) Internaute (email, nom, prnom, rgion) Notation (email, idFilm, note) Pays (code, nom, langue) On supposera de plus, occasionnellement, que les artistes sont identis de manire unique par leur nom et prnom. Une partie des exercices proposs pour accompagner ce chapitre consiste exprimenter loptimiseur dOracle, et tester les diffrences de performances obtenues en modiant lorganisation physique dune (grosse) base de donnes.
153
Le site http://cortes.cnam.fr:8080/CoursBD propose un petit outil de gnration qui permet dengendrer quelques centaines de milliers ou millions de lignes, la demande, dans la base Films (le script de cration se trouve galement sur le site). partir de cette base, on peut tester les outils dcrits dans la section 9.5 et obtenir une ide concrte de limportance dune administration avise pour obtenir des applications performantes.
9.2 Algorithmes de base

Lvaluation dune requte consiste excuter une squence doprations appliques des enregistrements lus dans des chiers. Pour chaque opration, il existe plusieurs algorithmes possibles, dont lefcacit dpend de la prsence ou non dindex, de la taille des relations, de la slectivit des attributs, etc. Cette section est consacre aux principaux oprateurs utiliss dans lvaluation dune requte. Nous commenons par la recherche dans un chier (opration de slection), qui peut se faire par balayage ou par accs direct. Le tri est une autre opration fondamentale pour lvaluation des requtes. On a besoin du tri par exemple lorsquon fait une projection ou une union et quon dsire liminer les enregistrements en double (clauses DISTINCT ou ORDER BY de SQL). On verra galement quun algorithme de jointure courant consiste trier au pralable sur lattribut de jointure les relations joindre. Enn cette section consacre une part importante aux algorihmes de jointures. La jointure est une des oprations les plus courantes et les plus coteuses, et savoir lvaluer de manire efcace est une condition indispensable pour obtenir un systme performant. Les algorithmes couramment utiliss dans les SGBD relationnels sont dcrits : jointure par boucles imbriques, jointure par tri-fusion et jointure par hachage.
9.2.1 Recherche dans un chier (slection)

Il existe deux algorithmes pour effectuer une recherche dans un chier (ou une slection dans une table, pour employer un vocabulaire de plus haut niveau) en fonction dun critre de recherche : 1. Accs squentiel ou balayage. Tous les enregistrements du chier sont examins lors de lopration, en gnral suivant lordre dans lequel ils sont stocks. 2. Accs par adresse. Si on connat ladresse du ou des enregistrements concerns, on peut aller lire directement les blocs et obtenir ainsi un accs optimal. Voici une description de ces deux mthodes, avant de discuter des situations o on peut les utiliser. Balayage Le balayage squentiel dune table est utile dans un grand nombre de cas. Tout dabord on a souvent besoin de parcourir tous les enregistrements dune relation, par exemple pour faire une projection. Certains algorithmes de jointure utilisent le balayage dau moins une des deux tables. On peut enn vouloir accder un ou plusieurs enregistrements dune table satisfaisant un critre de slection. Dans le cas de la slection, le balayage est utilis soit parce quil ny a pas dindex sur le critre de slection, soit parce que la table est stocke sur un petit nombre de pages. Lalgorithme est trs simple. Il consiste lire en squence les pages de la relation, une une, en mmoire centrale. Il suft dun tampon en mmoire pour stocker la page courante lue du disque. Les enregistrements de cette page sont parcourus squentiellement et traits au fur et mesure. Ce balayage squentiel permet de faire en mme temps que la slection une projection. Chaque enregistrement du tampon est test en fonction du critre de slection. Sil le satisfait, il est projet et rang dans un tampon de sortie. Lalgorithme ci-dessous, dnomm SelBal par la suite, rsume ces oprations. Comme la plupart des algorithmes de cette section, il correspond une boucle sur les lectures/critures de pages et une seconde boucle sur les enregistrements en mmoire centrale. p:= premire page de R; n:= premier enregistrement de p; s:= premier octet de S; Pour chaque page p de R {
9.2. ALGORITHMES DE BASE

lire p dans le tampon dentre E; pour chaque enregistrement n dans E { IF (n satisfait le critre de slection) { projeter n; IF (S plein) { vider S sur disque; s:= premier octet } ranger le rsultat dans le tampon de sortie S; incrmenter s avec la taille de la projection; } } }
154
Le cot de cette opration est donc de E/S. On essaie de limiter ce nombre non seulement en compactant les tables, mais galement en ruisant le temps de lecture dune page. Lors dun balayage, les pages du chier sont lues en squence. Si ces pages sont contigues sur disque et et si on lit plusieurs pages contigues du disque la fois, le temps de lecture sera moindre que si on lit ces pages une une (voir chapitre 7). On cherche donc : 1. regrouper les pages dune table dans des espaces contigus (appels extensions dans ORACLE) ; 2. effectuer des lectures lavance : quand on lit une page, on lit galement les pages suivantes dans lextension. Une valeur typique de est 7 ou 15. Par consquent lunit dentre/sortie dun SGBD (un bloc ou page) est souvent un multiple de celle du gestionnaire de chier, et la taille dun tampon en mmoire est en gnral un multiple de la taille dun bloc (ou page) physique. Accs direct Quand on connait ladresse dun enregistrement, donc ladresse de la page o il est stock, y accder cote une lecture unique de page. Le problme est un petit peu plus compliqu quand il sagit daccder plusieurs enregistrements dont on connat les adresses. Il peut se faire que les enregistrements soient tous dans des pages diffrentes, mais il peut arriver galement que plusieurs enregistrements soient dans la mme page. Si on a un seul tampon en mmoire ( =1) alors il est fort possible quon relise plusieurs fois la mme page. Par exemple, laccs 6 enregistrements dont les pages ont pour numros respectivement 4, 1, 3, 1, 5, 4, demandera 6 lectures de page. Les pages 1 et 4 seront lues deux fois chaque. Une manire dconomiser le nombre de lectures est de trier la liste des enregistrements lire sur ladresse de leur page. De cette manire, on conomisera le nombre de lectures, en ne lisant quune fois toutes les pages et en traitant en mme temps les enregistrements de la mme page. Dans lexemple prcdent, si les adresses des enregistrements sont . Lorsque tries avant accs la table, on ne lira que 4 pages: aprs tri, on obtient la liste de pages la page 1 (la page 4) est lue on accde aux deux enregistrements de cette page. Exemple 17 Comparons les performances de recherche avec et sans index, en prenant les hypothses suivantes : le chier fait 500 Mo, et une lecture de bloc prend 0,01 s (10 millisecondes). 1. Un parcours squentiel lira tout le chier (ou la moiti pour une recherche par cl). Donc a prendra 5 secondes. 2. Une recherche par index implique 2 ou 3 accs pour parcourir lindex, et un seul accs pour lire lenregistrement : soit s, (4 millisecondes). En gros, cest mille fois plus cher. Ces chiffres sont bien st pondrer par le fait quune bonne partie des pages du chier peuvent tre dj en mmoire.

155
9.2.2 Quand doit-on utiliser un index ?

Laccs direct suppose (sauf cas exceptionnel o on connat ladresse dun enregistrement)) quil existe un index ou une table de hachage sur la table permettant dobtenir les adresses en fonction du critre de recherche. Pour tre complet il faut signaler quil existe une troisime mthode, la recherche par dichotomie, mais elle suppose que le chier est tri sur les attributs sur lesquels seffectue la recherche, ce qui est difcile satisfaire en pratique. Le choix dutiliser le parcours squentiel ou laccs par index peut sembler trivial : on regarde si un index est disponible, et si oui on lutilise comme chemin daccs. En fait ce choix est lgrement compliqu par les considrations suivantes : 1. Le critre de recherche porte-t-il sur un ou sur plusieurs attributs ? Sil y a plusieurs attributs, les critres sont-ils combins par des and ou des or ? 2. Quelle est la slectivit de la recherche ? On constate que quand une partie signicative de la table est slectionne, il devient inutile, voire contre-performant, dutiliser un index. Le cas rellement trivial est celui frquent dune recherche avec un critre dgalit sur la cl primaire (ou plus gnralement sur un attribut index par un index unique). Dans ce cas lutilisation de lindex ne se discute pas. Exemple : SELECT * FROM Film WHERE idFilm = 100 Dans beaucoup dautres situations les choses sont un peu plus subtiles. Le cas le plus dlicat car le plus frquemment rencontr est celui dune recherche par intervalle sur un champ index. Cas des recherches par intervalle Voici un exemple simple de requte dont loptimisation nest pas vidente priori. Il sagit dune recherche par intervalle (comme toute slection avec , , ou une recherche par prxe exprime avec LIKE). SELECT * FROM Film WHERE idFilm BETWEEN 100 AND 1000 Lutilisation dun index nest pas toujours approprie dans ce cas, comme le montre le petit exemple de la gure 9.2. Dans cet exemple, le chier a quatre pages, et les enregistrements sont identis (cl unique) par un numro. On peut noter que le chier nest pas ordonn sur la cl (il ny a aucune raison priori pour que ce soit le cas). Lindex en revanche sappuie sur lordre des cls (il sagit ici typiquement dun arbre B+, voir chapitre 8). chaque valeur de cl dans lindex est associ un pointeur (une adresse) qui dsigne lenregistremet dans le chier. Maintenant supposons : 1. que lon effectue une recherche par intervalle pour ramener tous les enregistrements entre 9 et 13 ; 2. que la mmoire centrale disponible soit de trois pages. Si on choisit dutiliser lindex, comme semble y inviter le fait que le critre de recherche porte sur la cl primaire, on va procder en deux tapes. 1. tape 1 : on rcupre dans lindex toutes les valeurs de cl comprises entre 9 et 13. 2. tape 2 : pour chaque valeur obtenue dans ltape 1, on prend le pointeur associ, on lit le bloc dans le chier et on en extrait lenregistrement.
156
Index 10 11 12 13
1 13
5 ...
2 14
6 ... Page 2
10
3 ...
11
4 ...
12
Page 1
Page 3
Page 4
F IG . 9.2 Recherche par intervalle avec un index
Donc on va lire la page 1 pour lenregistrement 9, puis la page 2 pour lenregistrement 10, puis la page 3 pour lenregistrement 11. ce moment-l la mmoire (trois pages est pleine). Quand on lit la page 4 pour y prendre lenregistrement 12, on va replacer sur disque la page la plus anciennement utilise, savoir la page 1. Pour nir, on doit relire, sur le disque, la page 1 pour lenregistrement 13. Au total on a effectu 5 lectures, alors quun simple balayage du chier se serait content de 4. Cette petite dmonstration sappuie sur des ordres de grandeurs qui ne sont clairement pas reprsentatifs dune vraie base de donnes. Elle montre simplement que les accs au chier, partir dun index de type arbre B+, sont anarchiques et peuvent conduire lire plusieurs fois la mme page. Mme sans cela, des recherches par adresses intenses mnent dclencher des oprations daccs une page pour lire un enregistrement chaque fois, ce qui savre trs pnalisant. Slectivit Le seul moyen pour loptimiseur de dterminer la bonne technique est de disposer de statistiques sur la slectivit des attributs, an de pouvoir estimer, pour une slection donne, la partie dun chier concerne par cette slection. La slectivit dun attribut dune table (note ) est le rapport entre le nombre denregistrements pour lesquels a une valeur donne, et le nombre total denregistrements. Cette dnition prend lhypothse que la rpartition de valeurs de est uniforme, ce qui est loin dtre toujours le cas. Admettons pour linstant cette hypothse. La slectivit de est calcule de la manire suivante :
. 2. la slectivit de
ce qui revient aussi
Si est une cl unique, on a , , et la slectivit est gale . Il sagit du cas o lattribut est le plus slectif. Si au contraire on a un attribut dont les seules valeurs possibles sont Oui ou Non , on aura , , et la slectivit est gale . Lattribut est trs peu slectif. Si un optimiseur ne dispose pas de la slectivit dun attribut, il utilisera lindex, ce qui donnera, dans lexemple prcdent, des rsultats catastrophiques. Il est donc essentiel, dabord de faire attention quand on cre des index utiliser des attributs ayant une slectivit raisonnable, ensuite de rcolter des statistiques sur la base pour fournir loptimiseur des informations permettant de le guider dans le choix dutiliser ou non un index.
est donc
!

!

1. Soit est
le nombre de valeurs distinctes dans
, alor le nombre denregistrements ayant une valeur donne
!
157
Revenons maintenant sur lhypothse duniformit des valeurs sur laquelle sappuient les calculs prcdent. Si cette hypothse nest pas vrie en pratique, cela peut mener loptimiseur commetre des mauvais choix. Le fait par exemple davoir 1 % de Oui et 99 % de Non devrait linciter utiliser lindex pour une recherche sur les Non , et un balayage pour une recherche sur les Oui . Une technique plus sophistique consiste grer des histogrammes dcrivant la rpartition des valeurs dun attribut et permettant destimer, pour un intervalle donn, la partie de la table qui sera slectionne. le principe dun histogramme est de dcouper les enregistrements en groupes, chaque groupe contenant des valeurs proches. Il existe deux types dhistogrammes : Les histogrammes en hauteur : les valeurs prises par un attribut sont tries, puis divises en intervalles gaux ; chaque intervalle on associe alors le nombre denregistrements pour lesquels lattribut analys a une valeur appartenenant .
La gure 9.3 montre deux exemples dhistogrammes, lun en hauteur, lautre en largeur. Le premier nous indique par exemple quil y a 8 % des donnes entre les valeurs 70 et 80. Connaissant le nombre total de lignes dans la table, on en dduit la slectivit de la requte portant sur cette partie des valeurs. Les histogrammes peuvent tre tenus jour automatiquement par le systme, ou crs explicitement par ladministrateur. Nous verrons dans la section 9.5 comment effectuer ces oprations sous ORACLE.
12 8 20 0 10 20 30 40 50 60 70 80 90 100 (a) Histogramme en hauteur 0 20 20 42 61 70 20 90 20 100
(b) Histogramme en largeur
F IG . 9.3 Exemples dhistogrammes
Index ou pas index ? Quelques autres exemples Voici quelques autres exemples, plus faciles traiter. SELECT FROM WHERE AND * Film idFilm = 20 titre = Vertigo
Ici on utilise videmment lindex pour accder lunique lm (sil existe) ayant lidentiant 20. Puis, une fois lenregistrement en mmoire, on vrie que son titre est bien Vertigo. Voici le cas complmentaire : SELECT FROM WHERE OR * Film idFilm = 20 titre = Vertigo
On peut utiliser lindex pour trouver le lm 20, mais il faudra de toutes manires faire un parcours squentiel pour rechercher Vertigo. Autant donc spargner la recherche par index et trouver les deux lms au cours du balayage.
Les histogrammes en largeur : on trie les enregistrements sur lattribut, et on dnit alors les sorte que chacun contienne le mme nombre denregistrements.
intervalles de tel
158
9.2.3 Le tri externe

Le tri dune relation sur un ou plusieurs attributs utilise lalgorithme de tri-fusion. Celui-ci est du type diviser pour rgner 2 Voici les deux tapes de lalgorithme : 1. Dcoupage de la table en partitions telles que chaque partition tienne en mmoire centrale et tri de chaque partition en mmoire. On utilise en gnral lalgorithme de Quicksort. 2. Fusion des partitions tries. Regardons en dtail chacune des phases. Phase de tri pages en mmoire. On prend un fragment constitu des Supposons que nous disposons pour faire le tri de premires pages du chier et on les charge en mmoire. On les trie alors avec Quicksort et on crit le fragment tri sur le disque (gure 9.4). On recommence avec les pages suivantes du chier, jusqu ce que tout le chier ait t lu par fragments de , lissue de cette phase on a partitions tries, o est le nombre de blocs du chier.
M pages ... Lecture Disque Fichier trier Ecriture ... Fragments tris ... ... ... Mmoire principale
F IG . 9.4 Algorithme de tri-fusion : phase de tri
Phase de fusion La phase de fusion consiste fusionner rcursivement les partitions. chaque tape on obtient des partitions tries plus grosses, et le processus termine quand la dernire fusion dlivre la relation tout entire. Commenons par regarder comment on fusionne en mmoire centrale deux listes tries et . On a besoin de trois tampons. Dans les deux premiers, les deux listes trier sont stockes. Le troisime tampon sert pour le rsultat cest--dire la liste rsultante trie. Lalgorithme est donn ci-dessous. Par convention, lorsque tous les lments de ( ) ont t lus, llment suivant est gal eof. Remarquons que:
La premire tape de la phase de fusion de la relation consiste fusionner les fragments tris obtenues aprs la phase de tri. On prend fragments la fois, et on leur associe chacun un tampon en mmoire, le tampon restant tant consacr la sortie. On commence par lire le premier bloc des premiers fragments dans les premiers blocs, et on applique lalgorithme de fusion. Les enregistrements tris sont stocks dans un nouveau fragment sur disque.
2. Ce type dalgorithme a deux phases. Dans la premire phase on dcompose le problme rcursivement en sous problmes jusqu ce que chaque sous-problme puisse tre rsolu de faon simple. La deuxime phase consiste fusionner rcursivement les solutions.
Si on fusionne
listes de taille pages chacune, la liste rsultante a une taille de
pages.
Lalgorithme fus se gnralise facilement au cas de listes
tampons, o on fusionne en mme temps
159
a= premier lment de A; b= premier lment de B; tant quil reste un lment dans A ou B { si a avant b { si tampon sortie T plein { vider T } crire a dans T a= lment suivant dans A } sinon { si tampon sortie T plein { vider } crire b dans T b= lment suivant dans B } }
F IG . 9.5 Algorithme de fusion de deux listes On continue avec les blocs suivants de chaque partition, jusqu ce que les partitions initiales aient . On rpte le processus t entirement lues et tries On a alors sur disque une nouvelle partition de taille avec les partitions suivantes, etc. la n de cette premire tape, on obtient partitions tries, chacune (sauf la dernire qui est plus petite) ayant pour taille blocs. et que la table La premire phase de la fusion est rsume par lalgorithme ci-dessous en supposant que est reprsente par un ensemble de chiers, un par fragment tri. Le rsultat est un ensemble de fragment.
Tant quil reste deux partitions lire dans P { p= partition suivante dans P q= partition suivante dans P pour chaque bloc b dans p, bloc c dans q { lire b dans le premier tampon lire c dans le deuxime tampon fusion (b,c). } mettre la partition rsultat dans P } Sil reste une partition p dans P { mettre p dans P }
160
La deuxime tape consiste recommencer le mme processus mais avec fois moins de partitions chacune tant fois plus grande. La gure 9.6 rsume la phase de fusion. La phase de fusion peut tre reprsente par un arbre, chaque noeud (agrandi droite) correspondant une fusion de partitions.
fragments tris
... ... ...

fragments initiaux o i1 i2 i(m1) i1 i2 i(m1) o
...
fragments initiaux fragment en sortie
F IG . 9.6 Algorithme de tri-fusion : la phase de fusion
Un exemple est donn dans la gure 9.7 sur un ensemble de lms quon trie sur le nom du lm. Il y a trois phases de fusion, partir de 6 fragments initiaux que lon regroupe 2 2.
Annie Hall, Brazil, Easy Rider, Greystoke, Jurassic Park, Manhattan, Metropolis, Physchose, Shining, Twin Peaks, Underground, vertigo fusion Annie Hall, Brazil, Jurassic Park, Twin Peaks, Underground, Vertigo fusion Annie Hall, Brazil, Twin Peaks, Vertigo fusion Annie Hall, Vertigo Brazil, Twin Peaks Jurassic Park, Underground Easy Rider, Greystoke, Manhattan, Metropolis, Psychose, Shining fusion Greystoke, Psychose Metropolis,Shining fusion Metropolis, Psychose Greystoke, Shining Manhattan, Easy Rider
F IG . 9.7 tri-fusion: un exemple
Cot du tri-fusion La phase de tri cote lectures et critures pour crer les partitions tries. chaque tape de la phase fusion, chaque fragment est lu une fois et les nouveaux fragments crs sont fois plus grands mais fois moins nombreux. Par consquent chaque tape (pour chaque niveau de larbre de fusion), il y a entres/sorties. Le nombre dtapes cest--dire le nombre de niveaux dans larbre est . Par consquent le cot de la phase

de fusion est
161
. Il prdomine celui de la phase de tri. En rsum, le cout de lalgorithme de tri-fusion est . En pratique, un niveau de fusion est en gnral sufsant. Idalement, le chier trier tient compltement en mmoire et la phase de tri suft pour obtenir un seul fragment tri, sans avoir effectuer de fusion par la suite. Si possible, on peut donc chercher allouer un nombre de page sufsant lespace de tri pour que tout le chier puisse tre trait en une seule passe. Il faut bien raliser que les performances ne samliorent pas de manire continue avec lallocation de mmoire supplmentaire. En fait il existe des seuils qui vont entraner un tape de fusion en plus ou en moins, avec des diffrences de performance notables, comme le montre lexemple suivant.
Exemple 18 Prenons lexemple du tri dun chier de 75 000 pages de 4 096 octets, soit 307 Mo. Voici quelques calculs, pour des tailles mmoires diffrentes.
(a) on divise le chier en fragments. Chaque fragment est tri en mmoire et stock sur le disque. On a lu et crit une fois le chier en entier, soit 714 Mo.
fragments. Chaque fragment est tri en mmoire et stock sur le disque. (a) on divise le chier en On a lu et crit une fois le chier en entier, soit 714 Mo. (b) On associe les 249 premiers fragments une page en mmoire, et on effectue la fusion (on garde la dernire page pour la sortie). On obtient un nouveau fragment de taille Mo. On prend les fragments qui restent et on les fusionne : on obtient , de taille 58 Mo. On a lu et crit encore une fois le chier, pour un cot total de Mo.
Il est remarquable quavec seulement 2 Mo, on arrive trier en une seule tape de fusion un chier qui est 150 fois plus gros. Il faut faire un effort considrable dallocation de mmoire (passer de 2 Mo 307) pour arriver liminer cette tape de fusion. Noter quavec 300 Mo, on garde le mme nombre de niveaux de fusion quavec 2 Mo (quelques techniques subtiles permettent quand mme dobtenir de meilleures performances dans ce cas). En revanche, avec une mmoire de 1 Mo, on doit effectuer une tape de fusion en plus, ce qui reprsente plus de 700 E/S supplmentaires. En conclusion : on doit pouvoir effectuer un tri avec une seule phase de fusion, condition de connatre la taille des tables qui peuvent tre trier, et dallouer une mmoire sufsante au tri.
9.3 Algorithmes de jointure

On peut classer les algorithmes de jointure en deux catgories, suivant labsence ou la prsence dindex sur les attributs de jointure. Nous allons prsenter successivement trois algorithmes de la premire catgorie et deux algorithmes de la seconde catgorie.
(c) Finalement on prend les deux derniers fragments, de plus, soit Mo.
et
, et on les fusionne. Cela reprsente une lecture

3. Avec une mmoire
, soit 250 pages.

(b) On associe chaque fragment une page en mmoire, et on effectue la fusion (noter quil reste pages disponibles). On a lu encore une fois le chier, pour un cot total de Mo.

2. Avec une mmoire
1. Avec une mmoire
, soit 500 pages.
, tout le chier peut tre charg et tri en mmoire. Une seule lecture suft.
9.3. ALGORITHMES DE JOINTURE

Jointure sans index Les trois algorithmes les plus rpandus sont les suivants :
162
1. Lalgorithme le plus simple est la jointure par boucles imbriques. Il est malheureusement trs coteux ds que les tables joindre sont un tant soit peu volumineuses. 2. Lalgorithme de jointure par tri-fusion est bas, comme son nom lindique, sur un tri pralable des deux tables. Cest le plus ancien et le plus rpandu des concurrents de lalgorithme par boucles imbriques, auquel il se compare avantageusement ds que la taille des tables dpasse celle de la mmoire disponible. 3. Enn la jointure par hachage est un technique plus rcente qui donne de trs bons rsultats quand une des tables au moins tient en mmoire. Jointure avec index 1. Quand une des tables est indexe sur lattribut de jointure, on utilise une variante de lalgorithme par boucles imbriques avec traverse dindex, dite jointure par boucles indexe. 2. Enn si les deux tables sont indexes, on utilise parfois une variante du tri-fusion sur les index, mais cette technique pose quelques problmes et nous ne lvoquerons que brivement. On notera et les relations joindre et la relation rsultat. Le nombre de pages est not respectivement par et . Le nombre des enregistrements de chaque relation est respectivement et . On prcisera pour chaque algorithme sil peut tre utilis quel que soit le prdicat de jointure.
9.3.1 Jointure par boucles imbriques

Cet algorithme sadapte tous les prdicats de jointure. Il consiste numrer tous les enregistrements dans le produit cartsien de et (en dautres termes, toutes les paires possibles) et garde ceux qui satisfont le prdicat de jointure. La technique employe est un exemple de ce que nous avons appel technique ditration. On balaye lune des deux relations, disons , appele relation extrieure. Pour chaque enregistrement de , on balaye entirement lautre relation , appele relation intrieure. Pour chaque enregistrement de , on compare lattribut de jointure de avec celui de . Si le prdicat de jointure est satisfait, on concatne et dans un tampon quon vide sur disque lorsquil est plein. La technique est rsume par la procdure BIM (R, S) ci-dessous.
Pour chaque r dans R { Pour chaque s dans S { si r et s sont joignables pour donner t, alors si T est plein vider T sur disque, sinon ajouter t T } }
Illustrons cet algorithme sur un exemple. Soit les tables Films et Artistes de schma: Films(nomFilm, anne) Artistes(Nom,nomFilm) La jointure naturelle par boucles imbriques est illustre dans la gure 9.8. En fait lalgorithme prcdent ne fonctionne que si et sont entirement en mmoire centrale. Comme en gnral ce nest pas le cas, on applique une variante qui effectue une premire boucle sur les blocs, et une seconde, une fois les blocs en mmoire, sur les enregistrements quils contiennent.

Vertigo 1958 Spielberg Hitchcock Allen Lang Hitchcock Allen Kubrik Spielberg Hitchcock Allen Lang Hitchcock Allen Kubrik ....... Comparaison Association Jurassic Park Psychose Manhattan Metropolis Vertigo Annie Hall Shining Jurassic Park Psychose Manhattan Metropolis Vertigo Annie Hall Shining
163
Annie Hall 1977
Brazil 1984
F IG . 9.8 Jointure par boucles imbriques
Voici la variante la plus simple pour commencer. On lit en squence les pages de . Pour chaque page de , on lit en squence les pages de . Pour chaque page de on fait la jointure avec la page . On applique lalgorithme BIM ci-dessus pour les enregistrements de la page et les enregistrements de la page qui sont dans deux pages. Lorsque la jointure entre et est termine, on passe la page suivante de . Lorsque toutes les pages de ont t visites, on recommence tout le processus avec la page suivante de . Cet algorithme rsum ci-dessous ne ncessite donc que 3 pages en mmoire, deux pour lire une page de chaque relation et un pour le rsultat de la jointure. Le cot de la jointure avec cet algorithme est de lectures.
Pour chaque p dans pages(R) { lire p Pour chaque q dans pages(S) { lire q BIM(p,q)} }
Maintenant on peut faire beaucoup mieux en utilisant plus de mmoire. Soit la relation la plus petite. Si le nombre de pages est au moins gal , la relation tient en mmoire centrale. On la lit dans pages, et pour chaque page de on fait la jointure (procdure BIM(R, q)). La table nest lue quune seule fois. le cot est de lectures : dun cot quadratique dans les tailles des relations, lorsquon na que 3 pages, on est pass un cot linaire. Sil sagit dune qui-jointure, une variante de cet algorithme consiste hacher en mmoire laide dune fonction de hachage . Alors pour chaque enregistrement de on cherche par les enregistrements de joignables. Le cot en E/S est inchang, mais le cot CPU est linaire dans le nombre denregistrement des tables (alors quavec la procdure BIM cest une fonction quadratique du nombre denregistrements). Malheureusement il arrive souvent que ne tient pas en mmoire : . Voici alors la version la plus gnrale de la jointure par boucles imbriques (voir gure 9.9) : on dcoupe en groupes de taille pages et on utilise la variante ci-dessus pour chaque groupe. est lue une seule fois, groupe par groupe, est lue fois. On obtient un cot nal de :
C
Exemple 19 On prend lexemple dune jointure
en supposant, pour les besoins de
#'#

mmoire m2 pages Table extrieure Table intrieure
164
Sortie
F IG . 9.9 Allocation mmoire dans laointure par boucles imbriques
la cause, quil ny a pas dindex. La table Film occupe 1 000 blocs, et la table Artiste 10 000 blocs. On suppose que la blocs. mmoire disponible a pour taille 1. En prenant la table Artiste comme table extrieure, on obtient le cot suivant :

2. Et en prenant la table Film comme table extrieure :

Conclusion : il faut prendre la table la plus petite comme table extrieure. Cela suppose bien entendu que loptimiseur dispose des statistiques sufsantes. En rsum, cette technique est simple, et relativement efcace quand une des deux relations peut tre dcoupe en un nombre limit de groupes (autrement dit, quand sa taille par rapport la mmoire disponible reste limite). Elle tend vite cependant tre trs coteuse en E/S, et on lui prfre donc en gnral la jointure par tri-fusion, ou la jointure par hachage, prsentes dans ce qui suit.
9.3.2 Jointure par tri-fusion

Lalgorithme de jointure par tri-fusion que nous prsentons ici sapplique lquijointure (jointure avec galit). Cest un exemple de technique deux phases : la premire consiste trier les deux tables sur lattribut de jointure (si elles ne le sont pas dj). Ce tri facilite lidentication des paires denregistrement partageant la mme valeur pour lattribut de jointure. lissu du tri on dispose de deux chiers temporaires stocks sur disque 3 . On utilise lalgorithme de tri externe vu prcdemment pour cette premire tape. La deuxime phase, dite de fusion, consiste lire page par page chacun des deux chiers temporaires et parcourir squentiellement en parallle ces deux chiers pour trouver les enregistrements joindre. Comme les chiers sont tries, sauf cas exceptionnel, chaque page nest lue quune fois. Regardons plus en dtail la fusion. Soit lquijointure de et sur les attributs et On commence avec les premiers enregistrements et de chaque relation.
3. En fait on viter dcrire le rsultat de la dernire tape de fusion du tri, en prenant la vole les enregistrements produits par loprateur de tri. Il sagit dun exemple de petites astuces qui peuvent avoir des consquences importantes, mais dont nous omettons en gnral la description pour des raisons videntes de clart.
2. Si
on lit le deuxime enregistrement de
et on recommence.

1. Si

, on joint les deux enregistrements, on passe au deuxime enregistrement de et on fait le test , etc., jusqu ce que lenregistrement de soit tel que > . On avance alors au deuxime enregistrement de et on fait le test .

165
Donc on balaie une table tant que lattribut de jointure a une valeur infrieure la valeur courante de lattribut de jointure dans lautre table. Quand il y a galit, on fait la jointure. Ceci peut impliquer la jointure entre plusieurs enregistrements de en squence et plusieurs enregistrements de en squence. Ensuite on recommence. Voici un pseudo-code pour cet algorithme, en supposant comme dhabitude quon a trois pages en mmoire, une pour lire une page de chaque table trie, et une pour le rsultat.
tant que r diffrent de eof et s diffrent de eof { p = 1e page de R; lire p; r = 1er enregistrement de p; q = 1e page de S; lire q; s = 1er enregistrement de q; v = 1er enregistrement de q; tant que r.A < s.B { si p lu entirement { p = page suivante de R; lire p; r = 1er enregistrement de p; } sinon r = enregistrement suivant dans p; } tant que s.B < r.A { si q lu entirement { q = page suivante de S; lire q; s = 1er enregistrement de q; } sinon s = enregistrement suivant dans q; } v = s; tant que r.A= s.B { s = v; tant que s.B = r.A { joindre r et s, resultat: t; si tampon de sortie plein, vider; sinon mettre t dans tampon de sortie; s = enregistrement suivant dans q; } r = enregistrement suivant dans p; } }
La jointure par tri-fusion est illustre dans la gure 9.10 En gnral, on doit parcourir un groupe denregistrements en squence de ayant mme valeur pour , autant de fois quil y a denregistrements dans ayant la mme valeur pour (boucle tant que ). Si le groupe denregistrements de est cheval sur plusieurs pages, il va falloir rappeler plusieurs fois les mmes pages de , ce qui peut augmenter sensiblement le nombre de lectures disque 4 . Lalgorithme ci-dessus suppose que ce cas narrive jamais, et que lorsquun groupe denregistrements en squence de est joint un groupe denregistrements de , les deux groupes sont entirement dans les pages p et q courantes. L hypothse dun parcours unique de chacune des
4. Dans le pire des cas, hautement improbable, o dans et pages comme dans le cas de lalgorithme de boucles imbriques
nont quune seule valeur identique dans chaque relation, il faut lire
3. Si enn
, on passe lenregistrement suivant de .

Allen Annie Hall 1977 Spielberg Jurassic Park 1992 Allen Manhattan 1979
166
....
FUSION Allen Spielberg Allen Lang Hitchcock Kubrik Hitchcock Annie Hall Jurassic Park Manhattan Metropolis Psychose Shining Vertigo Annie Hall 1977 Brazil 1984 Easy Rider 1969 Greystoke 1984 Jurassic Park 1992 Manhattan 1979 Metropolis 1926 Psychose 1960
TRI Fichiers Artistes
TRI Fichier films
F IG . 9.10 Jointure par tri-fusion
pages des deux relations est justie au moins dans le cas o il ny a pas de dupliqus pour lattribut de jointure dans lune des relations. Ce cas est extrmement courant : par exemple lorsque lattribut de jointure est une cl ou une cl trangre. Avec lhypothse ci-dessus, le cot de la fusion est alors de lectures disque (linaire). En gnral, les relations ntant pas tries, le tri domine le cot de lalgorithme de tri-fusion qui est alors :
9.3.3 Jointure par hachage

Comme tous les algorithmes base de hachage, cet algorithme ne peut sappliquer qu une qui-jointure. Comme lalgorithme de tri-fusion (section 9.3.2, page 164), il a deux phases: une phase de partitionnement des deux relations en partitions chacune, avec la mme fonction de hachage, et une phase de jointure proprement dite. La premire phase a pour but de rduire le cot de la jointure proprement dite de la deuxime phase. Au lieu de comparer tous les enregistrements de tous les enregistrements de , on ne comparera les enregistrements de chaque partition de quaux enregistrements de la partition associe de . Le partitionnement de se fait par hachage. Soit et les attributs respectifs de lquijointure de et . Soit la fonction de hachage. Un enregistrement de ( de ) va dans la partition ( ). Les enregistrements de la partition de ne peuvent tre joints quavec les enregistrements de tels que . Ces enregistrements forment la partition de associe la partition de (voir gure 9.11). La deuxime phase consiste alors pour , lire la partition de en mmoire (la partition doit tenir entirement en mmoire), lire ensuite tous les enregistrements de la partition de associe , et comparer chacun aux enregistrements de la partition . Ceci se fait par accs squentiel de la partition. Noter que, alors que les enregistrements dune partition de doivent tre tous en mmoire centrale en mme temps, lalgorithme ne ncessite pas quune partition de rside en mmoire. Sa taille peut donc tre arbitrairement grande. Lalgorithme de jointure par hachage prsent ci-dessous suppose quon a pages pour une partition de , une page pour une partition de et une page pour le rsultat. La premire phase consiste lire squentiellement le

C )
"

mmoire Table A hachage Table B A6 B6 A1 A2 B1 B2
167
F IG . 9.11 Premire phase de la jointure par hachage
tampons, en vidant chacun chier en utilisant un balayage et hacher chaque enregistrement dans lun des des tampons lorsquil est plein dans un chier correspondant la partition. La deuxime phase consiste itrer fois (i) la lecture dune partition de en mmoire centrale dans les tampons ddis, (ii) lire page par page la partition associe de et faire la jointure en mmoire centrale (procdure BIM) de cette page avec la partition de entire, en utilisant pour le rsultat le dernier des tampons (gure 9.12).
mmoire
Fragment A Fragment
en mmoire
Sortie
F IG . 9.12 Seconde phase de la jointure par hachage
pour chaque page p de R { lire p dans premier tampon, pour chaque enregistrement r de p { si tampon h(r.A) est plein vider dans partition (R, h(r.A)); crire r dans tampon h(r.A) } } pour chaque page p de S { lire p dans premier tampon, pour chaque enregistrement s de p { si tampon h(s.B) est plein vider dans partition (S, h(s.B)); crire s dans tampon h(s.B) } } pour i=1,...,k { lire partition (R,i); pour chaque page p de partition (S,i) { Philippe Rigaux (rigaux@lri.fr), Cours de bases de donnes, 2004

lire p; BIM(partition(R,i), p) } }
168
Le cot de la premire phase de partitionnement de cet algorithme est . Chaque relation est lue entirement et hache dans les partitions qui sont recopies sur disque page par page. la n les tampons non pleins sont galement recopis sur disque dans la partition correspondante. Bien que le nombre de pages de ( ) aprs ( ). partitionnement (hachage) puisse tre lgrement suprieur, on supposera quil est gal Le cot de la deuxime phase est de . En effet les relations partitionnes sont lues une fois, partition par . Noter que cet algorithme est trs gourmand partition. Par consquent le cot total de cet algorithme est en mmoire. Il suppose que toute partition de la plus petite relation tienne entirement en mmoire centrale, cest-dire ait moins de pages. Cet algorithme est donc bien adapt aux jointures pour lesquelles une des relations est petite en taille. En supposant que les partitions de sont gales en taille, celle-ci est gale . On doit donc avoir . Donc on doit avoir approximativement . Remarques: il existe de nombreuses variantes dalgorithmes de jointure par hachage. Celle que nous avons prsente sappelle dans la littrature anglo-saxonne Grace hash join.
comme pour lalgorithme par boucles imbriques, on peut diminuer le temps CPU de la jointure en mmoire centrale (voir le paragraphe sur les boucles imbriques par bloc). si la relation est si petite quelle tient en mmoire centrale ( ), il existe une variante de lalgorithme qui consiste (i) partitionner comme ci-dessus dans lun des tampons 5 et (ii) accder squentiellement sans partitionnement pralable et faire la jointure en mmoire centrale entre et les enregistrements de lus dans un tampon. Soit un tel enregistrement. On le comparera avec les enregistrements du tampon . Pour valuer le cot de cette variante, observons que chaque relation nest lue quune fois. Le cot est alors de .
9.3.4 Jointure avec un index

Sil existe un index sur le ou les attributs de jointure de lune des relations , on applique une variante de lalgorithme des boucles imbriques, trs efcace, et utilise dans tous les SGBD. Elle prend comme relation extrieure la relation non-indexe (disons que cest ) sur laquelle on fait un accs squentiel. Pour chaque enregistrement de , sert de cl daccs lindex . La traverse de donne les adresses des enregistrements de qui peuvent tre joints avec , cest--dire ceux pour lesquels . Il suft ensuite daccder par adresse aux enregistrements et de les joindre avec . On a vit le balayage de toute la relation qui est fait pour chaque enregistrement de dans lalgorithme initial. On donne lalgorithme ci-dessous :
Pour chaque p dans pages(R) { lire p dans tampon E Pour chaque enregistrement r dans p { adresses = TRAV (I,r.A) pour chaque a dans adresses { acces par adresse au enregistrement s t= jointure de r et s si tampon resultat T plein { vider T
5. La diffrence avec lalgorithme ci-dessus est quon na quune partition pour
il faut prvoir le cas o la taille dune partition dpasse projection par hachage).
tampons (voir la mthode employe pour la

} crire t dans T } } }
169
Le cot de cet algorithme est le produit (i) du nombre de pages de par (ii) le cot de la traverse dindex suivi du cot daccs au(x) enregistrement(s) de . Celui-ci dpend du type dindex et du nombre denregistrements de , voir discussion ce sujet dans la section 9.2.2. En rsum le cot de lalgorithme de jointure est . Une variante de cet algorithme existe dans le cas o est partitionne par hachage sur la valeur de lattribut . Alors que la variante ci-dessus sapplique tous les prdicats de jointure, la variante avec hachage ne marche que pour lquijointure.
9.3.5 Jointure avec deux index

Cet algorithme pour un prdicat avec galit est un autre exemple dalgorithme deux phases, lune de partitionnement, et lautre de jointure proprement dite. Lorsque et ont un index sur lattribut de jointure, comme les feuilles de ceux-ci sont tries sur cet attribut, en fusionnant les feuilles des index et de la mme manire que pendant la phase de fusion de lalgorithme de jointure par tri-fusion (section 9.3.2), on obtient une liste de couples dadresses denregistrements de et joindre. Dans le pire des cas, o les deux index sont non uniques, pour chaque couple de valeurs des attributs de jointure , on obtient un couple densembles dadresses des enregistrements . La deuxime phase consiste lire les enregistrements, faire la jointure et mettre le rsultat dans le tampon de sortie. Cette phase est dtaille ci-dessous dans le cas o les deux index sont denses.
'
For each a in Ar { lire r dadresse a for each b in Bs { lire s dadresse b si le tampon T est plein { vider T } joindre r et s, rsultat dans T } } Algorithme FI de jointure par fusion dindex: jointure dun couple (index denses)
La premire phase permet de dceler efcacement les jointures possibles. Le cot de cette phase de partitionnement et du nombre de est en gnral (voir discussion sur la jointure par tri-fusion) la somme du nombre de feuilles feuilles . Cet algorithme est trs intressant dans le cas o la deuxime phase daccs aux enregistrements de lune ou des deux relations nest pas ncessaire. Le cot de la deuxime phase dpend de lindex et de la taille du rsultat cest--dire des produits cartsiens. En particulier si les deux index sont denses et non uniques, non seulement on accde de nombreuses pages, mais de plus on risque de lire plusieurs fois les mmes pages. Pour viter cette lecture multiple des mmes pages, plusieurs techniques existent. Par exemple si le nombre de tampons disponibles est grand, il se peut quune page dj lue soit encore en mmoire centrale (voir discussion de la section 9.2.2). On peut galement essayer de trier les pages lire. Ceci demande de faire le produit cartsien des couples dadresses et ensuite de trier les couples dadresses des enregistrements obtenus sur les pages de la premire relation pour regrouper les enregistrements lire dans la deuxime relation par page de la premire relation. Cette dernire amlioration nempche pas des lectures multiples dune mme page de la deuxime relation. Pour toutes ces raisons, beaucoup de SGBD (dont ORACLE), en prsence dindex sur lattribut de jointure dans les deux relations, prfrent lalgorithme par boucles imbriques et traverse dindex cet algorithme.

9.4. COMPILATION DUNE REQUTE ET OPTIMISATION

Concluons cette section avec deux remarques :
170
1. Except les algorithmes bass sur une boucle imbrique avec ou sans index, les algorithmes montrs ont t conus pour le prdicat dgalit. Observons quune thetajointure pour dautres prdicats peut tre traduite par une quijointure ou un produit suivi dune slection. Naturellement, indpendamment de lalgorithme, le nombre des enregistrements du rsultat est vraisemblablement beaucoup plus important pour de telles jointures que dans le cas dgalit. 2. Cette section a montr que lventail des algorithmes de jointure est trs large et que le choix dune mthode efcace nest pas simple. Il dpend notamment de la taille des relations, des mthodes daccs disponibles et de la taille disponible en mmoire centrale. Ce choix est cependant fondamental parce quil a un impact considrable sur les performances. La diffrence entre deux algorithmes peut dans certains cas atteindre plusieurs ordres de grandeur.
9.4 Compilation dune requte et optimisation

Cette section est consacre la tche doptimisation proprement dite : comment, partir dune requte SQL, dterminer le meilleur programme pour valuer cette requte ? Nous prsentons successivement la traduction de la requte SQL en langage algbrique reprsentant les oprations ncessaires, puis les rcritures symboliques qui organisent ces oprations de la manire la plus efcace. La notion de plans dexcution est ensuite dtaille : ces plans sont des programmes en forme darbre constitus doprateurs physique (les nuds) changeant des donnes (les artes). Nous dcrivons le fonctionnement dun plan dexcution, discutons de leurs proprits, et montrons quelques exemples de plans possibles pour une mme requte. La dernire partie de cette section propose quelques algorithmes et fonctions de cot pour choisir un plan parmi les candidats.
9.4.1 Dcomposition en bloc

Nous supposerons quune requte SQL est dcompose en une collection de blocs. Loptimiseur se concentre sur loptimisation dun bloc la fois. Un bloc est une requte sans imbrication avec une seule clause SELECT, une seule clause FROM et au plus une clause WHERE, une clause GROUP BY et une clause HAVING 6 . La dcomposition en blocs est ncessaire cause des requtes imbriques. Toute requte SQL ayant des imbrications peut tre dcompose en une collection de blocs. Considrons par exemple la requte suivante qui calcule le lm le mieux ancien : SELECT titre FROM Film WHERE annee = (SELECT MIN (annee) FROM Film) On peut dcomposer cette requte en deux blocs: le premier calcule lanne minimale . Le deuxime bloc calcule le(s) lm(s) paru en grce une rfrence au premier bloc. SELECT titre FROM Film WHERE annee = (rfrence au bloc imbriqu) Bien entendu cette mthode peut savrer trs inefcace et il est prfrable de transformer la requte avec imbrication en une requte quivalente sans imbrication (un seul bloc) quand cette quivalence existe. Malheureusement de nombreux systmes relationnels sont incapables de dceler ce type dquivalence. Prenons lexemple de la requte suivante : Dans quel lm paru en 1958 joue James Stewart (vous avez sans doute devin quil sagit de Vertigo) ? Voici comment on peut exprimer la requte SQL. SELECT titre
6. Pour linstant nous laissons de ct ces deux dernires clauses.

FROM WHERE AND AND AND Film f, Role r, Artiste a a.nom = Stewart AND a.prenom=James f.idFilm = r.idFilm r.idActeur = a.idArtiste f.annee = 1958
171
Cette requte est en un seul bloc , mais il est tout fait possible question de style? de lcrire de la manire suivante : SELECT FROM WHERE AND AND titre Film f, Role r f.idFilm = r.idFilm f.annee = 1958 r.idActeur IN (SELECT idArtiste FROM Artiste WHERE nom=Stewart AND prenom=James)
Au lieu dutiliser IN, on peut effectuer une requte corrle avec EXISTS. SELECT FROM WHERE AND AND titre Film f, Role r f.idFilm = r.idFilm f.annee = 1958 EXISTS (SELECT x FROM Artiste a WHERE nom=Stewart AND prenom=James AND r.idActeur = a.idArtiste)
Encore mieux (ou pire), on peut utiliser deux imbrications : SELECT titre FROM Film WHERE annee = 1958 AND idFilm IN (SELECT idFilm FROM Role WHERE idActeur IN (SELECT idArtiste FROM Artiste WHERE nom=Stewart AND prenom=James)) Dans ce dernier cas on a trois blocs. La requte est peut-tre facile comprendre, mais le systme a trs peu de choix sur lexcution : on doit parcourir tous les lms parus en 1958, pour chacun on prend tous les rles, et pour chacun de ces rles on va voir sil sagit bien de James Stewart. Sil ny a pas dindex sur le champ annee de Film, il faudra balayer toute la table, puis pour chaque lm, cest la catastrophe : il faut parcourir tous les rles pour garder ceux du lm courant (notez quil nexiste pas dindex sur les lms pour accder Role). Enn pour chacun de ces rles il faut utiliser lindex sur Artiste. Telle quelle, cette dernire syntaxe a toutes les chances dtre extrmement coteuse valuer. Or il existe un plan bien meilleur (lequel ?) mais le systme ne peut le trouver que sil a des degrs de libert sufsants, autrement dit quand la requte est plat , en un seul bloc. Il est donc recommand de limiter lemploi des requtes imbriques de petites tables dont on est sr quelles rsident en mmoire.
172
9.4.2 Traduction et rcriture

Nous nous concentrons maintenant sur le traitement dun bloc, tant entendu que ce traitement doit tre effectu autant de fois quil y a de blocs dans une requte. Il comprend plusieurs phases. Tout dabord une analyse syntaxique est effectue, puis une traduction algbrique permettant dexprimer la requte sous la forme dun ensemble doprations sur les tables. Enn loptimisation consiste trouver les meilleurs chemins daccs aux donnes et choisir les meilleurs algorithmes possibles pour effectuer ces oprations. Analyse syntaxique Lanalyse syntaxique vrie la validit (syntaxique) de la requte. On vrie notamment lexistence des relations (arguments de la clause FROM) et des attributs (clauses SELECT et WHERE). On vrie galement la correction grammaticale (notamment de la clause WHERE). Dautres transformations smantiques simples sont faites au del de lanalyse syntaxique. Par exemple, on peut dtecter des contradictions comme anne = 1998 and anne = 2003. Enn un certain nombre de simplications sont effectues. Traduction algbrique Ltape suivante du traitement dune requte consiste la traduire en une expression algbrique . Voici lexpression algbrique correspondant la requte prcdente. Nous allons prendre pour commencer une requte un peu plus simple que la prcdente : donner le titre du lm paru en 1958, o lun des acteurs joue le rle de John Ferguson (rassurez-vous cest toujours Vertigo). Voici la requte SQL : SELECT FROM WHERE AND AND titre Film f, Role r nomRole =John Ferguson f.idFilm = r.idFilm f.annee = 1958
Cette requte correspond aux oprations suivantes : une jointure entre les rles et les lms, une slection sur les lms (anne=1958), une slection sur les rles (John Ferguson), enn une projection pour liminer les colonnes non dsires. La combinaison de ces oprations donne lexpression algbrique suivante :
Cette expression comprend des oprations unaires (un seul argument) et des oprations binaires. On peut la reprsenter sous la forme dune arbre (gure 9.13), ou Plan dExcution Logique (PEL). Cest en fait un arbre reprsentant lexpression algbrique quivalente la requte SQL 7 . Dans larbre, les feuilles reprsentent les tables arguments de lexpression algbrique. Les nuds internes correspondent aux oprateurs algbriques. Un arc entre un noeud et son noeud pre correspond la relation rsultat de lopration et argument dentre de lopration .
Film
Role
F IG . 9.13 Expression algbrique sous forme arborescente
7. Toute requte SQL a une expression algbrique quivalente.
! $ '
3
3 ( $ !
4 3 2 &# $0 0# &# 1 ) ( '
B
B$
% # &$
$ B %

" !

$ $ E ##
173
Linterprtation de larbre est la suivante. On commence par excuter les oprations sur les feuilles (ici les slections) ; sur le rsultat, on effectue les oprations correspondant aux nuds de plus haut niveau (ici une jointure), et ainsi de suite, jusqu ce quon obtienne le rsultat (ici aprs la projection). Cette interprtation est bien sr rendue possible par le fait que tout oprateur prend une table en entre et produit une table en sortie. Lois algbriques On peut amliorer le PEL obtenu par traduction de la requte SQL grce lexistence de proprits sur les expressions de lalgbre relationnelle. Ces proprits appeles lois algbriques ou encore rgles de rcriture permettent de transformer lexpression algbrique en une expression quivalente et donc de ragencer larbre. Le PEL obtenu est quivalent, cest--dire quil conduit au mme rsultat. En transformant les PEL grce ces rgles, on peut ainsi obtenir des PEL qui sexcutent plus rapidement. Voici la liste des rgles de rcriture les plus importantes : 1. Commutativit des jointures : 2. Associativit des jointures :
5. Commutativit de la slection et de la jointure. 6. Distributivit de la slection sur lunion. NB : valable aussi pour la diffrence.
Ces rgles simples sont trs utiles. Par exemple la rgle 3 permet des slections trs efcaces. En effet si la relation est indexe sur lattribut , la rgle justie de ltrer sur seulement les enregistrements satisfaisant le critre obtenus par traverse dindex. La commutatitivit de la projection avec la slection et la jointure (rgles 4 et 7) dune part et de la slection et de la jointure dautre part (rgle 5) permettent de faire les slections et les projections dabord pour rduire les tailles des relations manipules, ce qui est lide de base pour le choix dun meilleur PEL. En effet nous avons vu que lefcacit des algorithmes implantant les oprations algbriques est trs sensible la taille des relations en entre. Ceci est plus particulirement vrai pour la jointure qui est une opration chre. Donc quand une squence comporte une jointure et une slection, il est prfrable de faire la slection dabord : on rduit ainsi la taille dune ou des deux relations joindre, ce qui peut avoir un impact considrable sur le temps de traitement de la jointure. Pousser les slections le plus bas possible dans larbre, cest--dire essayer de les appliquer le plus rapidement possible et liminer par projection les attributs non ncessaires pour obtenir le rsultat de la requte sont donc les deux ides pour transformer un PEL en un PEL quivalent meilleur. Voici un algorithme simple rsumant ces ides : 1. Sparer les slections avec plusieurs prdicats en plusieurs slections un prdicat (rgle 3). 2. Descendre les slections le plus bas possible dans larbre (rgles 4, 5, 6) 3. Regrouper les slections sur une mme relation (rgle 3).

8. Distributivit de la projection sur lunion
I 98988 5 )
98988 5
) 98988 5 2 %( ! 8 '% "' 0 98982 F 9898 8 2 9898989888 22 ) )
7. Commutativit de la projection et de la jointure

% "' 9898984 5
4. Commutativit de la slection et de la projection
0 ! E ! )
4 2
3. Regroupement des slections :
! ! ! !7GE"6 ) 7E"6 %E"0 9898984 5 4 2 !
6
E! %3F
! "
! E!
! ! 7GE"6 !
) 0
6
! " 7"6 ! E!
! E!
)
)
6

4. Descendre les projections le plus bas possible (rgles 7 et 8). 5. Regrouper les projections sur une mme relation. Un exemple
174
Reprenons notre requte cherchant le lm paru en 1958 dans lequel gure James Stewart. Voici lexpression algbrique complte. Notez quon a group toutes les slections en une, place aprs les jointures.
Lexpression est correcte, mais videmment inutilement coteuse valuer. Appliquons notre algorithme. La premire tape donne lexpression suivante :
On a donc spar les slections. Maintenant on les descend dans larbre :
Finalement il reste ajouter des projections pour limiter la taille des enregistrements. Pour conclure deux remarques sont ncessaires : 1. le principe slection avant jointure conduit dans la plupart des cas un PEL plus efcace. Mais il peut arriver (rarement) que la jointure soit plus rductrice en taille et que la stratgie jointure dabord, slection ensuite , conduise un meilleur PEL. 2. cette optimisation du PEL, si elle est ncessaire, est loin dtre sufsante. Il faut ensuite choisir le meilleur algorithme pour chaque opration du PEL. Ce choix va dpendre des chemins daccs et des statistiques sur les tables de la base et bien entendu des algorithmes dvaluation implants dans le noyau. Le PEL est alors transform en un plan dexcution physique. Cette transformation constitue la dernire tape de loptimisation. Elle fait lobjet de la section suivante.
9.4.3 Plans dexcution

Un plan dexcution physique (PEP) est une squence doprations (on parle dalgbre physique) propres au SGBD 8 . Dans la section 9.2 nous avons vu les algorithmes implantant les principales oprations. Nous redonnons ici une liste doprateurs physiques quon retrouve dans tous les SGBD. Choix dun plan dexcution Le choix du PEP dpend de nombreux facteurs : chemin daccs, statistiques, nombre de pages en mmoire centrale. Typiquement en fonction de ces paramtres, loptimiseur choisit, pour chaque nud du PEL, une opration physique ou une squence doprations. La premire difcult vient du grand nombre de paramtres. Une autre difcult vient du fait que le choix dun algorithme pour un nud du PEL peut avoir un impact sur le choix dun algorithme pour le nud suivant dans le PEL. Nous ne regarderons pas ce problme. Disons pour simplier que la connaissance ou lestimation de la taille du rsultat dune opration est utile pour le choix de lopration suivante. Par ailleurs un autre problme difcile est la rpartition de la mmoire disponible entre les diffrentes oprations (voir section 9.4.5). La connaissance des chemins daccs aux tables restreint le choix doprations physiques pour une opration donne. Pour faire un choix dnitif, loptimiseur compare une estimation des cots des oprations restantes. Lestimation
8. Il ny a pas dinterface standard, mme si tous les diteurs ont peu prs les mmes stratgies dvaluation de requtes et implantent des algorithmes similaires pour les oprations algbriques.
! '

B E ! ( $ B
B % $
B$
B$

$ B %
!# E
# C! B
!'
!'
B E " ( $ B !
B E ! B $

B$
$ ! # E E

!# E
$ B %
# C " ( ! B
# C! B
$ $E

$ $ E # #
$ $ E # #
$ # $ E #

175
du cot dune opration physique utilise un modle de cot qui dpend de lalgorithme et qui a pour paramtres des grandeurs dont la valeur est soit connue et stocke ou bien estime. De telles grandeurs sont la taille des relations ou la slectivit dun attribut. Par exemple pour faire une slection avec un critre , sachant quil existe un index dense sur , on comparera une estimation du cot de la slection par balayage squentiel une estimation du cot par traverse de lindex. Ces estimations utilisent la taille exacte de la relation. Nous illustrerons la mthode dans ce cas simple et tudierons ensuite successivement une stratgie simplie de choix dun oprateur physique pour la slection et pour la jointure. Plan dexcution physique (PEP) Un plan dexcution physique est le rsultat de la phase doptimisation dune requte. Il contient les oprateurs physiques choisis pour valuer la requte ainsi que lordre dans lequel excuter ces oprateurs (sauf cas exceptionnel, le plan comprend plusieurs oprateurs). Le plan contient aussi des dtails comme le chemin daccs aux tables et index, et si une relation doit tre trie. Ce plan est reprsent par un arbre dont les feuilles sont les chemins daccs aux tables et index, et les nuds internes sont les oprateurs physiques. Les feuilles reprsentent les oprations effectues en premier. Larc entre un nud et son nud parent reprsente le ot de donnes entre deux oprations en squence : et . Ce ot est le rsultat de qui sert de source (entre) pour lopration . Le rsultat nal est le ot de donnes qui sort de la racine de larbre. On peut noter quune opration algbrique peut donner naissance plusieurs oprations physiques. La jointure (par boucles imbriques, par tri-fusion) est un exemple typique. Inversement, une expression algbrique de plusieurs oprations peut tre implante par une seule opration physique : par exemple le parcours squentiel dune table permet lexcution dune slection et dune projection. Quelques exemples La gure 9.14 donne une notation pour quelques oprateurs physiques courants. Cette notation sera utilise dans les exemples de plans dexcution physique plus bas.
CHEMINS DACCES
Squentiel Critre
OPERATIONS PHYSIQUES
Critre
TABLE Parcours squentiel

Adresse
Selection Slection selon un critre

Attribut(s)
Filtre Filtre dun ensemble en fonction dun autre

Critre
TABLE Accs par adresse

Attribut(s)
Tri Tri sur un attribut

Critre
Jointure Jointure selon un critre

Attribut(s)
INDEX Parcours dindex
Fusion Fusion de deux ensembles tris
Projection Projection sur des attributs
F IG . 9.14 Algbre physique
On distingue les oprations daccs des tables ou index stocks dans des chiers, des oprations de manipulation de donnes. Les oprations daccs des chiers sont reprsentes dans les arbres par des rectangles (feuilles du PEP), le nom du chier tant indiqu lintrieur du rectangle. La premire est le balayage squentiel. La deuxime est laccs par adresse, cest--dire laccs un ou plusieurs enregistrements connaissant son (leur) adresse. Le troisime enn est la traverse dindex. On indique le ou les attribut(s) cl(s).
176
Les oprations de manipulation sont reprsentes par des ellipses. Ltiquette lintrieur de lellipse est le nom de lopration. Les donnes en entre sont obtenues par les branches qui descendent du nud dans larbre. Ce sont soit le rsultat de lopration daccs, soit le rsultat dune opration lle dans larbre. Un paramtre ventuel est indiqu en haut gauche de lellipse (par exemple le(s) attribut(s) sur le(s)quel(s) est fait le tri). On reconnait les algorithmes dcrits dans la section 9.2. Le ltre est une opration utile qui ne sera pas dtaille ici. La jointure correspond lalgorithme de boucles imbriques. Cette liste est juste indicative et loin dtre complte (il y manque notamment la jointure par hachage). Voici maintenant quelques exemples de plans dexcution, en fonction dhypothses sur lorganisation de la base. Le premier plan dexcution (gure 9.15) suppose quil ny a pas dindex sur les attributs (nom, prnom) des artistes. On en est donc rduit effectuer un balayage squentiel de la table Artiste. En revanche il est possible, connaissant un artiste, dutiliser lindex sur Rle pour accder tous les rles de cet artiste. On utilise donc lalgorithme de boucles imbriques indexes. Mme remarque pour la seconde jointure : on connat lidentiant du lm (il est dans lenregistrement dcrivant un rle) donc on peut utiliser lindex. Notez que les slections se font systmatiquement en bas , au moment o on accde la table, soit en balayage, soit en accs direct.
Projection
Jointure [artiste,role] [film] 1958 [artiste] James Stewart Slection Adresse Role Adresse Film Jointure [role] Slection
Squentiel Artiste
IdArtiste Index Role(idActeur, idFilm)
idFilm Index Film (idFilm)
F IG . 9.15 Plan dexcution physique, sans index sur nom et prnom
La gure 9.16 montre le plan dexcution dans le cas o un index existe sur les nom et prnom des artistes. Ce plan est certainement optimal puisque on peut utiliser un index sur chaque table. Enn, quand il ny a pas dindex, les slections sont faites par balayage squentiel et les jointures par tri-fusion. La table Film est balaye squentiellement. La slection garde seulement les lms parus en 1958 qui sont ensuite tris sur lattribut idFilm. La table Rle est galement balaye squentiellement et trie sur lattribut idFilm. Les chiers rsultant du tri sont fusionns et tris sur lattribut idActeur. Le chier rsultant est fusionn avec les artistes nomms James Stewart, eux-mmes tris sur lattribut idArtiste et obtenus par balayage squentiel et slection de la table Artiste. Notons que : 1. lopration algbrique de slection est chaque fois traduite par un balayage squentiel (algorithme Selbal de la section 9.2. Mme si les deux oprations daccs et de slection sont faites en mme temps, on garde par souci de gnralit le dcoupage en deux oprations distinctes, lune daccs squentiel (feuille de larbre) et lautre de slection proprement dite (nud interne). La mme remarque joue pour le tri de la table Artiste. 2. chaque arc de larbre correspond un ot des enregistrements (rsultat de lopration de plus bas niveau dans
177
Projection
Jointure [artiste,role] 1958 Jointure [artiste] Adresse Artiste Adresse Rle [role] Adresse Film Selection
James Stewart Index Artiste(nom,prenom)
idArtiste
Id_cinema Index Film (idFilm) Index Role(idActeur, idFilm)
F IG . 9.16 Plan dexcution physique, avec index sur nom et prnom
Projection
Fusion idActeur Tri [film,rle] [film] idFilm Tri 1958 Slection Squentiel Film Squentiel Rle Tri Fusion [rle] idFilm idArtiste Tri James Stewart Slection Squentiel Artiste
F IG . 9.17 plan dexcution physique, sans aucun index
larbre). Soit celui-ci est stock dans un chier temporaire soit il est au fur et a mesure utilis par lopration de plus haut niveau (pipelinage, voir section 9.4.5).
178
9.4.4 Modles de cot
1. le balayage squentiel de : la table ntant pas en gnral trie sur , dans le cas du balayage squentiel, il faut parcourir toute la table et tester pour chaque enregistrement lingalit.
Lestimateur du cot de lalgorithme utilisant lindex est la somme de trois estimations: estimation du nombre de niveaux raisonnable de est:
estimation du nombre de feuilles chaines lire en squence: les feuilles de lindex sont tries sur . Lestima9 teur simpliste consiste dire qu un dixime des feuilles satisfait au critre estimation du nombre de pages de lues pour accder aux enregistrements: . Cet estimateur simpliste enregistrements satisfont le critre; (ii) pour chaque est justi par les hypothses suivantes: (i) environ enregistrement tel que il faut lire une page diffrente. Ceci est une hypothse pessimiste parce que la page lire est peut-tre encore en mmoire, ce qui suppose quun certain nombre de tampons soient disponibles en mmoire centrale. Par consquent loptimiseur choisira le balayage squentiel. Notons que 1. sil y a moins de 10 nulets par page, loptimiseur choisira toujours le balayage squentiel, 2. ce choix peut tre erron cause de lestimation simpliste du cot de lalgorithme utilisant lindex. En utilisant un histogramme des valeurs de (stock ou valu sur un chantillon), on peut arriver une estimation plus ne du nombre des enregistrements satisfaisant le critre conduisant ventuellement au choix de la stratgie avec index. Choix dun oprateur pour la slection Considrons le cas gnral dune condition de slection qui est un de conditions de la forme ou (voir note de bas de page de la section 9.4.2). Supposons pour simplier lexpos que les conditions portent sur attributs diffrents. Nous supposons galement que la relation a un index sur parmi les attributs apparaissant dans un critre. Alors loptimiseur a le choix entre le balayage squentiel (la condition complte est teste sur chaque enregistrement) et laccs par index suivi dun accs par adresse au enregistrement (et le test sur ce enregistrement des conditions restantes). Comme il y a critres portant sur un attribut avec index, loptimiseur a cas considrer. Lestimation du cot de chacun des cas est rsum ci-dessous en fonction du nombre des enregistrements , du nombre de blocs de la relation et de la slectivit de lattribut .
9. On pourrait penser quen moyenne enregistrements satisfont le critre. Lintuition du rapport ingalit donne seulement une petite fraction des enregistrements.
1. balayage squentiel:
sur
vient de ce quune requte avec
2. index:
1. balayage squentiel:
de lindex: la premire tape consiste traverser lindex. Une estimation
Pour choisir entre ces deux algorithmes, loptimiseur compare les estimations du cot
de chacun:
2. la traverse dindex: on accde la feuille contenant le couple ensuite toutes les feuilles de lindex chaines en squence. Pour chacun des couples enregistrement dadresse (une lecture de page), voir section 9.2 et chapitre 2.

Soit la slection . La table a enregistrements stocks sur unique sur . Il existe deux algorithmes pour valuer cette slection:
blocs et un index dense
et on parcourt , on accde au
179
2. stratgie avec index sur un critre avec galit (lindex est suppos tre dense et non unique, voir section 9.2): o est le cot de traverse dindex, est le nombre de feuilles en squence lire et le nombre de pages lire pour accder aux enregistrements (et tester les conditions restantes): En effet le terme numrateur indique le nombre moyen des enregistrements par valeur dindex et le dnominateur indique le nombre des enregistrements par page. . En effet est le nombre des enregistrements qui satisfont le critre. Pour chacun deux il faut accder une page (ce qui est une hypothse pessimiste, voir discussion sur lexemple de la section prcdente). En rsum lestimation du cot de cette stratgie est . 3. stratgie avec index sur un critre avec ingalit: : le premier terme concerne la traverse dindex; le terme est lestimation du nombre de feuilles parcourues et le terme est lestimation du nombre des enregistrements accds et tests sur les autres critres (voir discussion de la section prcdente) Choix dun oprateur pour la jointure Lors de ltude des algorithmes de jointure dans la section 9.2 nous avons valu le cot de chacun des algorithmes. Cette valuation peut servir de base pour un estimateur permettant loptimiseur de choisir entre plusieurs stratgies possibles. Cependant un certain nombre de critres simples aident loptimiseur dans son choix. Ceux-ci sont rsums ci-dessous: Le prdicat de jointure est-il une ingalit? Le produit cartsien suivi dune slection est une stratgie possible si la taille de ce produit est raisonnable. Cependant en gnral on choisit un algorithme simple par boucles imbriques (procdure BIS). Dans la suite on suppose que le prdicat de jointure est lgalit. Si lune au moins des deux relations a un index on utilise lalgorithme par boucles imbriques et traverse dindex (procdure BIT). Cet algorithme est dautant plus intressant que la relation extrieure (quon balaie) est plus petite (elle est par exemple le rsultat dune slection qui produit un ou quelques enregistrements) 10. La taille de la mmoire disponible est grande par rapport celle des tables: on lit les tables en mmoire et on fait la jointure en mmoire centrale (Procdure BIM). Une startgie dexception si les tables sont lgrement trop grandes consiste les dcouper en deux morceaux et faire la jointure en deux tapes. si lune des deux relations est dja trie sur lattribut de jointure, utiliser lalgorithme de tri-fusion. Sil ny a pas dindex sur lattribut de jointure, certains systmes utilisent systmatiquement cette stratgie 11 . lalgorithme de tri-fusion doit tre mis en comptition avec lalgorithme par hachage lequel est intressant si les partitions issues de sa premire phase tiennent en mmoire centrale.

9.4.5 Pipelinage ou matrialisation des rsultats intermdiaires

Mme si la phase doptimisation a choisi le meilleur plan dexcution, cest--dire la meilleure squence doprations, les performances de lexcution dpendront fortement de lespace disponible en mmoire centrale. Nous avons vu lors de ltude des algorithmes pour implanter les oprateurs, combien lespace disponible en mmoire est important pour le choix et les performances dune opration. Ce critre est dautant plus important quand on a excuter une squence de plusieurs oprateurs. Comment rpartir lespace disponible entre les diffrents oprateurs dun plan dexcution ? Si la meilleure allocation despace entre les diffrents oprateurs est un problme difcile rsoudre dans toute sa gnralit, il est nanmoins facile de minimiser lespace ncessaire pour lexcution de deux oprateurs en squence. Une manire naive dexcuter la squence doprations , , est dexcuter dabord lopration , stocker le rsultat intermdiaire en mmoire sil y a de la place ou sur disque, et dutiliser le buffer en mmoire ou le chier intermdiaire comme source de donnes pour . En gnral, la mmoire centrale disponible est trop petite pour accueillir le rsultat intermdiaire qui doit donc tre crit sur disque. Cette solution de matrialisation des rsultats intermdiaires est
10. Si les deux relations ont un index sur lalgorithme de jointure on peut utiliser la variante consistant fusionner les feuilles de lindex sil nest pas ncessaire daccder aux enregistrements des deux relations (voir discussion sur le cot de cet accs dans la section 9.2). 11. Ceci est justi si les tailles des relations sont grandes. Un autre cas justiant lutilisation de cet algorithme est que le tri dune table peut servir ultrieurement dans le mme plan (par exemple pour une autre jointure sur le mme attribut).
180
impraticable en ralit : les critures/lectures sur disque rptes entre chaque opration cotent dautant plus cher en temps que la squence doprations est longue. Lalternative appele pipelinage consiste ne pas crire les enregistrements produits par sur disque mais les utiliser immdiatement comme entre de . Autrement dit, on nattend pas que soit termine, et que lensemble des enregistrements rsultat de ait t produit pour lancer . On dmarre une opration ( ) bien avant davoir termin la prcdente ( ). On peut ainsi excuter en mme temps une squence de plusieurs oprations. On peut par exemple enchainer une slection par parcours squentiel dune table avec une jointure par boucles imbriques. Noter toutefois que cela nest pas toujours possible. Si ce nest pas possible, on est en prsence dune opration dite bloquante dont le rsultat doit tre entirement produit et crit sur disque avant de dmarrer lopration suivante. Par exemple lalgorithme de jointure par tri-fusion comporte deux oprations en squence : on trie dabord les relations joindre (oprations bloquantes), on fait ensuite la fusion du rsultat. On ne peut commencer la fusion avant que le tri soit termin. En effet la fusion commence par fusionner les articles les plus petits. Or ceux-ci peuvent trs bien tre produits la n de lopration de tri. Donc lorsque le pipelinage de deux oprations et en squence est possible, on vite lcriture des rsultats intermdiaires sur disque, et on minimise la place ncessaire en mmoire centrale. Aussitt quun article a t produit par il est utilis comme entre de : on a juste besoin de la place en mmoire ncessaire pour crire un article. En fait cest qui demande un enregistrement. Si est un opration binaire il demande chacun de ses oprations lles dans larbre, respectivement et , un enregistrement. Ce mcanisme de pipelinage la demande est implant au moyen dun arbre ditrateurs (correspondant au PEP) dont les fonctions sappellent des moments appropris. chaque oprateur physique (chaque nud dans larbre) correspond un iterateur. Les donnes demandes par litrateur implantant sont gnres par litrateur ls implantant . Avant dillustrer le mcanisme ditrateurs permettant dactiver plusieurs oprations en mme temps, dnissons plus prcisement la notion ditrateur. Cest un groupe de trois fonctions, qui permet au consommateur du rsultat dune opration physique dobtenir le rsultat article par article. Ces oprations sont: 1. Open. Cette fonction commence le processus pour obtenir des articles rsultats. Elle alloue les resources ncessaires, initialise des structures de donnes et appelle Open pour chacun de ses arguments (cest--dire pour chacun des itrateurs ls). 2. Next. Cette fonction remplit une tape de litration, retourne larticle rsultat suivant en squence et met jour les structures de donnes ncessaires pour obtenir les rsultats suivants. Pour obtenir un article rsultat, elle peut appeler une ou plusieurs fois Next sur ses arguments. 3. Close. cette fonction termine litration et libre les ressources, lorsque tous les articles du rsultat ont t obtenus. Typiquement elle appelle Close sur chacun de ses arguments. Nous illustrons la notion ditrateur en construisant deux itrateurs : celui du balayage squentiel dune table et celui de la boucle imbrique. OpenScan (R) { p:= premire page de R; n:= premier enregistrement dans la page p; FIN = false; } NextScan (R) { IF (n a depass le dernier enregistrement de la page p) { incrmenter p la page suivante; IF (pas de page suivante) { FIN := true; RETURN; }


ELSE lire page p; n:= premier enregistrement de la page p; } vieuxn:= n; incrmenter n au enregistrement suivant dans la page p; RETURN vieuxn; } CloseScan (R) { liberer ressources; RETURN; }
181
OpenScan ( ) initialise la lecture au premier enregistrement de la premire page de . La variable FIN est initialise false. NextScan ( ) retourne un enregistrement. Si la page courante a t entirement lue, il lit la page suivante et reourne le premier enregistrement de cette page. Litrateur qui appelle litrateur de balayage squentiel de commence par appeler OpenScan ( ). Tant que la variable globale FIN nest pas true, un enregistrement est retourn (vieuxn) par un appel de NextScan(R). Quand la table est entirement lue (FIN=true), I lance litrateur CloseScan (R).
9.5 Oracle, optimisation et valuation des requtes

Cette section prsente lapplication concrte des concepts, structures et algorithmes prsents dans ce qui prcde dans le SGBD ORACLE. Ce systme est un trs bon exemple dun optimiseur sophistiqu sappuyant sur des structures dindex et des algorithmes dvaluation extrmement complets. Tous les algorithmes de jointure dcrits dans ce chapitre (boucles imbriques, tri-fusion, hachage, boucles imbriques indexes) sont en effet implants dans ORACLE. De plus le systme propose des outils simples et pratiques (EXPLAIN et TKPROF) pour analyser le plan dexcution choisi par loptimiseur, et obtenir des statistiques sur les performances (cot en E/S et cot CPU, entre autres). Nous commenons par dcrire lenvironnement de loptimiseur et ses deux principaux modes, optimisation base sur les rgles (rule-based) et optimisation base sur les cots (cost-based). Nous donnons ensuite, pour un ensemble reprsentatif de requtes sur notre base exemple, les plans dexcution choisis par loptimiseur.
9.5.1 Loptimiseur dORACLE

lorigine, loptimiseur dORACLE dterminait un plan dexcution en fonction dun ensemble de rgles indiquant quels taient les chemins daccs prioritaires parmi ceux disponibles pour excuter une requte. Depuis la version 7.3, cest loptimisation par les cots qui est privilgie. Optimisation par les rgles Prenons lexemple de la requte suivante : SELECT * FROM Film WHERE ROWID = 00000DD5.000.001 Loptimiseur a le choix entre deux accs : par ladresse donne par le ROWID, ou par parcours squentiel. Les rgles (voir tableau 9.1) indiquant une priorit 1 pour le premier choix, et 15 pour le second, cest videmment la premire solution qui est choisie. Loptimisation base sur les rgles trouve ses limites dans lincapacit prdire le cot rel dun chemin daccs en fonction du degr de slectivit de la requte. Nous avons par exemple expliqu dans la section 9.2.2 quil ntait
9.5. ORACLE, OPTIMISATION ET VALUATION DES REQUTES

Priorit 1 2 3 4 ... 15 Description Accs un enregistrement par ROWID Accs un enregistrement dans un cluster Accs un enregistrement dans une table de hachage (hash cluster) Accs un enregistrement par cl unique (avec un index) ... Balayage complet de la table TAB . 9.1 Rgles pour loptimiseur
182
pas toujours pertinent dutiliser un index quand la slectivit des attributs sur lesquels portent les critres de recherche est faible. Un nouveau mode introduit partir de la version 7.3, loptimisation base sur les cots, est venu palier ces insufsances. Optimisation par les cots Ce mode sappuie sur des statistiques, et il est le seul prendre en compte les volutions rcentes du SGBD. Les index bitmap par exemple sont uniquement pris en compte dans ce mode. Il est galement plus contraignant puisquil implique la rcolte rgulire de statistiques sur les tables et attributs sensibles , savoir ceux qui inuent sur le cot des requtes. Ladministrateur de la base est responsable de la tenue jour de ces statistiques. Il existe de trs nombreux paramtres qui permettent de rgler le fonctionnement de loptimiseur bas sur les cots qui, contrairement celui bas sur les rgles, est trs exible. Parmi les plus intressants, citons les suivants : 1. OPTIMIZER_MODE indique le mode de fonctionnement de loptimiseur. Si la valeur est RULE, cest loptimisation par les rgles qui est choisie. Si la valeur est CHOOSE, loptimiseur choisit loptimisation par les cots quand les statistiques sont disponibles Ce paramtre permet galement dindiquer si le cot considr est le temps de rponse (temps pour obtenir la premire ligne du rsultat), FIRST_ROW ou le temps dexcution ALL_ROWS. 2. SORT_AREA_SIZE indique la taille de la zone de tri. 3. HASH_AREA_SIZE indique la taille de la zone de hachage. 4. HASH_JOIN_ENABLED indique que loptimiseur considre les jointures par hachage. Nous renvoyons la documentation pour les (nombreux) autres paramtres. Il faut retenir que loptimisation par les cots nest possible que si les statistiques (taille des tables et distribution des valeurs) existent pour au moins une table de la requte. Ces statistiques sont rcoltes avec loutil ANALYZE. Pour analyser une table on utilise la commande ANALYZE TABLE qui stocke la taille de la table (nombre de lignes) et le nombre de blocs utiliss. Cette information est utile par exemple au moment dune jointure pour utiliser comme table externe la plus petite des deux. Voici un exemple de la commande.
ANALYZE TABLE Film COMPUTE STATISTICS FOR TABLE;
On trouve alors les informations du tableau 9.2 dans les vues DBA_TABLES, ALL_TABLES et USER_TABLES. On peut galement analyser les index dune table, ou un index en particulier. Voici les deux commandes correspondantes.
ANALYZE TABLE Film COMPUTE STATISTICS FOR ALL INDEXES; ANALYZE INDEX PKFilm COMPUTE STATISTICS;
On trouve alors les informations du tableau 9.3 dans les vues DBA_INDEX, ALL_INDEX et USER_INDEXES. Pour nir on peut calculer des statistiques sur des colonnes. ORACLE utilise des histogrammes en hauteur (voir section 9.2.2) pour reprsenter la distribution des valeurs dun champ. Il est videmment inutile danalyser toutes les

Champ NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN NUM_FREELIST_BLOCKS AVG_SPACE_FREELIST_BLOCKS SAMPLE_SIZE LAST_ANALYZED Description Nombre de lignes Nombre de blocs Nombre de blocs non utiliss (?) Nombre moyen doctets libres dans un bloc Nombre de blocs chans Taille moyenne dune ligne Nombre de blocs dans la freelist (?) (?) Taille de lchantillon utilis Date de la dernire analyse
183
TAB . 9.2 Les champs de la vue USER_TABLES aprs analyse Champ BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR Description Nombre de niveaux de larbre B Nombre de blocs-feuille Nombre de cls distinctes Nombre moyen de blocs dans lesquels on trouve une valeur de cl. Nombre moyen de blocs de donnes lire pour une valeur de cl. Probabilit que deux enregistrements ayant des cls voisines soient galement proches dans la table. Plus ce facteur est lev, et plus il est avantageux deffectuer des recherches par intervalle avec lindex. Nombre de lignes dans la table Taille de lchantillon utilis Date de la dernire analyse
NUM_ROWS SAMPLE_SIZE LAST_ANALYSED
TAB . 9.3 Les champs de la vue USER_INDEXES aprs analyse colonnes. Il faut se contenter des colonnes qui ne sont pas des cls uniques, et qui sont indexes. Voici un exemple de la commande danalyse pour crer des histogrammes avec vingt groupes sur les colonnes titre et genre.
ANALYZE TABLE Film COMPUTE STATISTICS FOR COLUMNS titre, genre SIZE 20;
On peut remplacer COMPUTE par ESTIMATE pour limiter le cot de lanalyse. ORACLE prend alors un chantillon de la table, en principe reprsentatif (on sait ce que valent les sondages !). Les informations sont stockes dans les vues DBA_TAB_COL_STATISTICS et DBA_PART_COL_STATISTICS. Le tableau 9.4 donne les champs de ces vues. Champ NUM_DISTINCT LOW_VALUE HIGH_VALUE DENSITY NUM_NULLS NUM_BUCKETS SAMPLE_SIZE LAST_ANALYSED Description Nombre de valeurs distinctes Plus petite valeur Plus grande valeur Distribution des valeurs Nombre de champs NULL. Nombre dintervalles de lhistogramme. Taille de lchantillon utilis Date de la dernire analyse
TAB . 9.4 Les champs de la vue DBA_TAB_COL_STATISTICS aprs analyse
184
9.5.2 Plans dexcution ORACLE

Nous en arrivons maintenant la prsentation des plans dexcution dORACLE, tels quils sont donns par EXPLAIN. Ces plans ont classiquement la forme darbres en profondeur gauche, chaque nud tant un oprateur, les nuds-feuille reprsentant les accs aux structures de la base, tables, index, cluster, etc. Le vocabulaire utilis par loptimiseur est un peu diffrent de celui utilis prcdemment dans ce chapitre. Le tableau 9.5 donne la liste des principaux oprateurs, en commenant par les chemins daccs, puis les algorithmes de jointure, et enn des oprations diverses de manipulation denregistrements. Oprateur FULL TABLE SCAN ACCESS BY ROWID CLUSTER SCAN HASH SCAN INDEX SCAN NESTED LOOP SORT/MERGE HASH JOIN INTERSECTION CONCATENATION FILTER PROJECTION Description dsigne un parcours squentiel dune table dsigne un accs par adresse parcours de cluster. On rcupre alors dans une mme lecture les enregistrements des 2 tables du . parcours de hash cluster. traverse dindex. Algorithme de boucles imbriques indexes, utilis quand il y a au moins un index. Algorithme de tri-fusion. Jointure par hachage. intersection de deux ensembles denregistrements. union de deux ensembles. limination denregistrements (utilis dans un ngation). opration de lalgbre relationnelle.

TAB . 9.5 Les oprations daccs aux donnes et de jointure dans ORACLE Voici un petit chantillon de requtes sur notre base Film, en donnant chaque fois le plan dexcution choisi par ORACLE. Les plans sont obtenus par application de loptimisation par rgles : vous tes invits appliquer loptimisation par cot en utilisant les outils proposs dans la section 9.6. La premire requte est une slection sur un attribut non index (partie gauche ci-dessous). On obtient le plan dexcution nomm SelSansInd que lon peut afcher comme montr dans la partie droite 12 : Requte
EXPLAIN PLAN SET STATEMENT_ID=SelSansInd FOR SELECT * FROM Film WHERE titre = Vertigo
Plan dexcution
0 SELECT STATEMENT 1 TABLE ACCESS FULL FILM
On effectue donc un balayage complet de la table Film. Lafchage reprsente larborescence du plan dexcution par une indentation. Pour plus de clart, nous donnons galement larbre complet (gure 9.18). On y distingue les structures de la base (tables et index principalement), reprsentes par des ovales, les oprateurs daccs ces structures, en fonc, et les oprateurs de manipulation de donnes, avec un fond clair.
La gure 9.18 montre un plan trs simple : loprateur de parcours squentiel extrait un un les enregistrements de la table Film. Un ltre (jamais montr dans les plans donns par EXPLAIN, car intgr aux oprateurs daccs aux donnes) limine tous ceux dont le titre nest pas Vertigo. Pour ceux qui passent le ltre, un oprateur de projection (malencontreusement nomm S ELECT dans ORACLE ...) ne conserve que les champs non dsirs. Voici maintenant une slection avec index sur la table Film. Comme prcdemment, la partie gauche montre la
12. La section 9.6 donne des dtails techniques sur la mise en uvre de EXPLAIN et sur lafchage du rsultat


P ROJECTION
185
PARCOURS S EQUENTIEL
Film
F IG . 9.18 Plan dexcution pour une slection sans index requte avec linstruction EXPLAIN, et la partie droite le plan dexcution obtenu. Requte
EXPLAIN PLAN SET STATEMENT_ID=SelInd FOR SELECT * FROM Film WHERE idFilm=21;
Plan dexcution
0 SELECT STATEMENT 1 TABLE ACCESS BY ROWID FILM 2 INDEX UNIQUE SCAN IDX-FILM-ID
Loptimiseur a dtect la prsence dun index unique sur le table Film. La traverse de cet index donne un ROWID qui est ensuite utilis pour un accs direct la table (gure 9.19).
P ROJECTION
ACCES D IRECT
T RAVERSE I NDEX
Film
IndexFilm
F IG . 9.19 Plan dexcution pour une slection avec index
Passons maintenant aux jointures. La requte donne les titres des lms avec les nom et prnom de leur metteur en scne, ce qui implique une jointure en Film et Artiste. Le plan dexcution est donn droite : il sagit dune jointure par boucles imbriques indexes. Requte
EXPLAIN PLAN SET STATEMENT_ID=JoinIndex FOR SELECT titre, nom, prenom FROM Film f, Artiste a WHERE idMES = idArtiste;
Plan dexcution
0 SELECT STATEMENT 1 NESTED LOOPS 2 TABLE ACCESS FULL FILM 3 TABLE ACCESS BY ROWID ARTISTE 4 INDEX UNIQUE SCAN IDXARTISTE
La reprsentation graphique est sans doute plus claire pour comprendre le mcanisme (g 9.20). Tout dabord la table qui nest pas indexe sur lattribut de jointure (ici, Film) est parcourue squentiellement. Le nud B OUCLES I M BRIQUES rcupre les enregistrements Film un par un du ct gauche. Pour chaque lm on va alors rcuprer lartiste correspondant avec le sous-arbre du ct droit.

S ELECTION
186
B OUCLES I MBRIQUES
PARCOURS S EQUENTIEL
ACCES D IRECT
Film
R ECHERCHE PAR C LE idArtiste=idMES IndexArtiste -
Artiste
F IG . 9.20 Plan dexcution pour une jointure avec index On efffectue dabord une recherche par cl dans lindex avec la valeur idMES provenant du lm courant. La recherche renvoie un ROWID qui est alors utilis pour prendre lenregistrement complet dans la table Artiste. Le nud de jointure appelle alors le lm suivant, et ainsi de suite. Dans certains cas on peut viter le parcours squentiel gauche de la jointure par boucles imbriques, si une slection supplmentaire sur un attribut indexe est exprime. Lexemple ci-dessous slectionne tous les rles joues par Al Pacino. Il existe un index sur les noms des artistes qui permet doptimiser la recherche par nom, et lindex sur la table Rle est la concatnation des champs idActeur et idFilm, ce qui permet de faire une recherche par intervalle sur le prxe constitu seulement de idActeur. La requte et le plan dexcution sont donns ci-dessous, (voir gure 9.21 pour larbre correspondant). Requte
EXPLAIN PLAN SET STATEMENT_ID=JoinSelIndex FOR SELECT nomRole FROM Role r, Artiste a WHERE r.idActeur = a.idArtiste AND nom = Pacino;
Plan dexcution
0 SELECT STATEMENT 1 NESTED LOOPS 2 TABLE ACCESS BY ROWID ARTISTE 3 INDEX RANGE SCAN IDX-NOM 4 TABLE ACCESS BY ROWID ROLE 5 INDEX RANGE SCAN IDX-ROLE
Notez bien que les deux recherches dans les index seffectuent par intervalle, et peuvent donc ramener plusieurs ROWID. Dans les deux cas on utilise en effet seulement une partie des champs dnissant lindex (et un partie constituant un prxe, ce qui est impratif). On peut donc envisager de trouver plusieurs artistes nomm Pacino (avec des prnoms diffrents), et pour un artiste, on peut trouver plusieurs rles (mais pas pour le mme lm). Tout cela rsulte de la conception de la base.
Pour nir voici une requte sans index. On veut trouver tous les artistes ns lanne de parution de Vertigo (et pourquoi pas ?). La requte est donne ci-dessous : elle effectue une jointure sur les annes de parution des lms et lanne de naissance des artistes. Comme il nexiste pas dindex sur ces champs, ORACLE applique un algorithme de tri-fusion. Requte
EXPLAIN PLAN SET STATEMENT_ID=JoinSansIndex FOR SELECT nom, prenom FROM Film f, Artiste a WHERE f.annee = a.anneeNaiss AND titre = Vertigo;
Plan dexcution
0 SELECT STATEMENT 1 MERGE JOIN 2 SORT JOIN 3 TABLE ACCESS FULL ARTISTE 4 SORT JOIN 5 TABLE ACCESS FULL FILM
Larbre de la gure 9.22 montre bien les deux tris, suivis de la fusion. Au moment du parcours squentiel, on va

S ELECTION
187
J OINTURE
ACCES D IRECT
ACCES D IRECT
R ECHERCHE I NTERVALLE nom=Pacino IdxNom -
Artiste
R ECHERCHE I NTERVALLE idActeur IndexRole -
Role
F IG . 9.21 Plan dexcution pour jointure et slection avec index
ltrer tous les lms dont le titre nest pas Vertigo, ce qui va certainement beaucoup simplier le calcul de ce ct-l. En revanche le tri des artistes risque dtre beaucoup plus coteux.
S ELECTION
F USION
T RI anneNaiss PARCOURS S EQUENTIEL
T RI anne PARCOURS S EQUENTIEL
Artiste -
Film -
F IG . 9.22 Plan dexcution pour une jointure sans index (tri-fusion)
Dans un cas comme celui-l, on peut envisager de crer un index sur les annes de parution ou sur les annes de naissance. Un seul index sufra, puisquil devient alors possible deffectuer une jointure par boucle imbriques. Outre labsence, il existe de nombreuses raisons pour quORACLE ne puisse pas utiliser un index : par exemple quand on applique une fonction au moment de la comparaison. Il faut tre attentif ce genre de dtail, et utiliser EXPLAIN pour vrier le plan dexcution quand une requte sexcute sur un temps anormalement long.
9.6 Exercices
Les premiers exercices sont faire en TD. Les exercices suivants consistent exprimenter les concepts proposs avc le SGBD ORACLE, en crant une base de donnes, en lalimentant avec un nombre choisi denregistrements, et en valuant leffet de manipulations diverses sur les performances du systme.
9.6. EXERCICES
188
9.6.1 Oprateurs daccs aux donnes

Exercice 26 (Tri) Soit un chier de 10 000 pages et un buffer en mmoire centrale de 3 pages. On trie ce chier avec lalgorithme de tri-fusion. Combien de fragments sont produits pendant la premire passe ? Combien de passes faut-il pour trier compltement le chier ? Quel est le cot total en entres/sorties ? Combien faut-il de pages pour trier le chier en deux passes seulement. Rpondre aux mmes questions en prenant un chier de 20 000 pages et 5 pages de buffer, puis un chier de 2 000 000 de pages et 17 pages de buffer. Exercice 27 Donner les solutions possibles pour les oprations suivantes : Recherche dune valeur maximale (SELECT MAX() ...). limination des doublons (DISTINCT). Utilisation dun GROUP BY.

On suppose quon a un buffer de 50 pages. Donnez le nombre dentres-sorties au pire pour lalgorithme suivant : Pour chaque enregistrement r de R Pour chaque enregistrement s de S Si r.a = s.b Alors crire r.c Fin pour Fin pour Mme question pour lalgorithme suivant : Pour chaque page P de R Pour chaque page Q de S Pour chaque enregistrement r de P Pour chaque enregistrement s de Q Si r.a = s.b Alors crire r.c Fin pour Fin pour Fin pour Fin pour Donnez la solution exploitant au mieux la mmoire, pour une jointure par boucles imbriques sans index. Quelle table faut-il prendre comme table directrice ? Donner le nombe dE/S si on a un index sur a 2 niveaux. , ou un index sur , sachant que dans les deux cas la taille lindex
Dcrivez la jointure par hachage avec un buffer de 15 pages.
E
Exercice 28 (Jointures) Soit deux relations, enregistrements par page. On veut calculer
et , avec
et
. Dans les deux cas on a 10
189
9.6.2 Algorithmes de jointure

Exercice 29 Soit les relations suivantes: Directeur(nom_directeur, nom_lm) Acteur(nom_lm, nom_acteur) Soit la requte suivante :
SELECT nom_directeur, nom_acteur FROM Directeur Join Acteur WHERE Directeur.nom_film = Acteur.nom_film
Pour valuer cette requte, il faut calculer la jointure Directeur Acteur. Pour lexcution des jointures, dcrivez et valuez la complexit de lalgorithme avec boucles imbriques et avec tri-fusion. Dans les deux cas on tiendra compte des mouvements entre mmoire centrale et disque et on valuera le nombre dentres-sorties. Algorithme avec boucles imbriques; Algorithme avec tri-fusion;
9.6.3 Plans dexcution

Exercice 30 Soit la base STATION DE SKI de schma: Station (noms,gare) Hotel (noms,nomh,categorie,adresse,tel,nb_chambres) Activite (type_activite,noms) Pour chacune des requtes suivantes, on demande: 1. deux arbres syntaxiques quivalents pour la requte 2. le plan dexcution obtenu par la restructuration algbrique 3. le plan dexcution obtenu par une optimisation globale. adresse, numro de tlphone et nombre de chambres des htels de catgorie 3 dans la station de nom (noms persey.
SELECT adresse, tel, nb_chambres FROM hotel WHERE noms=pesey AND categorie=3;
nom de station (noms) et la gare de la station pour le sstations ayant pour activit le tennis.
SELECT noms, gare FROM station, activite WHERE type_activite = tennis AND station.noms=activite.noms
9.6. EXERCICES
190
9.6.4 Plans dexcution ORACLE

Exercice 31 Soit le schma suivant :
CREATE TABLE FILM ( TITRE VARCHAR2(32), REALISATEUR VARCHAR2(32), ACTEUR VARCHAR2(32) ); CREATE TABLE VU ( SPECTATEUR TITRE ); VARCHAR2(32), VARCHAR2(32)
Soit la requte SQL : SELECT ACTEUR, REALISATEUR FROM FILM, VU WHERE FILM.TITRE=VU.TITRE Dans chacun des cas suivants, donner lalgorithme de jointure de ORACLE (par EXPLAIN, un arbre dexcution comment, une explication textuelle ou tout autre moyen de votre choix): 1. Il nexiste pas dindex sur TITRE ni dans FILM ni dans VU, 2. Il existe un index sur TITRE dans FILM seulement. 3. Il existe un index sur TITRE dans les deux relations. Exercice 32 SELECT e.enom, d.dnom FROM emp e, dept d WHERE e.dno = d.dno AND e.sal = 10000 sur la relation EMP de schma (EMPNO, SAL, MGR, DNO). Cette requte afche le nom des employs dont le salaire ) est gal 10000, et celui de leur dpartement. Indiquez le plan dexcution dans chacune des hypothses ( suivantes.
2. Index sur 3. Index sur
seulement.
4. Voici une autre requte, lgrement diffrente. Plan dexcution sil ny a pas dindex. SELECT e.enom FROM emp e, dept d WHERE e.dno = d.dno AND d.ville = Paris
5. Que pensez-vous de la requte suivante par rapport la prcdente ? SELECT e.enom FROM emp e WHERE e.dno IN (SELECT d.dno FROM Dept d WHERE d.Ville = Paris)
et sur
0 )
1. Index sur
et sur
0 )
I )


Voici le plan dexcution donn par ORACLE : 0 SELECT STATEMENT 1 MERGE JOIN 2 SORT JOIN 3 TABLE ACCESS FULL EMP 4 SORT JOIN 5 VIEW 6 SORT UNIQUE 7 TABLE ACCESS FULL DEPT
191
Quen dites vous ? Sur le mme schma, voici maintenant la requte suivante. SELECT * FROM EMP X WHERE X.SAL IN (SELECT SAL FROM EMP WHERE EMP.EMPNO=X.MGR) ) est gal celui de leur patron ( ). On donne le plan Cette requte cherche les employs dont le salaire ( dexcution avec Oracle (outil EXPLAIN) pour cette requte dans deux cas: (i) pas dindex, (ii) un index sur le salaire et un index sur le numro demploy. Expliquez dans les deux cas ce plan dexcution (ventuellement en vous aidant dune reprsentation arborescente de ce plan dexcution). 1. Pas dindex. Plan dexcution -----------------------------------------------------------------------0 FILTER 1 TABLE ACCESS FULL EMP 2 TABLE ACCESS FULL EMP
2. Index empno et index sal. Plan dexcution -----------------------------------------------------------------------0 FILTER 1 TABLE ACCESS FULL EMP 2 AND-EQUAL 3 INDEX RANGE SCAN I-EMPNO 4 INDEX RANGE SCAN I-SAL
3. Dans le cas o il y a les deux index (salaire et numro demploy) et o la requte est : SELECT * FROM EMP X WHERE X.SAL = (SELECT SAL FROM EMP WHERE EMP.EMPNO=X.MGR)
9.6. EXERCICES
on a le plan dexcution suivant:
192
Plan dexcution -----------------------------------------------------------------------0 FILTER 1 TABLE ACCESS FULL EMP 2 TABLE ACCESS ROWID EMP 3 INDEX RANGE SCAN I-EMPNO Expliquez-le. Exercice 33 Soit le schma suivant :
CREATE TABLE Artiste (Nom VARCHAR2 (20) NOT NULL, Prenom VARCHAR2 (15), Annee_naissance NUMBER(4) , PRIMARY KEY (Nom));
CREATE TABLE film
(ID_film NUMBER(10) NOT NULL, Titre VARCHAR2(30), Annee NUMBER(4), Nom_Realisateur VARCHAR2(20), PRIMARY KEY (ID_film), FOREIGN KEY (Nom_realisateur) REFERENCES Artiste); (Nom_cinema VARCHAR2(10) NOT NULL, No_salle NUMBER(2) NOT NULL, No_seance NUMBER(2) NOT NULL, Heure_debut NUMBER (4,2), Heure_fin NUMBER (4,2), ID_film NUMBER(10) NOT NULL, PRIMARY KEY (Nom_cinema, No_salle, No_seance), FOREIGN KEY (Nom_cinema, No_salle) REFERENCES salle ON DELETE CASCADE);
CREATE TABLE seance
Questions: 1. Donner lordre SQL pour la requte: Quels sont les lms dHitchcock visibles aprs 20h00? 2. Donner lexpression algbrique correspondante et proposez un arbre de requte qui vous parat optimal. 3. Sous ORACLE, loutil EXPLAIN donne le plan dexcution suivant: 0 SELECT STATEMENT 1 MERGE JOIN 2 SORT JOIN 3 NESTED LOOPS 4 TABLE ACCESS FULL ARTISTE 5 TABLE ACCESS BY ROWID FILM 6 INDEX RANGE SCAN IDX-ARTISTE-ID 7 SORT JOIN 8 TABLE ACCESS FULL SEANCE Commentez le plan donn par EXPLAIN. Pourrait-on amliorer les performances de cette requte?

Exercice 34 Soit le schma suivant : CREATE TABLE Artiste ( ID-artiste NUMBER(4), Nom VARCHAR2(32), Adresse VARCHAR2(32) ); CREATE TABLE Film ( ID-film Titre Anne ID-ralisateur );
193
NUMBER(4), VARCHAR2(32), NUMBER(4), NUMBER(4)
CREATE TABLE Joue ( ID-artiste ID-film ); Questions:
NUMBER(4), NUMBER(4)
1. Donner lordre SQL pour la requte: Afcher le nom des acteurs et le titre des lms o ils ont jou. 2. Donner lexpression algbrique correspondante. 3. Quel est votre avis le plan dexcution dans sil nexiste que deux index, un sur FILM(ID-ralisateur), et un sur ARTISTE(ID-artiste)?

9.6.5 Utilisation de EXPLAIN et de TKPROF

Le site Films propose les chiers suivants pour crer et alimenter une base (sur des lms bien sr...). 1. Le chier Schema.sql contient les commandes de cration du schma sous ORACLE. 2. Le chier CrFilms.pc est un programme PRO*C pour alimenter cette base. Lentte du chier contient les instructions pour le compiler et lexcuter. Avec ces deux chiers vous pouvez crer une base de taille quelconque, et tester lvaluation des requtes avec EXPLAIN et TKPROF. Utilisation de EXPLAIN Voici le mode dutilisation de EXPLAIN. Les plans dexcution sont stocks dans une table PLAN_TABLE dont le script de cration se trouve, en principe, dans $ORACLE_HOME/rdbms/admin/utlxplan.sql. Vous pouvez galement la rcuprer sur le site Ensuite on stocke le plan dexcution dune requte dans cette table avec la commande EXPLAINJ PLAN. Voici un exemple : EXPLAIN PLAN SET statement_id = FOR SELECT a.nom FROM film f, WHERE f.idMES AND f.titre
plan0 artiste a = s.idArtiste = Vertigo;
5. Idem, avec un index sur
, et un sur
4. Idem, avec un index sur
, et un sur

9.6. EXERCICES
194
La clause statement_id = plan0 attribue un identiant au plan dexcution de cette requte dans la table PLAN_TABLE. Bien entendu vous devez donner chaque requte stocke un identiant spcique. Pour connatre le plan dexcution, on interroge la table PLAN_TABLE. Linformation est un peu difcile interprter : le plus simple est de faire tourner le chier Explain.sql ( rcuprer sur le site) dont voici le code : undef query; SELECT LPAD( ,2*(LEVEL-1))||operation|| ||options || ||object_name "Plan dexcution" FROM plan_table START WITH id = 0 AND statement_id = &&query CONNECT BY PRIOR id = parent_id AND statement_id =&&query; Quand on excute ce chier, il demande (2 fois) le nom du plan dexcution afcher. Dans le cas de lexemple ci-dessus, on rpondrait deux fois plan0. On obtient lafchage suivant qui prsente de manire relativement claire le plan dexcution. Plan dexcution ----------------------------------------------------------0 SELECT STATEMENT 1 NESTED LOOPS 2 TABLE ACCESS FULL Film 3 TABLE ACCESS BY ROWID Artiste 4 INDEX UNIQUE SCAN SYS_C004709 Ici, le plan dexcution est le suivant : on parcourt en squence la table Film (ligne 2) ; pour chaque sance, on accde la table Artiste par lindex 13 (ligne 4), puis pour chaque ROWID provenant de lindex, on accde la table elle-mme (ligne 3). Le tout est effectu dans une boucle imbrique (ligne 1). Utilisation de TKPROF TKPROF est complmentaire de EXPLAIN : il donne les diffrents cots constats pour lexcution dune requte. Le principe dutilisation est le suivant : on passe en mode TRACE avec la commande suivante (sous SQLPLUS) ALTER SESSION SET SQL_TRACE = TRUE; partir de ce moment-l, toutes les requtes excutes sous SQLPLUS entraneront linsertion dans un chier des informations sur le cot dexcution. Quand on a excut toutes les requtes analyser, on stoppe le mode TRACE avec : ALTER SESSION SET SQL_TRACE = FALSE; Il reste rcuprer le chier de trace et lanalyser avec lutilitaire TKPROF. Pour localiser le chier, on peut utiliser la requte suivante : SELECT value FROM v$parameter WHERE name = user_dump_dest; On obtient le rpertoire o se trouve le chier, dont le nom suit le format oraSID_ora_noProcessus. Il reste lui appliquer le programme tkprof : tkprof nomFichier Vous devez bien entendu avoir les droits de lecture sur le chier, ce qui peut poser problme si vous ntes pas ladministrateur. Il reste une troisime solution, peut-tre la plus simple, avec loption AUTOTRACE de SQLPLUS.
13. Cet index a t automatiquement cr en association avec la commande PRIMARY KEY.

Cumuler EXPLAIN et TKPROF avec AUTOTRACE
195
En passant en mode AUTOTRACE sous SQLPLUS, on obtient les principales informations fournies par EXPLAIN et TKPROF sans avoir besoin deffectuer les manipulations dtailles prcdemment. Avant de pouvoir utiliser cette option, il faut avoir effectuer la petite installation suivante : 1. crer le rle PLUSTRACE avec le script $ORACLE_HOME/sqlplus/admin/plustrce.sql (il faut excuter ce script sous le compte SYS) ; 2. donner ce rle avec la commande GRANT tout utilisateur souhaitant faire appel AUTOTRACE. Si, maintenant, on est un de ces utilisateurs, on se place en mode AUTOTRACE avec la commande suivante : ALTER SESSION SET AUTOTRACE {OFF | ON | TRACEONLY} [EXPLAIN] [STATISTICS] Le mode TRACEONLY permet de ne pas afcher le rsultat de la requte, ce qui est le but recherch en gnral.
9.6.6 Exercices dapplication

Exercice 35 Effectuer des requtes en mode TRACE, an dtudier les plans dexcution. Pour linstant, se mettre en mode rgles . 1. Des slections sur des champs indexs ou non indexs (faire une slection sur le genre par exemple) 2. Des jointures (penser inverser lordre des tables dans le FROM) 3. Des requtes avec NOT IN ou NOT EXISTS Exercice 36 Maintenant, analyser les tables, les index et les distributions avec ANALYSE, et regarder les modications des plans dexcution en optimisation par les cots. En particulier Chercher des lms par le genre en mode rgles Chercher des lms par le genre en mode cots Le genre tant peu slectif, loptimiseur ne devrait pas utiliser lindex dans le second cas. Exercice 37 Reprendre les requtes du polycopi cherchant le lm paru en 1958 avec James Stewart. Analyser les diffrentes versions (sans imbrication, avec imbrication mais sans corrlation (IN), avec imbrication et corrlation (EXISTS), etc). Comparer les plans dexcution obtenus dans chaque cas. Exercice 38 Supprimer quelques index, et regarder le changement dans les plans dexcutions des requtes prcdentes. NB : vous pouvez obtenir la liste des index existant sur vos tables avec la commande : SELECT table_name, index_name FROM user_indexes;
Exercice 39 Maintenant appliquez des fonctions de groupe, des GROUP BY et des HAVING, regardez les plans dexcution et interprtez-les. Exercice 40 Essayer dappliquer des fonctions dans les conditions de jointure. Que constate-t-on au niveau du plan dexcution ? Exercice 41 Essayer dappliquer loprateur LIKE dans des slections sur des attributs indexs. Que constate-t-on ?
9.6. EXERCICES
196
CHAPITRE 10. INTRODUCTION LA CONCURRENCE DACCS
197
Chapitre 10
Introduction la concurrence daccs

Sommaire
10.1 Prliminaires . . . . . . . . . . . . . . . . . . 10.1.1 Excutions concurrentes : srialisabilit . 10.1.2 Transaction . . . . . . . . . . . . . . . 10.1.3 Excutions concurrentes : recouvrabilit 10.2 Contrle de concurrence . . . . . . . . . . . . 10.2.1 Verrouillage deux phases . . . . . . . 10.2.2 Contrle par estampillage . . . . . . . . 10.3 Gestion des transactions en SQL . . . . . . . 10.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 198 199 200 201 202 204 204 205
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 deffectuer des mises jour. Plus gnralement, on doit savoir contrler les accs concurrents de plusieurs programmes complexes effectuant de nombreuses lectures/critures. Un SGBD doit garantir que lexcution dun programme effectuant des mises jour dans un contexte multiutisateur seffectue 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.
10.1 Prliminaires
Commenons ds maintenant par un exemple illustrant le problme. Supposons que lapplication Ofciel des spectacles propose une rservation des places pour une sance. Voici le programme de rservation (simpli) :
Programme RESERVATION Entre : Une sance Le nombre de places souhait Le client debut Lire la sance si (nombre de places libres ) Lire le compte du client Dbiter le compte du client Soustraire au nombre de places vides Ecrire la sance
10.1. PRLIMINAIRES
Ecrire le compte du client nsi n
198
Il est important de noter ds maintenant que, 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. 2. Les critures que lon notera w. De plus, la nature des informations manipules est indiffrente : les rgles pour le contrle de la concurrence 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 se reprsente donc simplement par la squence
10.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 , du programme . et .
1. Il reste 50 places libres pour la sance .
Voici le droulement imbriqu des deux excutions et , 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.
la n de lexcution, il y a un problme : il reste 45 places vides sur les 50 initiales alors que 7 places ont effectivement t rserves et payes. Le problme est clairement issu dune mauvaise imbrication des oprations de et : lit et modie une information que 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 21 Excution en srie de
et
6.
crit le nouveau compte de
5.
crit avec nb places =
4.
crit le nouveau compte de
. .
3.
2.
lit et
!
1.
lit et
. Nb places vides : 50. . Nb places vides : 50. .

3.
veut rserver 2 places pour la sance .
2.
veut rserver 5 places pour la sance .
Donc on effectue dabord les lectures pour , puis les lectures pour enn les critures pour ordre. Imaginons maintenant que lon se trouve dans la situation suivante :

et
Exemple 20 Voici un exemple de deux excutions concurrentes du programme programme veut rserver des places dans la mme sance, pour deux clients distincts
et
! ! )
)
r[s] r[c] w[c] w[s]
. Chaque
dans cet
199
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.
Suivons pas pas lexcution :
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.
10.1.2 Transaction
Le fait de garantir une imbrication correcte des excutions de programmes concurrents serait sufsant dans lhypothse o tous les programmes terminent normalement en validant les mises jour effectues. Malheureusement ce nest pas le cas : il arrive que lon doive annuler les oprations dentres sorties effectues 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 :
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 effectues. Dans le cas ci-dessus, cest simple : on annule . Mais la question plus gnrale, cest : jusquo doit-on annuler quand un programme a dj effectu 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 offrir 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 effectues.

7.
crit le nouveau compte du client
6.
crit le nouveau compte du client
5.
4.
3.
lit . Nb places vides : 45. lit . . . .
2.
1.
lit et
. Nb places vides : 50. .
! !
Exemple 22 Excution imbrique de
et
On est assur dans ce cas quil ny a pas de problme : crera donc plus dinterfrence.
lit une donne crite par
qui a ni de sexcuter et ne
10.1. PRLIMINAIRES
200
Ces instructions permettent de dnir la notion de transaction : une transaction est lensemble des instructions sparant un commit ou un rollback du commit ou du rollback suivant. On adopte alors les rgles suivantes : 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.
Du point de vue de lexcution concurrente, cela soulve de nouveaux problmes qui sont illustrs ci-dessous.
10.1.3 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 lli la recouvrabilit des transactions et illustr par lexemple suivant : Exemple 24 (Excutions recouvrables).
Consquence sur lexemple : le nombre de places disponibles a t diminu par et repris par , avant que nannule ses rservations. Le nombre de siges rserv sera plus grand que le nombre effectif de clients ayant valid leur rservation. Le problme ici vient du fait que la transaction est annule aprs que la transaction a lu une information mise jour par , manipul cette information et effectu 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 annule la MAJ qui a fait lobjet dune lecture sale . Pour annuler proprement , il faudrait annuler en plus les mises jour de , 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 ayant effectus par une transaction et les commit dune autre. On pourrait penser interdire une transaction effectu des dirty read dune transaction de valider avant . On accepterait alors la situation suivante : Exemple 25 (Annulations en cascade).
Ici, le rollback de intervient sans que nait valid. Il faut alors imprativement que le systme effectue galement un rollback de 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 difcilement envisageable 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.

! !
3.
2.

1.

Exemple 23 Les deux premires transactions ne sont pas correctes, la troisime lest ( signie

).

201
Cel laisse encore une dernire possibilit danomalie qui fait intervenir la ncessit dannuler les critures effectues par une transaction. Imaginons quune transaction ait modif la valeur dune donne , puis quun rollback intervienne. Dans ce cas il est ncessaire de restaurer la valeur quavait 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. Exemple 26 (Excution non stricte)

Ici il ny a pas de dirty read, mais une criture sale (dirty write). En effet, a valid aprs que ait crit dans . Donc la validation de enregistre la mise jour de alors que celle-ci sapprte annuler ses mises jour par la suite. Au moment o va annuler, le gestionnaire de transaction doit remettre la valeur du tuple connue au dbut de la transaction : ce qui revient annuler la mise jour de . Autre exemple.
Que se passe-t-il au moment de lannulation de ? On devrait restaurer limage avant connue de , mais cela revient annuler la mise jour de . 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 offert 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 pour : Atomicit. Une transaction est lunit de validation. Cohrence. Une transaction est un ensemble de mises jour entre deux tats cohrents de la base. Isolation. Les lectures ou critures effectues par une transaction doivent tre invisibles des autres transactions. Durabilit : une transaction valide ne peut plus tre annule. Il reste maintenant tudier les techniques mises en oeuvre pour assurer ces bonnes proprits.
10.2 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 : au 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 transaction sachve. Il sagit dune approche dite optimiste : on considre que les conits sont rares et que lon peut accepter de rexcuter les quelques transactions qui posent problme.
" ! !
Exemple 27 Cette fois cest
qui annule et
qui valide :

10.2. CONTRLE DE CONCURRENCE
202
La premire approche est la plus frquente. Le mcanisme adopt est celui du verrouillage. Lide 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 termine par commit ou rollback ( libration du verrou ). Reprenons lexemple 20, et supposons que tout accs en lecture ou en criture pose un verrou bloquant les autres transactions. Clairement les transactions et sexcuteront en srie et les anomalies disparatront. Le bloquage systmatique des transactions est cependant une contrainte trop forte, comme le montre lexemple 22. Lexcution est correcte, mais le verrouillage total bloquerait pourtant sans ncessit la transaction . On doit 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 est typiquement utilis pour permettre plusieurs transactions concurrentes de lire la mme ressource. 2. Le verrou exclusif 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 effectues par les transactions/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.
10.2.1 Verrouillage deux phases

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 indique par exemple que la transaction a pos un verrou en lecture sur la nots wl (comme write lock). Donc resource . On notera de mme et 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.

Le respect du protocole est assur par un module dit scheduler qui reoit les oprations mises par les transactions et les traite selon lalgorithme suivant :
2. Un verrou pour nest jamais relch avant la conrmation de lexcution par un autre module, le gestionnaire de donnes GD.
Le terme verrouillage deux phases sexplique par le processus dtaill ci-dessus : il y a dabord accumulation de verrou pour une transaction , puis libration des verrous. Thorme 1 Toute excution obtenue par un verrouillage deux phases est srialisable. De plus on obtient une excution stricte en ne relachant les verrous quau moment du commit ou du rollback. Les transactions obtenues satisfont les proprits ACID. Il est assez facile de voir que ce protocole garantit que, en prsence de deux transactions en conit et , 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). A ce moment l il ny a plus de conit possible puisque ne demandera plus de verrou (rgle 3).
3. Ds que
relche un verrou, elle ne peut plus en obtenir dautre.
sinon,
obtient le verrou
et lopration
est excute.
si
est en conit avec
est retarde et la transaction
1. Le scheduler reoit

et consulte le verrou dj pos sur ,
, sil existe. est mise en attente.
Dnition 10 Deux verrous
et
sont en conit si
et
ou
est un verrou en criture.

203
La rgle 2 a principalement pour but de sassurer de la synchronisation entre la demande dexcution dune opration, et lexcution effective de cette opration. Rien ne garantit en effet que les excutions vont se faire dans lordre dans lequel elles ont t demandes. Pour illustrer lintrt de ces rgles, on peut prendre lexemple suivant : Exemple 28 (Non-respect de la rgle de relchement des verrous). Soit les deux transactions suivantes :
et lordre dexcution suivant : r [x] w [x] w [y] c w [y] c . Supposons que lexcution avec pose et relchement de verrous soit la suivante :
On a viol la rgle 3 : a relach le verrou sur puis en a repris un sur . Un fentre sest ouverte qui a permis a de poser des verrous sur et . Consquence : lexcution nest plus srialisable car a crit sur pour , et a crit sur pour (r [x] w [x] et w [y] w [y]). Reprenons le mme exemple, avec un verrouillage deux phases : Exemple 29 (excution correcte)
Le verrouillage deux phases (avec des variantes) est utilis dans tous les SGBD. Il permet en effet une certaine imbrication des oprations. Notons cependant quil est un peu trop strict dans certains cas : voici lexemple dune excution srialisable Exemple 30 Une excution srialisable impossible par verrouillage
T relche rl[x] pour w [x], mais a besoin ensuite de rl[y] pour r [y].
Le principal dfaut du verrouillage deux phases est dautoriser des interblocages : deux transactions concurrentes demandent chacune un verrou sur une ressource dtenue par lautre. Voici lexemple type : Exemple 31 Les deux transactions sont les suivantes :
Cette situation ne peut pas tre vite et doit donc tre gre par le SGBD : en gnral ce dernier maintient 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 annule et r-xcute. Autre solution : tester le temps dattente et annuler les transactions qui dpassent le temps limite. Notons que le problme vient dun accs aux mmes ressources, mais dans un ordre diffrent : il est donc bon, au moment o lon crit des programmes, dessayer de normaliser lordre daccs aux donnes. titre dexercice, on peut reprendre le programme de rservation donn initialement, mais dans une version lgrement diffrente :
et
sont en attente lune de lautre : il y a interblocage (deadlock en anglais).

Considrons maintenant que

et
sexcutent en concurrence dans le cadre dun verrouillage deux phases :
r [x] w [x] c w [y] c r [y] w [z] c
rl [x] r [x] ru [x] wl [x] w [x] wl [y] w [y] wu [x] wu [y] c wl [y] w [y] wu [y] c

2. T : w [x]
w [y]
1. T : r [x]
w [y]

10.3. GESTION DES TRANSACTIONS EN SQL

Programme RESERVATION2 Entre : Une sance Le nombre de places souhait Le client debut Lire la sance si (nombre de places libres ) Lire le compte du spectateur Dbiter le compte du client Soustraire au nombre de places vides Ecrire le compte du client Ecrire la sance nsi n
204
Exercice : donner une excution concurrente de RESERVATION et de RESERVATION2 qui aboutisse un interblocage. Ds que 2 transactions lisent la mme donne avec pour objectif deffectuer une mise jour ultrieurement, il y a potentiellement interblocage. Do lintrt de pouvoir demander ds la lecture un verrouillage exclusif (criture). Cest la commande SELECT ... FOR UPDATE que lon trouve dans certains SGBD. Autre solution pour uidier les transactions : ne pas poser de verrou en lecture (mode READ COMMITTED en SQL2). Cette solution affecte lisolation entre deux transactions. .
Sans verrou en lecture : on bloque mois
, mais la transaction nest plus srialisable.
10.2.2 Contrle par estampillage

Cest une mthode beaucoup plus simple qui consiste xer, a priori, lordre de srialisabilit des transactions soumises au scheduler. Pour cela, on affecte chaque transaction une estampille. Chaque valeur destampille est unique et les valeurs sont croissantes : on garantit ainsi un ordre total entre les transactions. Quand un conit survient entre et , on vrie simplement que lordre du conit est compatible avec lordre des transactions (i.e. ). Sinon on rejette la transaction qui veut effectuer lopration conictuelle. Sur lexemple suivant :
en admettant que lestampille est le numro de la transaction, on rejette la transation au moment de . Mthode peu utilise car elle entrane des abandons inutiles de transactions, et le risque de privation : une transaction est toujours rejette.
10.3 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 srialisabilit 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. 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;

Exemple 32 Toujours avec le programme mme sance, pour deux clients distincts et

! ! )
. Chaque programme veut rserver des places dans la
205
Il devient alors interdit deffectuer 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 diffrents : entre temps une autre transaction a pu mettre jour les donnes. 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 offre 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 diffrents. 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. 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
10.4 Exercices
Exercice 42 (Graphe de srialisabilit et quivalence des excutions) Construisez les graphes de srialisabilit pour les excutions (histoires) suivantes. Indiquez les excutions srialisables et vriez sil y a des excutions quivalentes.

3.
"

2.
!

1.

10.4. EXERCICES
206
Conclusion: , et srialisables, Les histoires et ne sont pas quivalentes. Pour avoir quivalence, deux conditions sont ncessaires: (i) avoir les mmes transactions et les mmes operations, et (ii) avoir le meme ordre des operations conictuelles. Ici la seconde condition est remplie, mais pas la premiere! En effet, si on extrait la transaction de ces histoires, on a , tandis que pour , . Et cest pareil pour . on remarque que pour Exercice 43 (Recouvrabilit) Parmi les excutions (histoires) suivantes, lesquelles sont recouvrables, lesquelles vitent les annulations en cascade et lesquelles sont strictes? Indiquez sil y a des excutions srialisables.
Exercice 44 On considre maintenant le problme (dlicat) de la rservation des places pour un match. Pour cela on ajoute les tables Match (Match, NomStade, PlacesPrises) et Client (NoClient, Solde). Les oprateurs disposent du petit programme suivant pour rserver des places 1 : Places (Client C, Match M, Nb-Places N) begin Lire le match M // Donne le nbre de places prises Lire le stade S // Donne le nbre total de places if ( (S.places - M.PlacesPrises) > N) // Il reste assez de places begin Lire le client C M.PlacesPrises += N; C.solde -= N * 300; Ecrire le match M Ecrire le client C end commit end Les organisateurs saperoivent rapidement quil ny a pas assez de place dans les stades en entreprennent des travaux dagrandissement. On a le deuxime programme : Augmenter (Stade S, Places P) begin Lire S S.Places += P Ecrire S commit end 1. On lance simultanment deux excutions du programme Augmenter (SF, 1000) pour augmenter la capacit du Stade de France. (a) Donnez un exemple dune histoire (imbrication des lectures/critures) non srialisable. (b) Donnez un exemple dune histoire non recouvrable (en plaant des ordres commit).
1. On suppose que chaque place vaut 300F.

3.

2.

1.
!
!
D

2. On a maintenant une excution concurrente de Places (C, M, 1500) et de Augmenter (SF, 1000), match qui se droule au Stade de France. Voici le dbut de lexcution 2 :
207 tant un
(a) Donner lhistoires complte en supposant quil y a 2000 places libres au dbut de lexcution. Donnez galement le nombre de places libres dans le stade la n de lexcution. (b) Lhistoire obtenue est-elle srialisable ? (c) Appliquer un verrouillage deux phases (les verrous sont relchs au moment du commit. (d) Conclusion ? Y-avait-il un risque danomalie ? Que dire du comportememt du verrouillage deux phases ?
(a) Montrer que H nest pas srialisable. (b) On suppose quil y a 1000 places prises dans au dbut de lexcution. Combien y en a-t-il la n de lexcution de H ? Combien de places a-t-il rellement payes ? A qui prote lerreur ? (c) Appliquer un verrouillage deux phases sur H et donner lexcution H rsultante. Les verrous sont relchs aprs le commit.
Exercice 45 Le programme suivant sexcute dans un systme de gestion de commandes pour les produits dune entreprise. Il permet de commander une quantit donne dun produit qui se trouve en stock. Les paramtres du programme reprsentent respectivement la rfrence de la commande ( ), la rfrence du produit ( ) et la quantit commande ( ). Commander ( , , ) Start Lecture prix produit si >stock de alors Abort sinon Mise jour stock de Enregistrement dans du total de facturation Commit n si N.B. et ne sont pas des enregistrements, mais des identiants pour le produit et la commande. Ainsi, le prix et la quantit de produit en stock sont gards dans des enregistrements diffrents. 1. Lesquelles des transactions suivantes peuvent tre obtenues par lexecution du programme ci-dessus? Justiez votre rponse.
T: r[x] r[y] a T: r[x] a T: r[x] w[y] w[z] c T: r[x] r[y] w[y] w[z] c

2. lindice
dsigne
" !
H=
3. Soit lhistoire suivante, reprsentant deux excutions concurrentes du programme Places : 100) et = Places (C, M, 200) pour le mme match et le mme client.

"!
= Places (C, M,
H=
10.4. EXERCICES
208
2. Dans le systme sexcutent en mme temps trois transactions: deux commandes dun mme produit et le changement du prix de ce mme produit. Montrez que lhistoire ci-dessous est une excution concurrente de ces trois transactions et expliquez la signication des enregistrements qui y interviennent.

H : r [x] r [y] w [x] w [y] c r [x] r [y] w [z] c w [y] w [u] c

3. Vriez si H est srialisable en identiant les conits et en construisant le graphe de srialisation. 4. Lexcution H est-elle stricte? Justiez votre rponse. 5. Quelle est lexcution obtenue par verrouillage deux phases partir de H? Quel prix sera appliqu pour la seconde commande, le mme que pour la premire ou le prix modi? On considre que le relchement des verrous dune transaction se fait au Commit et qu ce moment on excute en priorit les oprations bloques en attente de verrou, dans lordre de leur blocage. Exercice 46 (Verrouillage 2 phases) Un scheduler avec verrouillage 2 phases reoit la squence doprations ci-dessous. Indiquez lordre dexcution tabli par le scheduler, en considrant quune opration bloque en attente dun verrou est excute en priorit ds que le verrou devient disponible. On suppose que les verrous dune transaction sont relchs au moment du Commit. Exercice 47 (Concurrence: Gestion Bancaire) Les trois programmes suivants peuvent sexcuter dans un systme de gestion bancaire. Dbit diminue le solde dun compte c avec un montant donn m. Pour simplier, tout dbit est permis (on accepte des dcouverts). Crdit augmente le solde dun compte c avec un montant donn m. Transfert transfre un montant m partir dun compte source s vers un compte destination d. Lexcution de chaque programme dmarre par un Start et se termine par un Commit (non montrs ci-dessous).
Dbit (c:Compte; m:Montant) begin t := Read(c); Write(c,t-m); end | | | | | | Crdit (c:Compte; m:Montant) begin t = Read(c); Write(c,t+m); end | | | | | | Transfert (s,d:Compte; m:Montant) begin Dbit(s,m); Crdit(d,m); end

Le systme excute en mme temps les trois oprations suivantes: (1) un transfert de montant 100 du compte A vers le compte B (2) un crdit de 200 pour le compte A (3) un dbit de 50 pour le compte B
2. Mettre en vidence les conits dans H et construire le graphe de srialisation de cette histoire. H est-elle srialisable? H est-elle recouvrable? 3. Quelle est lexcution H obtenue partir de H par verrouillage deux phases? On suppose que les verrous dune transaction sont relchs aprs le Commit de celle-ci. Une opration bloque en attente dun verrou bloque le reste de sa transaction. Au moment du relchement des verrous, les oprations en attente sont excutes en priorit. Si au dbut le compte A avait un solde de 100 et B de 50, quel sera le solde des deux comptes aprs la reprise si une panne intervient aprs lexcution de ?

1. crire les transactions
et
qui correspondent ces oprations. Montrer que lhistoire H: est une excution concurrente de , et .
!
ANNEXE A. TRAVAUX PRATIQUES
209
Annexe A
Travaux pratiques
Sommaire
A.1 Interrogation avec SQL . . . . . . . . . . . . . . . . . A.1.1 Slections simples . . . . . . . . . . . . . . . . . A.1.2 Jointures . . . . . . . . . . . . . . . . . . . . . . A.1.3 Requtes imbriques . . . . . . . . . . . . . . . A.1.4 Ngation . . . . . . . . . . . . . . . . . . . . . . A.1.5 Fonctions de groupe . . . . . . . . . . . . . . . . A.2 Cration dun schma relationnel . . . . . . . . . . . . A.2.1 Cration des tables . . . . . . . . . . . . . . . . A.2.2 Insertion de donnes . . . . . . . . . . . . . . . . A.2.3 Vues . . . . . . . . . . . . . . . . . . . . . . . . A.2.4 Triggers . . . . . . . . . . . . . . . . . . . . . . A.3 Concurrence daccs . . . . . . . . . . . . . . . . . . . A.4 Progammation dune application avec base de donnes A.5 Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 211 212 212 212 213 213 213 213 214 215 215 216 216
Tous les travaux pratiques dcrits dans ce qui suit peuvent seffectuer en ligne grce linterface web disponible lURL : http://www.lri.fr/ rigaux/BD La mise en uvre est simplissime puisquil ny a rien installer : vous avez juste besoin dun ordinateur accdant au Web. Les instructions pour utiliser le systme sont disponibles en ligne. Sachez simplement quil est possible de pratiquer SQL sans autre formalit. En revanche, pour crer une base et disposer dun environnement de travail permettant des crations, des modications et lcriture dune application, il faudra fournir quelques informations permettant de crer un compte. Vous accderez ensuite au systme avec un login et un mot de passe. Il est galement possible deffectuer ces TP dans dautres conditions : le seul pr-requis est en fait de disposer dun SGBD relationnel sufsamment avanc, et dun terminal daccs permettant dentrer les commandes en ligne. Voyez dans un tel cas avec votre enseignant quelles sont les oprations dinstallation effectuer. Les exercices proposs comprennent peu prs toutes les oprations dont la matrise est ncessaire la pratique correcte et efcace un SGBD relationnel, savoir : interrogation avec le langage SQL (section A.1, page A.1) ; insertions et mise jour diverses et varis ; conception et cration dun schma avec tables, vues, contraintes, index, triggers, etc. ; mcanisme de concurrence daccs ;
A.1. INTERROGATION AVEC SQL

accs la base avec un langage de programmation interne (PL/SQL) ou externe (Java, PHP).
210
Un projet rcapitulant lensemble de ces connaissances vous est galement propos. Il est clair que la prsence dun enseignant pour vous guider est prfrable. Si ce nest pas le cas, vous ne risquez rien tenter votre chance pour exprimenter et voir si vous vous en sortez ou non. Dans tous les cas, bonne chance !
A.1
Interrogation avec SQL
Au dpart, vous avez accs au schma et la base de donnes Films , vue et revue en cours, qui est partage (en lecture) par tout le monde. Voici le script de cration de ce schma (disponible sur le site). Ces commandes doivent maintenant vous tre familires (sinon relisez les chapitres correspondant). Exemple 33 SchemaFilms.sql : Le script de cration du schma
/* Commandes de cration de la base Films, test avec MySQL et PostgreSQL. Pour Oracle, il suffit de remplacer le type TEXT par le type LONG dans la table Film. Philippe Rigaux, 2004 */ /* Destruction eventuelle des tables existantes */ DROP DROP DROP DROP DROP DROP DROP TABLE Notation; TABLE Role; TABLE Film; TABLE Artiste; TABLE Internaute; TABLE Pays; TABLE Genre; */
/* Creation des tables
CREATE TABLE Internaute (email VARCHAR (40) NOT NULL, nom VARCHAR (30) NOT NULL , prenom VARCHAR (30) NOT NULL, region VARCHAR (30), CONSTRAINT PKInternaute PRIMARY KEY (email)); CREATE TABLE Pays (code VARCHAR(4) NOT NULL, nom VARCHAR (30) DEFAULT Inconnu NOT NULL, langue VARCHAR (30) NOT NULL, CONSTRAINT PKPays PRIMARY KEY (code)); CREATE TABLE Artiste (idArtiste INTEGER NOT NULL, nom VARCHAR (30) NOT NULL, prenom VARCHAR (30) NOT NULL, anneeNaiss INTEGER, CONSTRAINT PKArtiste PRIMARY KEY (idArtiste), CONSTRAINT UniqueNomArtiste UNIQUE (nom, prenom));
CREATE TABLE Film
(idFilm INTEGER NOT NULL, titre VARCHAR (50) NOT NULL, annee INTEGER NOT NULL, idMES INTEGER, genre VARCHAR (20) NOT NULL, /* Remplacer TEXT par LONG pour ORACLE */ resume TEXT,

codePays VARCHAR (4), CONSTRAINT PKFilm PRIMARY KEY (idFilm), FOREIGN KEY (idMES) REFERENCES Artiste, FOREIGN KEY (codePays) REFERENCES Pays); CREATE TABLE Notation (idFilm INTEGER NOT NULL, email VARCHAR (40) NOT NULL, note INTEGER NOT NULL, CONSTRAINT PKNotation PRIMARY KEY (idFilm, email)); CREATE TABLE Role (idFilm INTEGER NOT NULL, idActeur INTEGER NOT NULL, nomRole VARCHAR(30), CONSTRAINT PKRole PRIMARY KEY (idActeur,idFilm), FOREIGN KEY (idFilm) REFERENCES Film, FOREIGN KEY (idActeur) REFERENCES Artiste); CREATE TABLE Genre (code VARCHAR (20) NOT NULL, CONSTRAINT PKGenre PRIMARY KEY (code));
211
Vous pouvez remarquer que lordre de cration des tables respecte le rfrencement entre PRIMARY KEY et FOREIGN KEY. Les tables qui sont rfrences par cette dernire clause doivent tre cres avant celles qui les rfrencent. Par exemple la table Artiste est cre avant la table Film cause de la cl trangre idMES. Cest en revanche lordre inverse qui est suivi pour les commandes DROP : on ne peut pas dtruire une table qui est rfrence par une commande FOREIGN KEY. Notez quen principe on ne place pas les commandes DROP dans un script de cration puisquon ne souhaite pas prendre le risque de dtruire des donnes existantes. Comme il sagit ici dune base de test, la situation est diffrente. La base est disponible sur le site et contient un chantillon de lms avec leur metteur en scne, leurs acteurs et les notations de quelques internautes. vous de jouer : il faut concevoir, saisir et excuter les ordres SQL correspondant aux requtes qui suivent.
A.1.1 Slections simples

1. Tous les titres de lms. 2. Nom et prnom des internautes normands 3. Titre et anne de tous les drames, tris par anne ascendante. Donnez ensuite le tri par anne descendante. 4. Nom et anne de naissance des artistes ns avant 1950. 5. Titre et anne de tous les lms parus entre 1960 et 1980 6. Tous les genres de lms (liminez les doublons). 7. Titre, genre et rsum des lms qui sont soit des drames, soit des westerns (utilisez la construction IN), et dont le rsum contient la chane de caractres vie . 8. Les artistes dont le nom commence par H (commande LIKE). 9. Quels sont les acteurs dont on ignore lanne de naissance? (Attention : cela signie que la valeur est absente). 10. Prnom, nom et ge de chaque artiste (NB : lge est la diffrence entre lanne courante et lanne de naissance). Nommez ge la colonne obtenue (commande AS).
A.1. INTERROGATION AVEC SQL
212
A.1.2 Jointures
1. Qui jou le rle de Morpheus (nom et prnom) ? 2. Noms des rles pour le lm Titanic. 3. Qui est le ralisateur de Alien ? 4. Prnom et nom des internautes qui ont donn une note de 4 un lm (donner aussi le titre du lm). 5. Quels acteurs ont jou quel rle dans le lm Vertigo ? 6. Films dont le ralisateur est Tim Burton, et un des acteurs avec Jonnhy Depp. 7. Titre des lms dans lesquels a jou Bruce Willis. Donner aussi le nom du rle. 8. Quel metteur en scne a tourn dans ses propres lms ? Donner le nom, le rle et le titre des lms. 9. Quel metteur en scne a tourn en tant quacteur (mais pas forcment dans son propre lm) ? Donner le nom, le rle et le titre des lms o le metteur en scne a jou. 10. Dans quels lms le metteur en scne a-t-il le mme prnom que lun des interprtes ? (titre, nom du metteur en scne, nom de linterprte). Le metteur en scne et linterprte ne doivent pas tre la mme personne.
A.1.3 Requtes imbriques

Les requtes suivantes peuvent sexprimer avec une imbrication des clauses SELECT, mais on peut galement utiliser des jointures plat . Si le cur vous en dit, essayez les deux versions. 1. Donnez les nom et prnom des artistes qui on mis en scne un lm. 2. Donnez le titre et lanne des lms qui ont le mme genre que Matrix. 3. Donnez les titre et lanne des lms qui ont le mme genre que Matrix. 4. Donnez le nom des internautes qui ont not le lm Alien. Donnez galement la note.
A.1.4 Ngation
L encore, il existe souvent plusieurs manires dexprimer la mme requte. 1. Les lms sans rle. Faire un requte en ne donnant que lid du lm. Comment faire ensuite si on veut donner aussi le titre ? 2. Nom et prnom des acteurs qui nont jamais mis en scne de lm. 3. Les internautes qui nont pas not de lm paru en 1999.
213
A.1.5 Fonctions de groupe

1. Quelle est le nombre de lms nots par linternaute rigaux@lri.fr, quelle est la moyenne des notes donnes, la note minimale et la note maximale ? 2. Combien de fois Bruce Willis a-t-il jou le role de McLane ? 3. Anne du lm le plus ancien et du lm le plus rcent. 4. id, Nom et prnom des ralisateurs, et nombre de lms quils ont tourns.
A.2
Cration dun schma relationnel
Il sagit de dnir un schma de base de donnes, dy intgrer des contraintes, des vues et des triggers, et dy insrer quelques informations.
A.2.1 Cration des tables

Crez les tables du schma Agence de voyages, vues en cours, et rappeles ci-dessous. Station (nomStation, capacit, lieu, rgion, tarif) Activite (nomStation, libell, prix) Client (id, nom, prnom, ville, rgion, solde) Sejour (id, station, dbut 1 , nbPlaces) Attention bien dnir les cls primaires et trangres. Voici les autres contraintes portant sur ces tables. 1. Les donnes capacit, lieu, nom, ville, solde et nbPlaces doivent toujours tre connues. 2. Les montants (prix, tarif et solde) ont une valeur par dfaut 0. 3. Il ne peut pas y avoir deux stations dans le mme lieu et la mme rgion. 4. Les rgions autorises sont : Ocean Indien, Antilles, Europe, Ameriques et Extreme Orient. 5. La destruction dune station doit entraner la destruction de ses activits et de ses sjours. Conseil : donnez des noms vos contraintes CHECK avec la clause CONSTRAINT. Il est possible aussi de donner des noms aux contraintes FOREIGN KEY et PRIMARY KEY.
A.2.2 Insertion de donnes

Insrez dans la base les donnes de la gure A.1 avec des ordres INSERT. Attention, lordre des INSERT est important (pourquoi ?). Vous pouvez ensuite tester les contraintes avec quelques ordres SQL. Par exemple : dtruisez la station et vriez que les activits ont disparu ; insrez une autre station en (Guadeloupe, Antilles) ; insrez une station dans une rgion Nullepart, etc.
1. pour les dates, utiliser un numrique simple et les saisir au format aaaammjj.
A.2. CRATION DUN SCHMA RELATIONNEL

Station Capacit Lieu 350 Guadeloupe Activite NomStation Libell Venusa Voile Venusa Plonge Client prnom ville Phileas Londres Blaise Paris Jack New York Sejour station dbut Venusa 1998-08-03
214
NomStation Venusa
Rgion Antilles
Tarif 1200
Prix 150 120
id 10 20 30
nom Fogg Pascal Kerouac
rgion Europe Europe Amrique
solde 12465 6763 9812
idClient 20
nbPlaces 4
F IG . A.1 La base Agence
A.2.3 Vues
Maintenant il faut crer des vues et tester linterrogation et la mise jour travers ces vues. 1. Crez les vues suivantes sur le schma prcdent. (a) Une vue ActivitesModiques (Station, Activite) donnant le nom des stations et des activits dont le prix est infrieur 140 FF. Toute ligne insre dans cette vue doit apparatre dans la vue ensuite. (b) Une vue ActivitesCheres, de mme schma, avec prix suprieur 140 FF, et la mme contrainte dinsertion. (c) Une vue StationEuro (Nom, Capacite, Lieu, TarifEuro) donnant le nom dune station, sa capacit, le lieu et le tarif en euro (un euro=6,58 FF). (d) Une vue Tarifs (Station, Tarif, OptionMin, OptionMax) donnant, pour chaque station, le tarif et les prix min et max des activits. (e) Une vue Reservation (nomStation, PlacesReservees) donnant, par station et date de dbut de sjour, le nombre de places rserves.
2. Consultez ensuite le contenu de ces vues. Vous pouvez insrez quelques lignes supplmentaires dans les tables et constater quelles sont prises en compte dans les vues. 3. Dans quelles vues peut-on insrer, dtruire et mettre jour ? Essayez les oprations suivantes : (a) Insrez une activit Kayac pour la station Venusa dans ActivitesCheres et ActivitesModiques. Le contrle sur linsertion est-il utile dans ce cas ? (b) Peut-on insrer dans StationEuro ? Sous quelle condition ? Faites lessai. (c) Dtruisez une ligne de StationEuro.
215
A.2.4 Triggers
1. Implantez par un trigger la rgle suivante : si le prix dune activit baisse, alors le tarif de la station doit augmenter de la diffrence. Indication : le trigger doit se dclencher sur une modication, et tester pour chaque ligne que la nouvelle valeur est plus grande que lancienne. Si ce nest pas le cas, faire un UPDATE de la station pour ajouter la diffrence entre lancienne et la nouvelle valeur. 2. Faites lexprience : diminuez le prix dune activit, et regardez ce qui se passe pour la station. 3. On veut disposer de linformation nbActivites dans la table Station. Pour cela : (a) Ajoutez la colonne nbActivites avec pour valeur par dfaut 0. (b) Crez un trigger qui maintient cette information.
A.3
Concurrence daccs
On va maintenant tudier le comportement concret dun SGBD en cas daccs concurrents la mme ressource. Pour cel on va simuler lexcution concurrente de programmes laide du petit ensemble de lectures/critures sur la base Agence de voyage cr dans le premier exercice : modication du solde de certains clients et slection des clients. Crez 4 chiers, nomms SEL.sql, MAJpas.sql, MAJfog.sql et MAJker.sql et entrez-y les commandes suivantes : 1. SEL.sql PROMPT Affichage des clients =>; SELECT * FROM client;
2. MAJpas.sql PROMPT Augmentation du client Pascal =>; UPDATE client SET solde = solde + 1000 WHERE client = Pascal;
3. MAJfog.sql PROMPT Augmentation du client Fogg =>; UPDATE client SET solde = solde + 1000 WHERE client = Fogg;
4. MAJker.sql PROMPT Augmentation du client Kerouac =>; UPDATE client SET solde = solde + 1000 WHERE client = Kerouac;
Ensuite, ouvrez deux fentres et lancez SQLPLUS dans chacune : chaque session est considre par ORACLE comme un utilisateur, et on a donc 2 utilisateurs, nomms 1 et 2, en situation de concurrence. Dans tout ce qui suit, on note lexcution de linstruction par lutilisateur . Par exemple corespond lexcution du

A.4. PROGAMMATION DUNE APPLICATION AVEC BASE DE DONNES
216
chier MAJker dans la premire fentre par la commande @MAJker. On note de mme et lexcution des commandes rollback; et commit; dans la fentre . Questions Executez les squences dinstruction dcrites ci-dessous. Dans chacun des cas, expliquez ce qui se passe. 1. Premire exprience : lutilisateur 1 effectue des mises--jour, tandis que lutilisateur 2 ne fait que des slections. Que constate-t-on ?
3. Maintenant les deux utilisateurs effectuent des MAJ simultanes.
Un bloquage est apparu. Pourquoi ? 4. Idem, avec un ordre des oprations qui diffre dun utilisateur lautre.
Que constate-t-on ? 5. En fait, ORACLE pratique une verrouilage deux phases assez libral, qui ne garantit pas la srialisabilit : aucun verrrou nest plac sur une ligne lors dune lecture. Lutilisateur peut verrouiller explicitement en ajoutant la clause FOR UPDATE. Exemple : SELECT * FROM client FOR UPDATE; Chaque ligne slectionne est alors verrouille. Refaites les expriences prcdentes avec un verrouillage explicite des lignes que vous voulez modier. 6. Exprimentez les excutions cdentes en spciant le mode suivant : SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

A.4
Progammation dune application avec base de donnes
faire.
A.5
Projet
!

)
!
) ) )

!
) )
) )
!
) )
)
)
2. idem, mais avec des
. .
!
)
)
) )
) ) ) )
BIBLIOGRAPHIE
217
Bibliographie
[Garcia-Molina et al., 2000] H. Garcia-Molina, J.D. Ullman, et J. Widom. Database System Implementation. Prentice Hall, 2000. [Ullman et Widom, 1999] J.D. Ullman et J. Widom. A First Course in Database Systems. Prentice Hall, 1999.

Cours de Bases de Données

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cours de Bases de Données

Enviado por

Direitos autorais:

Formatos disponíveis

Cours de bases de donnes

Philippe Rigaux 12 janvier 2004

TABLE DES MATIRES

Table des matires

Philippe Rigaux (rigaux@lri.fr), Cours de bases de donnes, 2004

TABLE DES MATIRES

TABLE DES MATIRES

Philippe Rigaux (rigaux@lri.fr), Cours de bases de donnes, 2004

TABLE DES MATIRES

TABLE DES MATIRES

0.1 Donnes, Bases de donnes et SGBD

0.1. DONNES, BASES DE DONNES ET SGBD

TABLE DES MATIRES

0.2 Que doit-on savoir pour utiliser un SGBD ?

0.2.1 Dnition du schma de donnes

0.2. QUE DOIT-ON SAVOIR POUR UTILISER UN SGBD ?

0.2.2 Les oprations sur les donnes

TABLE DES MATIRES

0.2.4 Concurrence daccs

0.3 Le plan du cours

Philippe Rigaux (rigaux@lri.fr), Cours de bases de donnes, 2004

0.3. LE PLAN DU COURS

Philippe Rigaux (rigaux@lri.fr), Cours de bases de donnes, 2004

CHAPITRE 1. LE MODLE ENTIT/ASSOCIATION

Avantage et inconvnients du modle E/A

1.1 Principes gnraux

1.1. PRINCIPES GNRAUX

1.1.1 Bons et mauvais schmas

1.1.2 La bonne mthode

CHAPITRE 1. LE MODLE ENTIT/ASSOCIATION

anneNaiss 1943 1899 1910 1946 1963 1954 1932

anneNaiss 1943 1899 1910 1946 1963 1954 1932

1.2. LE MODLE E/A : PRSENTATION INFORMELLE

1.2 Le modle E/A : Prsentation informelle

Pays code nom langue

F IG . 1.1 Le schma de la base de donnes Films

CHAPITRE 1. LE MODLE ENTIT/ASSOCIATION

1.3.1 Entits, attributs et identiants

CHAPITRE 1. LE MODLE ENTIT/ASSOCIATION

21 . Enn, un ensemble dentits

F IG . 1.2 Reprsentation des types dentit

1.3.2 Associations binaires

Philippe Rigaux (rigaux@lri.fr), Cours de bases de donnes, 2004

Dnition 6 Une association binaire entre les ensembles dentits et .

est un ensemble de couples

Alfred Hitchcock Clint Eastwood

Vertigo Impitoyable Psychose

F IG . 1.3 Association entre deux ensembles.

En gnral, ce nombre est 1 (au plus une fois) ou * .

(plusieurs fois, nombre indetermin), not par le symbole de peut

entre deux types dentits. La cardinalit de lassociation de peut

CHAPITRE 1. LE MODLE ENTIT/ASSOCIATION

Ralisateur 0..1 id nom prnom anneNaissance Ralise 0..n

Film id titre anne genre

F IG . 1.4 Reprsentation de lassociation.

F IG . 1.5 Association (Acteur,Film)

Film id titre anne genre

nom 0..* prnom anneNaiss Joue

F IG . 1.6 Associations entre Artiste et Film.

Internaute email nom prnom rgion note

Film id titre anne genre

1.3.3 Entits faibles

CHAPITRE 1. LE MODLE ENTIT/ASSOCIATION