Vous êtes sur la page 1sur 209

Cours de bases de donnes

Philippe Rigaux 20 fvrier 2002

TABLE DES MATIRES

Table des matires


1 2 Introduction Prsentation gnrale 2.1 Donnes, Bases de donnes et SGBD . . . . 2.2 Que doit-on savoir pour utiliser un SGBD ? 2.2.1 Dnition du schma de donnes . 2.2.2 Les oprations sur les donnes . . . 2.2.3 Optimisation . . . . . . . . . . . . 2.2.4 Concurrence daccs . . . . . . . . 2.3 Le plan du cours . . . . . . . . . . . . . . . 7 9 9 11 11 12 12 12 13

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

I Modles et langages
3 Le modle Entit/Association 3.1 Principes gnraux . . . . . . . . . . . . 3.1.1 Bons et mauvais schmas . . . . . 3.1.2 La bonne mthode . . . . . . . . 3.2 Le modle E/A : Prsentation informelle . 3.3 Le modle . . . . . . . . . . . . . . . . . 3.3.1 Entits, attributs et identiants . . 3.3.2 Associations binaires . . . . . . . 3.3.3 Entits faibles . . . . . . . . . . . 3.3.4 Associations gnralises . . . . . 3.4 Avantage et inconvnients du modle E/A 3.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15
17 17 18 18 20 21 21 24 27 29 30 31 35 35 37 38 43 43 45 45 46 47 50 52

Le modle relationnel 4.1 Dnition dun schma relationnel . . . . . . . . 4.2 Passage dun schma E/A un schma relationnel 4.2.1 Rgles gnrales . . . . . . . . . . . . . 4.2.2 Retour sur le choix des identiants . . . . 4.2.3 Dnormalisation du modle logique . . . 4.3 Le langage de dnition de donnes SQL2 . . . . 4.3.1 Types SQL . . . . . . . . . . . . . . . . 4.3.2 Cration des tables . . . . . . . . . . . . 4.3.3 Contraintes . . . . . . . . . . . . . . . . 4.3.4 Modication du schma . . . . . . . . . 4.4 Exercices . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

4 5 Lalgbre relationnelle 5.1 Les oprateurs de lalgbre relationnelle 5.1.1 La slection, . . . . . . . . . 5.1.2 La projection, . . . . . . . . . 5.1.3 Le produit cartsien, . . . . . 5.1.4 Lunion, . . . . . . . . . . . 5.1.5 La diffrence, . . . . . . . . 5.1.6 Jointure, . . . . . . . . . . . 5.2 Expression de requtes avec lalgbre . 5.2.1 Slection gnralise . . . . . . 5.2.2 Requtes conjonctives . . . . . 5.2.3 Requtes avec et . . . . . . 5.3 Exercices . . . . . . . . . . . . . . . .

TABLE DES MATIRES


55 56 57 57 58 59 60 60 61 61 62 63 64 67 68 68 70 71 72 72 73 74 74 76 76 76 77 78 78 78 78 79 79 81 82 82 82 83 85 85 86 87 87 88 89 91 91 91 94 96 97

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

Le langage SQL 6.1 Requtes simples SQL . . . . . . . . . . . 6.1.1 Slections simples . . . . . . . . . 6.1.2 La clause WHERE . . . . . . . . . . 6.1.3 Valeurs nulles . . . . . . . . . . . . 6.2 Requtes sur plusieurs tables . . . . . . . . 6.2.1 Jointures . . . . . . . . . . . . . . 6.2.2 Union, intersection et diffrence . . 6.3 Requtes imbriques . . . . . . . . . . . . 6.3.1 Conditions portant sur des relations 6.3.2 Sous-requtes correlles . . . . . . 6.4 Agrgration . . . . . . . . . . . . . . . . . 6.4.1 Fonctions dagrgation . . . . . . . 6.4.2 La clause GROUP BY . . . . . . . 6.4.3 La clause HAVING . . . . . . . . . 6.5 Mises--jour . . . . . . . . . . . . . . . . . 6.5.1 Insertion . . . . . . . . . . . . . . 6.5.2 Destruction . . . . . . . . . . . . . 6.5.3 Modication . . . . . . . . . . . . 6.6 Exercices . . . . . . . . . . . . . . . . . . Schmas relationnels 7.1 Schmas . . . . . . . . . . . . . . . . . . . 7.1.1 Dnition dun schma . . . . . . . 7.1.2 Utilisateurs . . . . . . . . . . . . . 7.2 Contraintes et assertions . . . . . . . . . . 7.3 Vues . . . . . . . . . . . . . . . . . . . . . 7.3.1 Cration et interrogation dune vue 7.3.2 Mise jour dune vue . . . . . . . 7.4 Triggers . . . . . . . . . . . . . . . . . . . 7.4.1 Principes des triggers . . . . . . . . 7.4.2 Syntaxe . . . . . . . . . . . . . . . 7.5 Exercices . . . . . . . . . . . . . . . . . . Programmation avec SQL 8.1 Interfaage avec le langage C . . . 8.1.1 Un exemple complet . . . 8.1.2 Dveloppement en C/SQL 8.1.3 Autres commandes SQL . 8.2 Linterface Java/JDBC . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

TABLE DES MATIRES


8.2.1 8.2.2 8.2.3

Principes de JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Le plus simple des programmes JDBC . . . . . . . . . . . . . . . . . . . . . . . . 99 Exemple dune applet avec JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . 100

II Aspects systmes
9 Techniques de stockage 9.1 Stockage de donnes . . . . . . . . 9.1.1 Supports . . . . . . . . . . 9.1.2 Fonctionnement dun disque 9.1.3 Optimisations . . . . . . . . 9.1.4 Technologie RAID . . . . . 9.2 Fichiers . . . . . . . . . . . . . . . 9.2.1 Enregistrements . . . . . . . 9.2.2 Blocs . . . . . . . . . . . . 9.2.3 Organisation dun chier . . 9.3 Oracle . . . . . . . . . . . . . . . . 9.3.1 Fichiers et blocs . . . . . . 9.3.2 Les tablespaces . . . . . . . 9.3.3 Cration des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

105
107 108 108 109 111 114 117 117 119 122 125 126 129 132 133 134 135 137 138 139 140 141 143 143 147 148 150 150 151 151 152 153 155 155 156 157 157 158 159 161 165 166 173 173 174

10 Indexation 10.1 Indexation de chiers . . . . . . . . . 10.1.1 Index non-dense . . . . . . . 10.1.2 Index dense . . . . . . . . . . 10.1.3 Index multi-niveaux . . . . . 10.2 Larbre-B . . . . . . . . . . . . . . . 10.2.1 Prsentation intuitive . . . . . 10.2.2 Recherches avec un arbre-B+ 10.3 Hachage . . . . . . . . . . . . . . . . 10.3.1 Principes de base . . . . . . . 10.3.2 Hachage extensible . . . . . . 10.4 Les index bitmap . . . . . . . . . . . 10.5 Indexation dans Oracle . . . . . . . . 10.5.1 Arbres B+ . . . . . . . . . . . 10.5.2 Arbres B . . . . . . . . . . . 10.5.3 Indexation de documents . . . 10.5.4 Tables de hachage . . . . . . 10.5.5 Index bitmap . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

11 valuation de requtes 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Evaluation dune requte . . . . . . . . . . . . . . . . . . . . . 11.2.1 Evaluation de requtes efcace . . . . . . . . . . . . . . 11.2.2 Mesure du cot dune opration . . . . . . . . . . . . . 11.2.3 Techniques daccs et prtraitement . . . . . . . . . . . 11.2.4 Le Tri externe . . . . . . . . . . . . . . . . . . . . . . . 11.2.5 La Slection . . . . . . . . . . . . . . . . . . . . . . . 11.2.6 Projection . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.7 Jointure . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Compilation dune requte et optimisation . . . . . . . . . . . . 11.3.1 Traduction de la requte en un plan dexcution logique 11.3.2 Lois algbriques . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

6 11.3.3 11.3.4 11.3.5 11.3.6 11.3.7 11.3.8 Amlioration dun plan dexcution logique . . . . . . . . . . Estimation des cots et choix dun plan dexcution physique Exemple destimation du cot dune opration . . . . . . . . Choix dun oprateur pour la slection . . . . . . . . . . . . . Stratgies pour le choix dun oprateur pour la jointure . . . . Pipelinage ou matrialisation des rsultats intermdiaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 178 182 182 183 183 187 187 188 189 190 192 192 195 195 196 199 199 199 200 201 203 203 203 204 204 204 206 208

12 Introduction la concurrence daccs 12.1 Prliminaires . . . . . . . . . . . . . . . . . . 12.1.1 Excutions concurrentes : srialisabilit 12.1.2 Transaction . . . . . . . . . . . . . . . 12.1.3 Excutions concurrentes : recouvrabilit 12.2 Contrle de concurrence . . . . . . . . . . . . 12.2.1 Verrouillage deux phases . . . . . . . 12.2.2 Contrle par estampillage . . . . . . . 12.3 Gestion des transactions en SQL . . . . . . . . 12.4 Exercices . . . . . . . . . . . . . . . . . . . . 13 Travaux pratiques 13.1 Environnement . . . . . . . . . . . . 13.1.1 Connexion au systme . . . . 13.1.2 Les commandes utiles . . . . 13.1.3 Utilisation de SQLPLUS . . . 13.2 Requtes SQL . . . . . . . . . . . . . 13.2.1 Slections simples . . . . . . 13.2.2 Jointures . . . . . . . . . . . 13.2.3 Ngation . . . . . . . . . . . 13.2.4 Fonctions de groupe . . . . . 13.3 Concurrence daccs . . . . . . . . . 13.4 Normalisation dun schma relationnel  13.5 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 1

Introduction
Sommaire
Ce cours sadresse aux tudiants du cycle A du CNAM et a pour objectif ltude des principes des SGBD relationnels et la mise en pratique de ces principes. Le contenu du cours est essentiellement le suivant : 1. Conception dun schma relationnel. Il sagit de savoir dnir un schma relationnel complet et correct, comprenant des tables, des contraintes, des vues. 2. Langages dinterrogation et de manipulation. Laccent est mis sur SQL et ses fondements, et sur lintgration de SQL avec un langage de programmation comme le C. De plus, le cours comprend une introduction aux problmes de concurrence daccs, dont la connaissance est ncessaire aux dveloppeurs dapplications bases sur des SGBD. Des travaux pratiques avec le SGBD ORACLE permettent de mettre en oeuvre les techniques tudies en cours. Laccent est donc plutt mis sur les notions de base (quest-ce quun SGBD, quune base de donnes, quun langage dinterrogation) et leur application pratique. Il demand davoir acquis la n du cours les connaissances ncessaires lutilisation dun SGBD par un informaticien non-spcialiste. : cration dun schma, insertion, mise--jour, destruction, interrogation de donnes, et comprehension des mcanismes de concurrence intervenant dans la gestion dun SGBD. En revanche, tout ce qui relve de la comprhension des mcanismes internes dun SGBD (reprsentation physique, valuation de requtes) ou des fondements thoriques du modle relationnel nest pas abord ici. Ce document est un support de cours : il ne prtend certainement pas tre exhaustif ni traiter en dtail tous les sujets abords. Lassistance au cours proprement dit, ainsi quaux travaux dirigs et aux travaux pratiques est fortement recommande. Il existe de plus un site WEB qui donne des renseignements complmentaires, les horaires des cours, les solutions de certains exercices, etc. Voici ladresse : http://sikkim.cnam.fr/~rigaux/bdpi.html Pour ceux qui veulent en savoir plus, il existe une riche bibliographie dont voici quelques lments recommandables : Ouvrages en franais 1. Carrez C., Des Structures aux Bases de Donnes, Masson 2. Gardarin G., Matriser les Bases de Donnes: modles et langages, Eyrolles 3. Marcenac, P., SGBD relationnels, Optimisation des performances, Eyrolles.

8 Ouvrages en anglais

CHAPITRE 1. INTRODUCTION

1. Melton J. et A.R. Simon, Understanding SQL, A Complete Guide, Morgan Kaufmann, 1993. 2. Ullman J.D. et Widom J., A rst Course in database Systemsd, Prentice Hall, 1999 3. Date C.J., An Introduction to Database Systems, Addison-Wesley Le premier chapitre (correspondant au premier cours) 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 de lenseignement.

Chapitre 2

Prsentation gnrale
Sommaire
2.1 2.2 Donnes, Bases de donnes et SGBD . . . . Que doit-on savoir pour utiliser un SGBD ? 2.2.1 Dnition du schma de donnes . . . 2.2.2 Les oprations sur les donnes . . . . 2.2.3 Optimisation . . . . . . . . . . . . . 2.2.4 Concurrence daccs . . . . . . . . . Le plan du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11 11 12 12 12 13

2.3

Ce chapitre prsente un panorama gnral de la problmatique des bases de donnes.

2.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 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 : Denition 2.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

10

CHAPITRE 2. PRSENTATION GNRALE

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. Denition 2.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. 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.

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

11

2.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.

2.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 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; ...

12

CHAPITRE 2. PRSENTATION GNRALE

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.

2.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.

2.2.3

Optimisation

Loptimisation (dune requte) sappuie sur lorganisation physique des donnes. Les principaux types dorganisation sont les chiers squentiels, les index (denses. secondaires, arbres B) et le regroupement des donnes par hachage. Un module particulier du SGBD, loptimiseur, tient compte de cette organisation et des caractristiques de la requte pour choisir le meilleur squencement des oprations.

2.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.

2.3. LE PLAN DU COURS

13

2.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.

14

CHAPITRE 2. PRSENTATION GNRALE

15

Premire partie

Modles et langages

17

Chapitre 3

Le modle Entit/Association
Sommaire
3.1 Principes gnraux . . . . . . . . . . . . . 3.1.1 Bons et mauvais schmas . . . . . . 3.1.2 La bonne mthode . . . . . . . . . . Le modle E/A : Prsentation informelle . Le modle . . . . . . . . . . . . . . . . . . 3.3.1 Entits, attributs et identiants . . . 3.3.2 Associations binaires . . . . . . . . 3.3.3 Entits faibles . . . . . . . . . . . . 3.3.4 Associations gnralises . . . . . . Avantage et inconvnients du modle E/A Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18 18 20 21 21 24 27 29 30 31

3.2 3.3

3.4 3.5

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.

3.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.

18

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

3.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.

3.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.

3.1. PRINCIPES GNRAUX

19

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 1997 6 Titanic 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.

20

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

3.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 3.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 0..* rle Donne une note Ralise 0..1 0..* Film id titre anne genre rsum * 1..1 * note * Internaute email nom prnom motDePpasse anneNaissance

Pays code nom langue

F IG . 3.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

3.3. LE MODLE

21

Artiste et Film indique quon sautorise ne pas connatre le metteur en scne dun lm. Attention : cela ne signie pas que ce metteur en 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 3.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.

3.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.

3.3.1

Entits, attributs et identiants

Il est difcile de donner une dnition trs prcise des entits. Les points essentiels sont rsums cidessous. Denition 3.1 (Entit) On dsigne par entit tout objet identiable et pertinent pour lapplication.

22

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

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. 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 %'&)(!01&!2305454641&!798 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. Denition 3.2 (Type dentit) Le type dune entit est compos des lments suivants : 1. son nom ;

3.3. LE MODLE

23

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. On dit quun entit  est une instance de son type instance dun mme type  est une extension de  . Il reste dnir plus prcisment la notion de cl.


. Enn, un ensemble dentits

%'3(@0A'230645464A'7B8

Denition 3.3 (Cl) Soit  sous-ensemble minimal de extension de  .




un type dentit et  lensemble des attributs de  . Une cl de  est un permettant didentier de manire unique une entit parmi nimporte quelle

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 3.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 . 3.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.

24

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

3.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. Denition 3.4 Une association binaire entre les ensembles dentits C( et D2 est un ensemble de couples 3(!0A'26 , avec !(C"$C( et '2E"FG2 . 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 . 3.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 3.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. Denition 3.5 (Cardinalit) Soit une association HC(30AD2' entre deux types dentits. La cardinalit de lassociation pour GIP0AQR"S%UT)0WVX8 , est une paire [min, max] telle que : 1. Le symbole max (cardinalit maximale) dsigne le nombre maximal de fois o une une entit DI peut intervenir dans lassociation.
 I

de

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

de 
I

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

3.3. LE MODLE

25

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.
Ralisateur 0..1 id nom prnom anneNaissance Ralise 0..n id titre anne genre Film

F IG . 3.4 Reprsentation de lassociation.

Dans la notation UML, on indique les cardinalits aux deux extrmits dun lien dassociation entre deux types dentits `ba et `bc . Les cardinalits pour `ba sont places lextrmit du lien allant de `ba vers `bc et les cardinalits pour `bc sont lextrmit du lien allant de `ba vers `bc . Pour lassociation entre Ralisateur et Film, cela donne lassociation de la gure 3.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 3.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 . 3.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 3.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.

26
Artiste id

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION


Film Ralise 1..1 0..* 0..* rle id titre anne genre

nom 0..* prnom anneNaiss Joue

F IG . 3.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 le lm (gure 3.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 : Denition 3.6 (Cl dune association) La cl dune association (binaire) entre un type dentit type dentit  2 est le couple constitu de la cl d ( de  ( et de la cl d 2 de  2 .
 (

et un

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 3.7).
Date date

Internaute email nom prnom rgion note

Film id titre anne genre

F IG . 3.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.

3.3. LE MODLE

27

Comme le montre la gure 3.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.
Internautes Phileas Fogg Jules Maigret Films Ennemi dtat Van Gogh

12 juillet 2023

6 juin 2000

Dates

F IG . 3.8 Graphe dune association ternaire

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 3.9).
Internaute 0..n email nom prnom rgion date note 0..n Film id titre anne genre

F IG . 3.9 Notation abrge dune association avec un type dentit Date

Nous reviendrons plus longuement sur les associations ternaires par la suite.

3.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 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 3.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

28

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

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 3.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   .
Cinma nom ville rue numro 1 * Salle id capacit dateConstr. (a) Cinma nom ville rue numro no * Salle capacit dateConstr. (b)

F IG . 3.10 Modlisation du lien Cinma-Salle (a) sous la forme dune association classique (b) avec une entit faible

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 e associ un type dentit  implique galement des contraintes fortes sur les crations, modications et destructions des instances de e 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 ; 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.

3.3. LE MODLE

29

3.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 Y -aire est une gnralisation de celle des associations binaires. Denition 3.7 Une association Y -aire entre Y types dentits 3(!0A'23064545460A'7f o chaque 'I appartient DI .
C(!0AD2)0546454AG7

est un ensemble de Y -uplets

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. tarif Horaire id heureDbut heureFin

Sance

Film id titre anne genre

F IG . 3.11 Association ternaire reprsentant les sances

Horaires 14h16h 16h18h Films Salles Salle Rex1 Salle Kino3 Impitoyable Vertigo

F IG . 3.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 3.11). Chaque instance de cette association lie un lm, un horaire et une salle. La gure 3.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 Y -uplet [nomCinma, noSalle, idFilm, idHoraire]. Une telle cl est

30

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

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 3.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 : Rgle 3.1 Soit  une association entre les types dentit type dentit seffectue en trois tapes : 1. On attribue un identiant autonome  . 2. On cre une association GI de type 1:n entre  et chacun des DI . La contrainte minimale, du ct de  , est toujours 1. 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 3.13.
Cinma nom ville rue numro no * Salle 1..1 capacit dateConstr. * id tarif Horaire id heureDbut heureFin 1..1 * Sance *
%'C('01D2)0645464g0AD7b8

. La transformation de


en

Film 1..1 id titre anne genre

F IG . 3.13 Lassociation Sance transforme en entit

3.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. 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

3.5. EXERCICES

31

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 (beau@ u hPwyx!Ct` . coup) plus : J. Rumbauch @hpiXq , rRitsv 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.

3.5

Exercices

Exercice 3.1 On vous donne un schma E/A (gure 3.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). 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 3.2 Le second schma (gure 3.15) reprsente des rencontres dans un tournoi de tennis. 1. Peut-on jouer des matchs de double ? 2. Un joueur peut-il gagner un match sans y avoir particip ?

32
Mdicament code libell 0..* nbPrises

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION


Mdecin matricule nom 1..1 Donne Patient noSS nom 1..1 Assiste 0..* Consultation no date

0..*

0..*

F IG . 3.14 Centre mdical

Joueur noCarte nom 2..2 Joue

Gagne 1..1 0..* Match id horaire

Terrain no surface 1..1 0..* Se joue sur

0..*

F IG . 3.15 Tournoi de tennis

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 ? Exercice 3.3 Voici le schma E/A (gure 3.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 3.4 Voici (gure 3.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 3.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 3.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.

3.5. EXERCICES
Journaliste id nom dateNaiss 1..1 rdige 0..n Journal nom adresse 0..n no Numro date tirage interviewe 0..n Personnalit id nom 0..n prnom nation.

33

a travaill pour 0..n Article no contenu 0..n parat dans 0..n

1..1

1..1

Sujet id libelle

F IG . 3.16 Systme dinformation dun quotidien

Plage dure dateEnreg

Disque titre no anne producteur

Oeuvre id titre anne

Interprte joue sur id nom prnom

F IG . 3.17 Contenu dun disque

Exercice 3.5 La gure 3.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. 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.

34

CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION


3. Transformer lassociation en entit, selon la rgle vue en cours.

Exercice 3.6 Voici quelques tableaux (gure 3.19, 3.20, 3.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 . 3.18 Sances de cours SOCIETE Tresys Fungus Demona Faribole DIRECTEUR Charlus Morel Saint-Loup Charlus

F IG . 3.19 Association SOCIETE/DIRECTEUR ORDINATEUR PC124 MAC04 MAC03 PC02 MAC03 UTILISATEUR Charlus Morel Saint-Loup Morel Charlus

F IG . 3.20 Association ORDINATEUR/UTILISATEUR ORDINATEUR PC124 MAC04 MAC04 PC124 PC02 DISQUES dsk09 dsk08 dsk05 dsk11 dsk04

F IG . 3.21 Association ORDINATEUR/DISQUES DURS

35

Chapitre 4

Le modle relationnel
Sommaire
4.1 4.2 Dnition dun schma relationnel . . . . . . . . Passage dun schma E/A un schma relationnel 4.2.1 Rgles gnrales . . . . . . . . . . . . . . . 4.2.2 Retour sur le choix des identiants . . . . . 4.2.3 Dnormalisation du modle logique . . . . . Le langage de dnition de donnes SQL2 . . . . 4.3.1 Types SQL . . . . . . . . . . . . . . . . . 4.3.2 Cration des tables . . . . . . . . . . . . . 4.3.3 Contraintes . . . . . . . . . . . . . . . . . 4.3.4 Modication du schma . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 37 38 43 43 45 45 46 47 50 52

4.3

4.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.

4.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 4.1. Une relation a donc un nom (Film) et se compose dun ensemble de colonnes dsignes par

36 titre Alien Vertigo Volte-face Pulp Fiction anne 1979 1958 1997 1995

CHAPITRE 4. LE MODLE RELATIONNEL


genre Science-Fiction Suspense Thriller Policier

F IG . 4.1 Une relation un nom dattribut. Dans chaque 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 4.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 4.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 :
H(C)(!0AG2)23054645460AG7)7

o les CI sont les noms dattributs et les I 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 (46454R7 entre des domaines ('0645464g0A7 est lensemble de tous les tuples U(!054546450A37 o 3I"I . 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.

4.2. PASSAGE DUN SCHMA E/A UN SCHMA RELATIONNEL

37

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 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 Un tuple est une liste de Y valeurs domaine I : 3I"$I . Exemple :
U('064546450P37

o chaque valeur

3I

est la valeur dun attribut

CI

de

(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 4.2.

4.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.

38
Artiste id nom prnom anneNaissance 0..* Joue 0..* rle Cinma nom adresse no Ralise 0..1 0..* Film id titre anne genre rsum *

CHAPITRE 4. LE MODLE RELATIONNEL


Internaute Donne une note * note email nom prnom motDePpasse anneNaissance

1..1

Pays code nom langue

Salle capacit climatise

Horaire id heureDbut heureFin

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

4.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. 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 4.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.

4.2. PASSAGE DUN SCHMA E/A UN SCHMA RELATIONNEL


Rgles de passage : associations de un plusieurs Soit une association de un plusieurs 1 entre suivantes :


39

et
e

. Le passage au modle logique suit les rgles

1. On cre les relations 2. Lidentiant de e

et

correspondant respectivement aux entits  et e .


a

devient un attribut de

Lide est quune occurence de d  rfrence   loccurence de e qui lui est associe laide dune cl trangre. Cette rfrence se fait de manire unique et sufsante laide de lidentiant. Exemple 4.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

anneNaiss 1943 1899 1910 1946 1954 1932 1925

code US FR JP

nom langue Etats Unis anglais France franais Japon japonais La table Pays

1. Il sagit ici des cardinalits maximales qui dterminent pour lessentiel le schma relationnel obtenu.

40 Rgles de passage : associations avec type entit faible

CHAPITRE 4. LE MODLE RELATIONNEL

Une entit faible est toujours identie par rapport une autre entit. Cest le cas par exemple de lassociation en Cinma et Salle (voir chapitre 3). 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. Le passage un schma relationnel est donc identique celui dune association 1-Y 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 4.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 e . 1. On cre les relations 2. On cre une relation 3. La cl de
a a c

et
c

correspondant respectivement aux entits  et e .

apefc

pour lassociation. deviennent des attributs de


apefc

et la cl de

.
a

4. La cl de cette relation est la concatnation des cls des relations 5. Les proprits de lassociation deviennent des attributs de
ape9c

et

Exemple 4.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

4.2. PASSAGE DUN SCHMA E/A UN SCHMA RELATIONNEL

41

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

idActeur rle 100 William Munny 101 Little Bill 101 Bril 103 Robert Dean La table Rle

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

nom prnom email 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)

42

CHAPITRE 4. LE MODLE RELATIONNEL


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

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 . 4.3 Reprsentation dune association ternaire : Sance

Salle (nomCinma, no, capacit) Film (idFilm, titre, anne, genre, rsum, idMES, codePays) Horaire (idHoraire, heureDbut, heureFin) Sance (idFilm, nomCinma, noSalle, idHoraire, tarif) 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 4.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.

4.2. PASSAGE DUN SCHMA E/A UN SCHMA RELATIONNEL

43

4.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). 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. nomCinma noSalle idHoraire titreFilm 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.

4.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 !

44 Suppression de relations

CHAPITRE 4. LE MODLE RELATIONNEL

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 g 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. Introduction de redondance 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.

4.3. LE LANGAGE DE DFINITION DE DONNES SQL2

45

4.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.

4.3.1

Types SQL

La norme SQL ANSI propose un ensemble de types qui sont donns dans le tableau 4.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. 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 . 4.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 h M Longueur de chane. env. 4 octets env. 4 octets 8 octets 2 octets

la

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 4.1.

46

CHAPITRE 4. LE MODLE RELATIONNEL

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 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.

4.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.

4.3. LE LANGAGE DE DFINITION DE DONNES SQL2

47

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).

4.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,

48

CHAPITRE 4. LE MODLE RELATIONNEL


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)); 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);

4.3. LE LANGAGE DE DFINITION DE DONNES SQL2


La commande FOREIGN KEY (idMES) REFERENCES Artiste

49

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). 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.

50 numration des valeurs possibles avec CHECK

CHAPITRE 4. LE MODLE RELATIONNEL

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);

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.

4.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.

4.3. LE LANGAGE DE DFINITION DE DONNES SQL2


Modication des attributs

51

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 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.

52

CHAPITRE 4. LE MODLE RELATIONNEL

4.4

Exercices
titre Cyrano Les oiseaux Titanic Les oiseaux anne 1992 1963 1963 metteurEnScne Rappeneau Hitchcock Cameron Hitchcock acteur Depardieu, Perez Taylor DiCaprio Taylor

Exercice 4.1 La relation de la gure 4.4 est-elle conforme la dnition ? Si non, citez les anomalies.

F IG . 4.4 Une relation

Exercice 4.2 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. Les cls trangres.

Exercice 4.3 Mme exercice que prcdemment, pour lapplication Discothque. Exercice 4.4 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 4.5 Mme exercice, pour le schma Cours. Donner les spcications compltes (cls primaires et trangres, NOT NULL, clauses UNIQUE, etc). Exercice 4.6 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 ?

4.4. EXERCICES

53

Exercice 4.7 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.

54

CHAPITRE 4. LE MODLE RELATIONNEL

55

Chapitre 5

Lalgbre relationnelle
Sommaire
5.1 Les oprateurs de lalgbre relationnelle 5.1.1 La slection, i . . . . . . . . . . . 5.1.2 La projection, j . . . . . . . . . . 5.1.3 Le produit cartsien, k . . . . . . 5.1.4 Lunion, l . . . . . . . . . . . . . 5.1.5 La diffrence, m . . . . . . . . . . 5.1.6 Jointure, n . . . . . . . . . . . . Expression de requtes avec lalgbre . . 5.2.1 Slection gnralise . . . . . . . 5.2.2 Requtes conjonctives . . . . . . . 5.2.3 Requtes avec l et m . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 57 57 58 59 60 60 61 61 62 63 64

5.2

5.3

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)

56 nomStation Venusa Farniente Santalba Passac capacit 350 200 150 400

CHAPITRE 5. LALGBRE RELATIONNELLE


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

NomStation Libell Venusa Voile Venusa Plonge Farniente Plonge Passac Ski Passac Piscine Santalba Kayac La table Activit

F IG . 5.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 . 5.2 Les clients et leurs sjours

5.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.

5.1. LES OPRATEURS DE LALGBRE RELATIONNELLE

57

5.1.1

La slection, o

La slection yp  sapplique une relation, critre de slection, q . Ce critre peut tre :

, et extrait de cette relation les tuples qui satisfont un

La comparaison entre un attribut de la relation, ri , o r appartient %!s06gt05tt05ht06uE8 .




, et une constante i . Cette comparaison scrit avec les mmes oprateurs de

La comparaison entre deux attributs comparaison que prcdemment.

E(

et

C2

, qui scrit

E(5rG2

Premier exemple : exprimer la requte qui donne toutes les stations aux Antilles.
Bv1wyx I{zA73|~}{ab7!I w }1HhiUhyQyx'Y

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.

5.1.2

La projection,

La projection Ba ab a~X sapplique une relation , et ne garde que les attributs ('01G2U0546454P . Donc, contrairement la slection, on ne supprime pas des lignes mais des colonnes. Exemple : donner le nom des stations, et leur rgion.
97)zAUWI{zA7X v1wyx I{zA7HhiUhyQyx'Y

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 :
v1wyx I{zA7 HhiUhyQyx'Y

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.

58

CHAPITRE 5. LALGBRE RELATIONNELLE

5.1.3

Le produit cartsien,

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 y D ( 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 01e010Ae et prsente donc des ambiguits, avec les colonnes  et e 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 F` 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. 5.3. On lve lambiguit sur les attributs nomStation qui apparaissent deux fois. Ce nest pas ncessaire pour les autres attributs.

5.1. LES OPRATEURS DE LALGBRE RELATIONNELLE


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

59 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

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

F IG . 5.3 Produit cartsien Station

Activit, avec leve des ambiguts

Renommage 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 a~t~ ct `C permet ainsi de renommer  en et e en  dans la relation ` . Le produit cartsien
FXa~t~ ctt`C

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 T et V 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

5.1.4

Lunion,

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.

60

CHAPITRE 5. LALGBRE RELATIONNELLE

Lunion des relations H0Ae et 0A donnes en exemple ci-dessus est donc interdite (on ne saurait pas comment nommer les attributs dans le rsultat). En revanche, en posant ~s ptap Rtc H , il devient possible de calculer , avec le rsultat suivant : A a x c u B b y d v

Comme pour la projection, il faut penser viter les doublons. Donc le tuple (x,y) qui existe la fois dans et dans ne gure quune seule fois dans le rsultat.

5.1.5

La diffrence,

Comme lunion, la diffrence sapplique deux relations qui ont le mme schma. Lexpression a alors pour rsultat tous les tuples de qui ne sont pas dans . Voici la diffrence de et , les deux relations tant dnies comme prcdemment. 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.

5.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. 5.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 :
X 7)zPUWI{zP7)|~ap 7)zAUWI{zA7bHhihyQyx'YS$GdghyQQh!

Et on obtient le rsultat de la Fig. 5.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 rsultat sont relatives une seule station). Cette opration est une jointure, que lon peut directement, et simplement, noter :
hihyQyx'Y$7)zA)IzA73|~7)zAUWIzA7GdhyQQh

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.

5.2. EXPRESSION DE REQUTES AVEC LALGBRE


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 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

61

F IG . 5.4 Une jointure

7UzPUWI{zP73|ap 7)zPUWI{zP7bhihyQyx'YGdhyQQh'

, composition de

Une jointure p peut simplement tre dnie comme tant quivalent yp  . Le critre de rapprochement, q , peut tre nimporte quelle opration de comparaison liant un attribut de un attribut de . En pratique, on emploie peu les s ou g 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.

5.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.

5.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 :
By1551fP1fB1{P)~{b!yWHUyy'A

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.
9yA6gW9AAX1yW{A3 b! y'

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.
y1551fP1 Hyy'bF WA3~b! yy'

Ce qui permet de sautoriser la syntaxe suivante, o le dnote le ou logique.


yA6gW9AAX1yW{A3 b! y'

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.

62

CHAPITRE 5. LALGBRE RELATIONNELLE

9yA6gW9AAXHyy'pyWA3

b! yy'

Cette requte est quivalente une slection o on sautorise loprateur :


9yA6gW9AAX1yW{AB b! y'

En rsum, les oprateurs dunion et de diffrence permettent de dnir une slection B 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).

5.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. 1. Nom des stations aux Antilles :
)PUW{PyW{P3b3yWHyy'P

2. Nom des stations o lon pratique la voile. 3. Nom et prnom des clients europens

)A)A~y{yy~pAyAHGy'A

)PC 5Wy)A

WA3

{ W6 AHE@bPA

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.
)PUW{Pf 1{PHyy'UPUW{P3)PUW{Py P CyU!P

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 :
)A Ey@b {W~{W~{y! )AUWA3 gPg 'B3P

5.2. EXPRESSION DE REQUTES AVEC LALGBRE


Quelles rgions a visit le client 30 :
WA~BW{y!~AfH'B3RyWA3~UPUW{P$HUyy'A

63

Nom des clients qui ont eu loccasion de faire de la voile :


UP HE@b WW! 'Bt W{P3)PUW{P y~HA HGy!AP

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 :

)PC {y! W{P

Ey@b

{W~{W~{y!XWA3~W{P

'Bt

W{P3)PUW{P

Uyy'A

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.

5.2.3

Requtes avec et

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 ?
)PUW{Pbyy' )AUW{Aby pA CyU!P

Comme le suggre cet exemple, la dmarche gnrale pour construire une requte du type Tous les qui ne satisfont pas la proprit est la suivante : 1. Construire une premire requte qui slectionne tous les . 2. Construire une deuxime requte 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.
W{P Ey@bPp 1yW{A HUyy'

qui slectionne tous les

qui satisfont .

Nom des stations qui nont pas reu de client amricain.


)AUWAbHUyy'p AU'9E{W~y3~CyW{P3 by1{ HEy@bPP

64 Id des clients qui ne sont pas alls aux Antilles.


{W~{y!6HEy@bP W{y!5HyWA3

CHAPITRE 5. LALGBRE RELATIONNELLE

b! yy')PUW{P)W{P'9!

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 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 .
{ HEy6bP UPUW{P yy'Pp {W~{y! A U'93

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 :
UPUW{P yy'p )PUW{P  51)b1 HGy!A

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 :

{XHE@bP

{XP

XEy@bP

)AUW{AbHyy'P

{W~y3 W{PH'B3A

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.

5.3

Exercices

Exercice 5.1 La gure 5.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. 1.
)AC Wg't@36'b~!

5.3. EXERCICES
2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
)A1U$@fg! )A1C )ABWX9 6y1@{WbPPH)9@PA )Ay 6!  )PW Wgg f3)bA1gP1b HEggU9UbPA

65

)A1C )ABWXB)AB15yWg)H6UB'PP

)AyW! 6yW@{ UFF@bG

)AW~UPW

UB'P

)Ay 6! 3Uyb1Ag1 6yW@{)HUB'UPW)PWX)PBW5~)ABWEgBbP 511'y{A U$@fgG )AyW!~UP t@3@'b~!

)AyW!UFF@bG)AyW!)Ppy 63X)PW~)AWdEgBbP 6yW6{{3B)Apy 5g! g' EgBbPR)AW~UPWXUPBW5~)ABWC)9@P

)A1C )ABWXR)9U'P )A1U$@fg!~ )A1 

)PWC )PBWHEggU9UbP  HEgBbPA

UPWHy)Ay 6! EgBbPP

)Ppy 63A 

Quelle est la diffrence entre les deux dernires requtes ? Exercice 5.2 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 . 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 ?

66 nomImm Koudalou Barabas adresse 3 Rue Blanche 2 Allee Nikos nomImm Koudalou Koudalou Koudalou Koudalou Barabas Barabas

CHAPITRE 5. LALGBRE RELATIONNELLE


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 nomGrant Doug Ross

nom ge profession Ross 51 Informaticien 34 Cadre Alice 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 . 5.5 Les immeubles et leurs occupants 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 5.3 1. Montrez que la requte 4 dans lexercice 5.1 peut sexprimer avec lunion.

2. Inversement, donner une requte sur la base Immeuble qui peut sexprimer avec lunion, mais pas avec et . 3. Exprimez la dernire requte de lexercice 5.1 avec la diffrence, et sans .

67

Chapitre 6

Le langage SQL
Sommaire
6.1 Requtes simples SQL . . . . . . . . . . 6.1.1 Slections simples . . . . . . . . . 6.1.2 La clause WHERE . . . . . . . . . 6.1.3 Valeurs nulles . . . . . . . . . . . Requtes sur plusieurs tables . . . . . . 6.2.1 Jointures . . . . . . . . . . . . . . 6.2.2 Union, intersection et diffrence . Requtes imbriques . . . . . . . . . . . 6.3.1 Conditions portant sur des relations 6.3.2 Sous-requtes correlles . . . . . . Agrgration . . . . . . . . . . . . . . . . 6.4.1 Fonctions dagrgation . . . . . . 6.4.2 La clause GROUP BY . . . . . . . 6.4.3 La clause HAVING . . . . . . . . Mises--jour . . . . . . . . . . . . . . . 6.5.1 Insertion . . . . . . . . . . . . . . 6.5.2 Destruction . . . . . . . . . . . . 6.5.3 Modication . . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 68 70 71 72 72 73 74 74 76 76 76 77 78 78 78 78 79 79

6.2

6.3

6.4

6.5

6.6

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 8.

68

CHAPITRE 6. LE LANGAGE SQL

6.1

Requtes simples SQL

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

6.1.1

Slections simples

Commenons par les requtes les plus simples : la gure 5.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, souschanes, 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
1. Attention, ce nest pas forcment ainsi que la requte est excute par le systme.

6.1. REQUTES SIMPLES SQL


Ce qui donne le rsultat : libelle Kayac prix / 6.56 7.62 Cours de leuro = Cours de leuro = 6.56 6.56

69

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

70

CHAPITRE 6. LE LANGAGE SQL

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

6.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_____

6.1. REQUTES SIMPLES SQL


Dates

71

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 aaaamm-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.

6.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  = F"#$f


%&

3. NOT  =

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

idClient 10 20 30

nbPlaces 2 3

La prsence de NULL peut avoir des effets surprenants. Par exemple la requte suivante SELECT station FROM Sejour WHERE nbPlaces <= 10 OR nbPlaces >= 10

72

CHAPITRE 6. LE LANGAGE SQL

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.

6.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.

6.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.

6.2. REQUTES SUR PLUSIEURS TABLES

73

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.

6.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.

74 Trois exemples sufront pour illustrer ces oprations. 1. Donnez tous les noms de rgion dans la base. SELECT region FROM Station UNION SELECT region FROM Client

CHAPITRE 6. LE LANGAGE SQL

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.

6.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

6.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 station

6.3. REQUTES IMBRIQUES


FROM WHERE Sejour idClient IN (SELECT id FROM Client WHERE ville = Paris)

75

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 ' construite avec une requte imbrique. 1. EXISTS R. Renvoie TRUE si ' nest pas vide, FALSE sinon. 2.

IN R o est un tuple dont le type est celui de ' . TRUE si appartient ' , FALSE sinon.


3. 4.

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. ALL R, o est un comparateur SQL (  ,  , , etc.). Renvoie TRUE si la comparaison avec tous les 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.

76

CHAPITRE 6. LE LANGAGE SQL

6.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.

6.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.

6.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.

6.4. AGRGRATION
4. SUM qui effectue le cumul. Exemple dutilisation de ces fonctions : SELECT COUNT(nomStation), AVG(tarif), MIN(tarif), MAX(tarif) FROM Station

77

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

6.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 ?

78

CHAPITRE 6. LE LANGAGE SQL

6.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.

6.5

Mises--jour

Les commandes de mise--jour (insertion, destruction, modication) sont considrablement plus simples que les requtes.

6.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.

6.5.2

Destruction

La destruction seffectue avec la clause DELETE dont la syntaxe est : DELETE FROM R WHERE condition

6.6. EXERCICES

79

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 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%

6.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.

6.6

Exercices

Exercice 6.1 Reprendre les expressions algbriques du premier exercice du chapitre algbre, et les exprimer en SQL. Exercice 6.2 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 ?

80 11. Combien de sjours ont eu lieu Passac ?

CHAPITRE 6. LE LANGAGE SQL

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.
()$0

Les clients qui sont alls dans toutes les stations.

Exercice 6.3 (Valeurs nulles) On considre la table suivante : NomStation Gratuite NullePart Capacit 80 150 STATION Lieu Guadeloupe Rgion Antilles Tarif 2000

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 6.4 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
1

(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.

81

Chapitre 7

Schmas relationnels
Sommaire
7.1 Schmas . . . . . . . . . . . . . . . . . . 7.1.1 Dnition dun schma . . . . . . 7.1.2 Utilisateurs . . . . . . . . . . . . Contraintes et assertions . . . . . . . . . Vues . . . . . . . . . . . . . . . . . . . . 7.3.1 Cration et interrogation dune vue 7.3.2 Mise jour dune vue . . . . . . . Triggers . . . . . . . . . . . . . . . . . . 7.4.1 Principes des triggers . . . . . . . 7.4.2 Syntaxe . . . . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 82 82 83 85 85 86 87 87 88 89

7.2 7.3

7.4

7.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 2 2 Ofciel des spectacles 3 3 et le schma 2 2 Agence de voyage 3 3 . En toute rigueur il faudrait donc distinguer 2 2 linstance de schma 3 3 de la 2 2 base de donnes 3 3 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 ( 2 2 reexes 3 3 ) 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 2 2 Ofciel 3 3 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)

82

CHAPITRE 7. SCHMAS RELATIONNELS

7.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.

7.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 2 2 Agence de voyage 3 3 . 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.

7.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 lui-mme cr. Ces droits concernent aussi bien la manipulation des donnes que la modication ou la destruction des lments du schma.

7.2. CONTRAINTES ET ASSERTIONS

83

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. 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

7.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 4. 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)

84

CHAPITRE 7. SCHMAS RELATIONNELS

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. 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,

7.3. VUES
capacite INTEGER, climatisee CHAR(1), PRIMARY KEY (nomCinema, no), FOREIGN KEY nomCinema REFERENCES Cinema, CHECK (capacit  (SELECT Max(capacite) FROM Salle WHERE nomCinema = Rex)))

85

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

7.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.

7.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 2 2 contient 3 3 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

86

CHAPITRE 7. SCHMAS RELATIONNELS

Enn un des intrts des vues est de donner une reprsentation 2 2 dnormalise 3 3 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

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 2 2 Quels acteurs ont tourn un lm en 1997 3 3 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

7.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

7.4. TRIGGERS

87

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

7.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).

7.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.

88

CHAPITRE 7. SCHMAS RELATIONNELS

7.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

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.
1. Tous les exemples qui suivent utilisent la syntaxe des triggers Oracle, trs proche de celle de SQL3.

7.5. EXERCICES

89

7.5

Exercices

Exercice 7.1 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} Exercice 7.2 On veut crer un ensemble de vues sur la base 2 2 Agence de voyages 3 3 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 7.3 Une vue sur une table ' qui ne comprend pas la cl primaire de ' est-elle modiable ? Exercice 7.4 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.

90

CHAPITRE 7. SCHMAS RELATIONNELS


2. Donnez le trigger qui alimente la table AuditSance en fonction des mises jour sur la table Sance.

Exercice 7.5 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.

91

Chapitre 8

Programmation avec SQL


Sommaire
8.1 Interfaage avec le langage C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 8.1.2 8.1.3 8.2 8.2.1 8.2.2 8.2.3 Un exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dveloppement en C/SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . Autres commandes SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principes de JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le plus simple des programmes JDBC . . . . . . . . . . . . . . . . . . . . . . 91 91 94 96 97 97 99

Linterface Java/JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exemple dune applet avec JDBC . . . . . . . . . . . . . . . . . . . . . . . . . 100

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.

8.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.

8.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));

92

CHAPITRE 8. PROGRAMMATION AVEC SQL

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> 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

8.1. INTERFAAGE AVEC LE LANGAGE C


manipul par le programme et le type SQL correspondant. Cela se fait en deux tapes :

93

(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. 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)

94 {

CHAPITRE 8. PROGRAMMATION AVEC SQL

printf ("Film no %d. Titre : %s Annee : %d Id mes %d \n", ora_id_film, ora_titre, ora_annee, ora_id_mes); EXEC SQL FETCH CFILM INTO :ora_id_film:vi1, :ora_titre:vi2, :ora_annee:vi3, :ora_id_mes:vi4; } EXEC SQL CLOSE CFILM; /* Comme avant ... */ On dclare un curseur ds quun ordre SQL ramne potentiellement plusieurs n-uplets. Ensuite chaque appel la clause FETCH accde un n-uplet, jusqu ce que sqlca.sqlcode soit gal 1403 (ici on a dclar une constante ORA_NOTFOUND). Comme dhabitude, il est recommand dorganiser le code avec des fonctions. Dune manire gnrale, il parat prfrable de bien sparer le code grant les accs la base du code implantant lapplication proprement dite. Quelques suggestions sont donnes dans la section suivante.

8.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; ...

8.1. INTERFAAGE AVEC LE LANGAGE C


/* 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 */

95

*/

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

*/

96 EXEC SQL FETCH ...

CHAPITRE 8. PROGRAMMATION AVEC SQL

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)) { .... } 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.

8.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;

8.2. LINTERFACE JAVA/JDBC


Valeurs nulles

97

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 */ ...

8.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/or

8.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. La gure 8.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. Connexion 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

98

CHAPITRE 8. PROGRAMMATION AVEC SQL

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 . 8.1 Mise en uvre des drivers JDBC

le cas o on souhaite accder plusieurs bases de donnes, comme montr sur la gure 8.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 cidessous et le driver 2 2 thin 3 3 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.

8.2. LINTERFACE JAVA/JDBC

99

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.

8.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 ; // 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
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.

100

CHAPITRE 8. PROGRAMMATION AVEC SQL


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. 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.

8.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>

8.2. LINTERFACE JAVA/JDBC

101

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);

102

CHAPITRE 8. PROGRAMMATION AVEC SQL


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()); //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); nom"

8.2. LINTERFACE JAVA/JDBC


// 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"); 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; } }

103

104

CHAPITRE 8. PROGRAMMATION AVEC SQL

105

Deuxime partie

Aspects systmes

107

Chapitre 9

Techniques de stockage
Sommaire
9.1 Stockage de donnes . . . . . . . . 9.1.1 Supports . . . . . . . . . . . 9.1.2 Fonctionnement dun disque 9.1.3 Optimisations . . . . . . . . 9.1.4 Technologie RAID . . . . . Fichiers . . . . . . . . . . . . . . . 9.2.1 Enregistrements . . . . . . . 9.2.2 Blocs . . . . . . . . . . . . 9.2.3 Organisation dun chier . . Oracle . . . . . . . . . . . . . . . . 9.3.1 Fichiers et blocs . . . . . . . 9.3.2 Les tablespaces . . . . . . . 9.3.3 Cration des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 108 109 111 114 117 117 119 122 125 126 129 132

9.2

9.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 ( 4 4 disque dur 5 5 ) 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.

108

CHAPITRE 9. TECHNIQUES DE STOCKAGE

9.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.

9.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 9.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 . 9.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 9.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

9.1. STOCKAGE DE DONNES


Type mmoire Mmoire cache Mmoire principale Mmoire secondaire (disque) Mmoire tertiaire (bande/CD) Taille (en Mo) Env. 1 Mo EGF7H9PI@Q Mo EGF7H9WV I Q (Gygaoctets) EGF7H9 VYX Q (Traoctets) Temps daccs (secondes) 687@9BADC (10 nanosec.) 687@9BADCRS7@9BAUT (10-100 nanosec.) 687@9 ADI (10 millisec.) 6 1 seconde

109

TAB . 9.1 Caractristiques des diffrentes mmoires lordre de 10 nanosecondes ( 7H9BADC ) tandis que le temps daccs sur un disque est de lordre de 10 millisecondes ( 7H9 AUI ), 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.

9.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 ( 4 4 simple face 5 5 ) ou des deux cts ( 4 4 simple face 5 5 ) 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 512K. 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 512K). 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 512K (un secteur), 1024K (deux secteurs) ou 4096K (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 . 9.2 Un disque magntique

110

CHAPITRE 9. TECHNIQUES DE STOCKAGE

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. 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 9.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 9.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 9.2 appartient au mileu de gamme. Le disque comprend 17 783 secteurs de 512K 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 7a`b`dcfehgPefcWidprq sut t pfe 9fp secteurs par surface.

9.1. STOCKAGE DE DONNES


Caractristique Capacit Taux de transfert Cache Nbre de disques Nbre de ttes Nombre total secteurs (512K) 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

111

TAB . 9.2 Spcications du disque Cheetah 18LP (source www.seagate.com) 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 sht t t s calculer le nombre moyen de secteurs par piste, qui est gal pfe 9fpWi `P` qvef9fe . On peut donc s sftPs estimer quune piste stocke en moyenne ef9Pexwy7 q87ayfy 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. 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 9.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 :
pfwc ef9fe q9H7Hp

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.

9.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.

112 Regroupement

CHAPITRE 9. TECHNIQUES DE STOCKAGE

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 9.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.

(a)

(b)

F IG . 9.3 Mauvaise et bonne organisation sur un disque

La lecture dans le premier cas implique 5 dplacements des ttes de lecture, et 5 dlais de latence ce s e"Qhqg7 ms. Dans le second cas, on aura un dplacement, et un dlai de qui donne un temps de ywFy latence pour la lecture du premier bloc, mais le bloc suivant pourra tre lu instantanment, pour un temps total de 8,2 ms. 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 imporI V tant que les donnes sont 4 4 proches 5 5 , sur le disque, cette proximit tant dnie comme suit, par ordre dcroissant : la proximit maximale est obtenue quand lues ensembles ;
V

et
I

sont dans le mme bloc : elles seront alors toujours

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.

9.1. STOCKAGE DE DONNES

113

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 d demande la lecture du chier e tandis que lutilisateur f demande la lecture du chier e , le systme alternera I V probablement les lectures des 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.
Mmoire tampon L(116), L(223), L(118), L(224), L(117) L(117) L(223) L(118) L(224) L(116)

Contrleur disque

L(116), L(117), L(118), L(223), L(224) Squenceur

F IG . 9.4 Squencement des entres/sorties

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 9.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 4 4 de lascenseur 5 5 . 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 consomateurs de donnes. Le processus qui

114

CHAPITRE 9. TECHNIQUES DE STOCKAGE

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.
Gestionnaire de mmoire cache Table de hachage Lecture disque Demande de bloc Mmoire centrale

blocs

F IG . 9.5 Mmoire cache

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 les blocs de la relation, y compris ceux qui ne serviront que dans quelques temps et peuvent tre placs dans un buffer en attendant.

9.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

9.1. STOCKAGE DE DONNES

115

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 4 4 disque miroir 5 5 ). 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 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 4 4 intelligente 5 5 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) 7 disques ont la mme taille et la mme structure (taille de blocs, des disques. On suppose que les 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 9.1 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 g de 1 dans la colonne. La valeur du bit s s de parit est grhd . Pour la premire colonne on a giq , et le bit de parit vaut 0. Voici le premier octet du disque de contrle. DC: 01101001

116

CHAPITRE 9. TECHNIQUES DE STOCKAGE

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 Rj7 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 Rj7 autres disques, de recalculer la parit et de mettre jour le disque de contrle. 7 entres/sorties. Cette solution est tout fait inefcace puisquelle ncessite 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 9.2 Reprenons lexemple prcdent, avec trois disques D1, D2, D3, et le disque de contrle DC. D1: 11110000 D2: 10101010 D3: 00110011 DC: 01101001 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
k

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

9.2. FICHIERS

117

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 7 disques. La seule modication apporter par rapport au RAID 5 est de savoir, quand on modie un bloc sur un disque l , quel est le disque l qui contient les donnes de parit pour ce bloc. Il est possible I V par exemple de dcider que pour le bloc m , cest le disque mPhdh 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.

9.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 ; 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.

9.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 4 4 entits 5 5 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 9.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.

118 Type SMALLINT INTEGER BIGINT FLOAT DOUBLE PRECISION NUMERIC (M, D ) DECIMAL (M, D ) CHAR(M ) VARCHAR(M ) BIT VARYING DATE TIME DATETIME

CHAPITRE 9. TECHNIQUES DE STOCKAGE


Taille en octets 2 4 8 4 8 M, (D +2 si M n D ) M, (D +2 si M n D ) M L+1 avec L o M
n s C

8 6 14

TAB . 9.3 Types SQL et tailles (en octets) 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 9.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. 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 7 , 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 ; le champ est de longueur p dconomiser de lespace.
7

, avec

pbnq

; ici on ne stocke pas les octets inutiliss, ce qui permet

9.2. FICHIERS

119

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 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 9.3 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 9.6 montre cet enregistrement : notez quen lisant len-tte, on sait calculer ladresse de lenregistrement suivant.
k

9.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 r pour un bloc de taille f est donn par sfxitvu o la notation sxwu dsigne le plus grand entier infrieur w .

120
entte id titre

CHAPITRE 9. TECHNIQUES DE STOCKAGE

12 110 1237 v e r t i go pointeur

F IG . 9.6 Exemple dun enregistrement avec en-tte

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 szy|{|}|~ A V {|{ uqqgB` enregistrements dans un tft C y bloc. Notons quil reste dans chaque bloc e pRFgB`wcfg"QuqgPc octets inutiliss dans chaque bloc.
Blocs 12

...
Fichier F1 Enregistrements Entte bloc

...
46

F IG . 9.7 Fichier avec blocs et enregistrements

Le transfert en mmoire de lenregistrement 563 de ce chier est simplement effectu en dterminant s 7q7 ), en chargeant le douzime bloc en mmoire centrale et dans quel bloc il se trouve (soit s#ypPe"idgW`@u 7q en prenant dans ce bloc lenregistrement. Le premier enregistrement du bloc 12 a le numro 7f7wxgW` s yB7d` , et le dernier enregistrement le numro 7 wgW`q8yfpg . Lenregistrement 563 est donc lavant-dernier du bloc, avec pour numro interne le 46 (voir gure 9.7). 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 9.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. 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

9.2. FICHIERS
F1 12

121

...
Adresse Adresse logique physique #90887 F1.12.46

46

...

F IG . 9.8 Adressage avec indirection

revanche 46 est une identication logique de lenregistrement, gre au sein du bloc. La gure 9.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.
En-tte Espace libre Bloc F1.12 46 57

16

indirection

Enregistrements

F IG . 9.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. 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 9.10 : 1. on insre dans la table Film un lm 4 4 Marnie 5 5 , sans rsum ; lenregistrement correspondant est stock dans le bloc F1.12, et prend le numro 46 ;

122
Bloc F1.12 16 46 57 16

CHAPITRE 9. TECHNIQUES DE STOCKAGE


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 . 9.10 Mises jour dun enregistrement de taille variable

2. on insre un autre lm, stock lemplacement 47 du bloc F1.12 ; 3. on saperoit alors que le titre exact est 4 4 Pas de printemps pour Marnie 5 5 , 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. 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.

9.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.

9.2. FICHIERS
Quest-ce quune organisation de chier ?

123

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 p 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 sous-linaire : 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. 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.

124

CHAPITRE 9. TECHNIQUES DE STOCKAGE

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. I 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 I I gnralement ltape . I Au pire, la recherche se termine quand il ny a plus quun seul bloc explorer, autrement dit quand sP sP est tel que n . On en dduit le nombre maximal dtapes : cest le plus petit tel que qn , soit p#h@ F$Qn , soit qp#h@ F$Q . I I Pour un chier de 100 Mo, un parcours squentiel implique la lecture des 25 000 blocs, alors quune s recherche par dichotomie ne demande que #p#h@ F y9P9f9"Qq7ay lectures de blocs !! Le gain est considI rable. 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. Mises jour 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.

9.3. ORACLE

125

La premire est une liste doublement chane des blocs libres (voir gure 9.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 9.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 . 9.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 9.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 . 9.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.

9.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 4 4 reprsentation physique 5 5 et 4 4 reprsentation logique 5 5 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. 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 pa-

126

CHAPITRE 9. TECHNIQUES DE STOCKAGE

ramtrable 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.

9.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 En-tte (adresse du bloc, type dusegment) Tables reprsentes dans le bloc Adresses des enregistrements Espace libre Enregistrements

F IG . 9.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 9.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 ;

9.3. ORACLE

127

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). enn lespace des donnes contient les enregistrements. 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 9.3, page 118. Par exemple les donnes de type CHAR(n) sont stockes dans un tableau doctets 7 . Le premier octet indique la taille de la chane, qui doit donc tre comprise entre 1 et 255. de longueur 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

128

CHAPITRE 9. TECHNIQUES DE STOCKAGE

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. 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.

9.3. ORACLE

129

9.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. 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 4 4 par dfaut 5 5 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 ;

130 3. le nombre maximal dextensions, ici 20 ;

CHAPITRE 9. TECHNIQUES DE STOCKAGE

4. enn chaque nouvelle extension est 20% plus grande que la prcdente. En supposant que la taille dun bloc est 4K, on obtient une premire extension de 25 blocs, une seconde s s de 10 blocs, une troisime de 7H9Gw&7f q7 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 4 4 auto-extension 5 5 , 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

9.3. ORACLE

131

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. Comment inspecter les tablespaces 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,

132 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

CHAPITRE 9. TECHNIQUES DE STOCKAGE

MAXIMUM ------2928

MINIMUM ------115

AVERAGE ------1521.5

SUM -----3043

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.

9.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.

133

Chapitre 10

Indexation
Sommaire
10.1 Indexation de chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 10.1.1 Index non-dense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.1.2 Index dense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 10.1.3 Index multi-niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 10.2 Larbre-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 10.2.1 Prsentation intuitive . . . . 10.2.2 Recherches avec un arbre-B+ 10.3 Hachage . . . . . . . . . . . . . . . 10.3.1 Principes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 141 143 143

10.3.2 Hachage extensible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 10.4 Les index bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 10.5 Indexation dans Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 10.5.1 Arbres B+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 10.5.2 Arbres B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 10.5.3 Indexation de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 10.5.4 Tables de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 10.5.5 Index bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

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 4 4 B 5 5 vient

134 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 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

CHAPITRE 10. INDEXATION

TAB . 10.1 La table indexer 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. 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 10.1 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 10.1. Nous ne donnons que les deux k attributs titre et anne qui seront utiliss pour lindexation. Exemple 10.2 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 ( Y7H9f9P9f9P9f9"iegf ) 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 octets que nous allons construire k nos index.

10.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.

10.1. INDEXATION DE FICHIERS

135

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.

10.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 9, 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 10.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. la liste ordonne des cls dans lindex, il est facile de constater quun Si on dsigne par @ H I V enregistrement dont la valeur de cl est est stock dans le bloc associ la cl telle que onj . V Supposons que lon recherche le lm Shining. En consultant lindex on constate que ce titre est compris

136

CHAPITRE 10. INDEXATION

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 . 10.1 Un index non dense

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). 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.3 Considrons lexemple 10.2 de notre chier contenant un million de lms (voir page 134). Il est constitu de 29 142 blocs. Supposons quun titre de lms occupe 20 octets en moyenne, et ladresse sft sb s t F 9 cPQqc7ay `p octets, comparer aux 120 Mo dun bloc 8 octets. La taille de lindex est donc 7g k 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 10.4 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 10.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.
k

10.1. INDEXATION DE FICHIERS

137

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 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.

10.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 10.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 . 10.2 Un index dense

Exemple 10.5 Considrons lexemple 10.2 de notre chier contenant un million de lms (voir page 134). Il faut crer une entre dindex pour chaque lm. Une anne occupe 4 octets, et ladresse dun bloc 8 octets. s La taille de lindex est donc 7H9f9P9f9P9f9 F#g cPQhq7 9f9P9r9f9P9 octets, soit seulement dix fois moins que les k 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

138

CHAPITRE 10. INDEXATION

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 entres correspondant au critre de recherche. Par exemple, pour rechercher tous les lms parus en 1992 dans lindex de la gure 10.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. Exemple 10.6 Voici lalgorithme qui recherche tous les lms parus dans lintervalle
7 t y97 t ` t

1. on recherche dans lindex la premire valeur comprise dans lintervalle : pour lindex de la gure 10.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).
k

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.

10.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 10.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.

10.2. LARBRE-B
Annie Hall Brazil Casablanca Easy Rider Greystoke Jurassic Park Impitoyable Manhattan 1977 ...... 1984 ... 1942 ... 1969 ... 1984 1992 1992 1979 ... ... ... ... ... ... ... ... ... ... ... ...

139

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 . 10.3 Index multi-niveaux

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 10.7 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 k la valeur 1990 (il pourrait y en avoir plusieurs). Il reste accder lenregistrement. 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.

10.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+ .

140

CHAPITRE 10. INDEXATION

10.2.1

Prsentation intuitive

La gure 10.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.
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 . 10.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 10.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 10.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 10.5 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

10.2. LARBRE-B

141

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.
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 . 10.5 Le chier des lms, avec un index unique.

10.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 10.4, cela implique de lire inutilement 13 lms avant de trouver Impitoyable qui est en quatorzime position. Lindex permet de trouver lenregistrement beaucoup plus rapidement. 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.

142

CHAPITRE 10. INDEXATION

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 10.8 Reprenons lexemple 10.2 de notre chier contenant un million de lms. Une entre dindex | HP entres (au maximum) dans un bloc. Il faut HY||| occupe 28 octets. On place donc z| Y h" blocs pour le premier niveau de larbre-B+. deuxime niveau comprend 6 850 entres, une pour chaque bloc du premier niveau. Il faut donc |Le W blocs. Finalement, un troisime niveau, constitu dun bloc avec 47 entres suft pour com plter 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 ; 2. avec deux niveaux on indexe 146 blocs de 146 lms chacun, soit 3. avec trois niveaux on indexe
"frf@Hf P $@

lms ;

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 f lms dans un bloc, et un index avec trois niveaux permettrait dindexer fbPB!PB 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 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 10.5) 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 10.5. 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.
1. Pour tre plus prcis le calcul qui suit devrait tenir compte du fait quun bloc nest pas toujours plein.

10.3. HACHAGE

143

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 10.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 .

10.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.

10.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.

144 Exemple dune table de hachage

CHAPITRE 10. INDEXATION

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.
Jurassic Park 1992 Twin Peaks 1990 Easy Rider 1969 Annie Hall 1977 Underground 1995 Psychose 1960

blocs entres

0 1 2 3 4 Rpertoire Manhattan 1979 Metropolis 1926 Casablanca 1942 Reservoir Dogs 1992 Brazil 1984 Vertigo 1958 Greystoke 1984

Impitoyable 1992 Shining 1980 Smoke 1995

F IG . 10.6 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 :
!dd d"Dd" d Wd

La gure 10.6 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

10.3. HACHAGE

145

et Underground. les lettres , , , 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 10.6 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 9 consacre aux techniques dadressage de blocs (voir section 9.2.2, page 119). 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 ci-dessus), 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 larbreB 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.

146 Mises jour

CHAPITRE 10. INDEXATION

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 10.7. 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.
Jurassic Park 1992 Twin Peaks 1990 Easy Rider 1969 Annie Hall 1977 Underground 1995 Psychose 1960

0 1 2 3 4 Rpertoire Manhattan 1979 Metropolis 1926 Casablanca 1942 Reservoir Dogs 1992 Citizen Kane 1941 Brazil 1984 Vertigo 1958 Greystoke 1984

Impitoyable 1992 Shining 1980 Smoke 1995

F IG . 10.7 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.

10.3. HACHAGE
titre Vertigo Brazil Twin Peaks Underground Easy Rider Psychose Greystoke Shining
(titre) 01110010 10100101 11001011 01001001 00100110 01110011 10111001 11010011

147

TAB . 10.2 Valeurs du hachage extensible pour les titres 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 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.

10.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 10.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 10.8 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 . 10.8 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

148

CHAPITRE 10. INDEXATION

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 10.9) :
Easy Rider

00 01 10 11

Vertigo Underground Psychose

Brazil Twin Peaks

F IG . 10.9 Doublement du rpertoire dans le hachage extensible

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 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 10.10.

10.4

Les index bitmap

Un index bitmaprepose 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 a pour valeur dans la ligne ; sinon le bit est 0.

10.4. LES INDEX BITMAP


Easy Rider

149

00 01 10 11

Vertigo Underground Psychose

Brazil Greystoke

Twin Peaks Shining

F IG . 10.10 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

... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

TAB . 10.3 Les lms et leur genre

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 10.9 Reprenons lexemple de nos 16 lms, et crons un index sur le genre (voir le table 10.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 bitmapest 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-

150 Fiction et Comdie . Chaque colonne correspond lun des lms. Drame Science-Fiction Comdie 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

CHAPITRE 10. INDEXATION

12 0 0 1

13 0 0 0

14 0 0 0

15 1 0 0

16 0 0 1

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 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 !

10.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 (Indexorganized table) ou par une table de hachage (hach cluster).

10.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)

10.5. INDEXATION DANS ORACLE

151

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.

10.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)

10.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.

152

CHAPITRE 10. INDEXATION

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.

10.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. 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. || entres de la table de hachage Pour une taille de bloc de 4 096 octets, Oracle affectera alors | 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.

10.5. INDEXATION DANS ORACLE

153

10.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.

154

CHAPITRE 10. INDEXATION

155

Chapitre 11

valuation de requtes
Sommaire
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 11.2 Evaluation dune requte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 11.2.1 Evaluation de requtes efcace . . . . . . . . . . . . . . . . . . . . . . . . . . 157 11.2.2 Mesure du cot dune opration . . . . . . . . . . . . . . . . . . . . . . . . . . 157 11.2.3 Techniques daccs et prtraitement . . . . . . . . . . . . . . . . . . . . . . . . 158 11.2.4 Le Tri externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 11.2.5 La Slection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 11.2.6 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 11.2.7 Jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 11.3 Compilation dune requte et optimisation . . . . . . . . . . . . . . . . . . . . . . . 173 11.3.1 Traduction de la requte en un plan dexcution logique . . . . . . . . . . . . . 173 11.3.2 Lois algbriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 11.3.3 Amlioration dun plan dexcution logique . . . . . . . . . . . . . . . . . . . 175 11.3.4 Estimation des cots et choix dun plan dexcution physique . . . . . . . . . . 178 11.3.5 Exemple destimation du cot dune opration . . . . . . . . . . . . . . . . . . 182 11.3.6 Choix dun oprateur pour la slection . . . . . . . . . . . . . . . . . . . . . . 182 11.3.7 Stratgies pour le choix dun oprateur pour la jointure . . . . . . . . . . . . . . 183 11.3.8 Pipelinage ou matrialisation des rsultats intermdiaires . . . . . . . . . . . . 183

11.1

Introduction

Lobjectif de ce chapitre est de montrer comment le processeur de requtes rpond une requte SQL. On sappuie sur les techniques dveloppes dans les deux chapitres prcdents et on suppose le lecteur familier avec SQL et lalgbre relationnelle. Le processeur de requte est dcompos en deux couches. La premire appele compilation dune requte traduit une requte SQL en un plan dexcution physique. La deuxime couche appele valuation dune requte excute ce plan dexcution (gure 11.1). La compilation dune requete (section 11.3 ) consiste en trois tapes: 1. Analyse de la requte: le rsultat est un plan dexcution logique initial, reprsentation algbrique de la requte. Linterprtation de ce plan est une squence doprations de lalgbre relationnelle. 2. Rcriture de la requte: le plan initial est transform en un plan quivalent grce des rgles ou lois algbriques, plan qui est cens tre plus efcace que le plan initial.

156

CHAPITRE 11. VALUATION DE REQUTES

3. Gnration dun plan dexcution physique: on slectionne des algorithmes pour implanter chacune des oprations algbriques du plan logique et un ordre dexcution. 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 reprsentant les relations disponibles, cest--dire de lexistence dindex ou de tables de hachage. Enn il dpend aussi des donnes statistiques enregistres ou estimes pour chaque relation (nombre de nuplets, de page dune relation, slectivit dun attribut dans une relation, etc.). Le plan doprations physiques est galement reprsent sous forme darbre. Le plan comprend des dtails tels que comment se fait laccs un chier et si et quand une relation doit tre trie.
Requete SQL Plan dexecution logique

Traduction algebrique Optimisation Evaluation requete

Plan dexecution physique

F IG . 11.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 accdes et gres par le sytme. Le catalogue est galement appel schma physique. On dit quil contient des mta-donnes . Les tapes 2 et 3 forment ce quon appelle loptimisation dune requte. Bien que nous distinguions ces deux tapes pour pdagogiquement mettre en vidence les diffrents types doptimisation, il nest pas clair que ces tapes soient spares dans la sous couche optimisation dun processeur de requte du commerce. Ces diffrentes tapes seront tudies dans la section 11.3. Avant de traiter la compilation dune requte, on tudie en dtail les diffrents algorithmes pour implanter les oprateurs de lalgbre relationnelle.

11.2

Evaluation dune requte

Le rsultat de la compilation dune requte est un plan dexcution (physique), cest--dire une squence doprations excuter. Lvaluation dune requte consiste excuter cette squence doprations: on accde aux chiers, on fait une opration, on stocke ventuellement le rsultat sur un chier temporaire, on lance lopration suivante. On prsente ventuellement le rsultat lutilisateur. Lobjectif de loptimisation est une valuation efcace de la requte initiale. La premire sous-section prcise ce quon entend par efcacit. Mais lessentiel de cette section concerne ltude prcise des algorithmes pour les plus importantes parmi ces oprations physiques. Chaque opration est une implantation particulire dune ou plusieurs oprations de lalgbre relationnelle. Mais dautres oprateurs sont ncessaires comme laccs aux donnes, et en particulier le balayage dune table, cest--dire la lecture en mmoire centrale et le parcours dune relation, nuplet par nuplet. 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 nuplets dupliqus. On verra galement quun algorithme de jointure courant consiste trier sur lattribut de jointure au pralable les relations joindre. Pour tre complet, on devrait tudier comment sont implants tous les oprateurs de lalgbre relationnelle y compris lunion, les fonctions agrgat, etc. On se contentera ici dtudier les algorithmes implantant

11.2. EVALUATION DUNE REQUTE

157

la slection, la projection et la jointure. Limplantation des autres oprations de lalgbre relationnelle utilise des techniques analogues, mais peut aussi utiliser des variantes plus efcaces. On tudiera successivement, (1) les algorithmes pour les oprations unaires, cest--dire la slection et la projection et (2) les algorithmes de jointure. On verra pour chaque algorithme, limpact de la place en mmoire centrale sur lefcacit de lalgorithme. Avant de dmarrer ltude des algorithmes pour la slection, la projection et la jointure, il est ncessaire de rappeler ce quest une valuation de requte performante, nos critres defcacit des algorithmes, de lister les techniques simples que partagent tous ces algorithmes et enn de donner lalgorithme de tri.

11.2.1

Evaluation de requtes efcace

Par valuation efcace, on entend gnralement valuation qui prend un temps le plus court possible. Loptimisation consiste alors trouver le plan qui minimisera le temps pris pour excuter la squence doprations. Cependant tant donn la complexit de loptimisation on 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. De plus nous verrons que le temps dexcution de certaines oprations dpend fortement de la place disponible en mmoire centrale. Celle-ci peut varier et dpendre de critres non maitrisables comme le nombre dutilisateurs. Indpendamment de la place en mmoire, ce nombre dutilisateurs et larchitecture du systme ont un impact non ngligeable sur le temps dvaluation dune requete. En particulier, certains systmes cherchent favoriser le dbit en nombre de transactions au dpens du temps dune requte utilisateur. Enn il est des cas o lefcacit requise concerne larrive du premier rsultat ou temps de rponse, plutt que le temps pour obtenir le rsultat total ou 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.

11.2.2

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 nuplets 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 rajout: il dpend uniquement de la taille du rsultat et non pas de lalgoritme. Dautre part, nous verrons dans la section sur le pipelinage que les rsultats intermdiaires ne sont pas ncessairement rcrits sur disque: chaque nuplet est alors utilis par lopration suivante ds sa production. Dans cette section toutefois, nous supposerons que le rsultat dune opration et toujours crit dans un tampon de sortie et quil faut donc au moins un tampon de sortie pour une opration. Un certain nombre de paramtres sont ncessaires pour lestimation du cot dune opration. Le premier est la mmoire centrale disponible, note et mesure en nombre de pages. M est donc le nombre de tampons en mmoire centrale destins contenir les entres dune opration et les rsultats intermdiaires, chaque tampon ayant la taille dune page. Le nombre de pages quoccupe sur disque une relation en entre dune opration est le deuxime paramtre, not . Le nombre de nuplets dune table est not . Enn on appelle slectivit dun attribut dune table , note v , ou quand il ny a pas dambiguit, le rapport a U  . est linverse du nombre de valeurs diffrentes prises par un attribut dans une table. On dira quun attribut est dautant plus slectif que est petit. Page statique versus volatile Nous verrons que dans certains algorithmes il est possible quune page soit lue plusieurs fois. Si on a assez de tampons en mmoire, on peut alors essayer de conserver dans ces tampons les pages susceptibles

158

CHAPITRE 11. VALUATION DE REQUTES

dtre rutilises ultrieurement. Certains systmes implantent un mcanisme simple bas sur le concepts suivants: page statique: la page reste en mmoire jusqu ce que le processeur de requtes demande au gestionnaire de mmoire de librer la page. page volatile: la page est la disposition du gestionnaire de mmoire.

11.2.3

Techniques daccs et prtraitement

Toute opration a une ou deux tables en entre 1 . La faon dont on accde aux nuplets de ces tables (chemin daccs) a un impact sur lefcacit de lopration. Par ailleurs un prtraitement des tables avant lexcution mme de lopration peut amliorer considrablement les performances de lalgorithme. On regroupe ces techniques daccs et de prtraitement en quatre catgories. 1. Accs squentiel ou itration. Tous les nuplets dune table sont examins lors de lopration, en gnral suivant lordre dans lequel ils sont stocks. 2. Accs par index. Un sous-ensemble de nuplets sont accds en deux tapes. La premire consiste traverser un index pour aller chercher les adresses de un ou plusieurs nuplets. La deuxime tape (accs par adresse) permet daccder aux nuplets connaissant leur adresse. 3. tri. Avant deffectuer lopration on trie la ou les tables. Cette technique est utilise par exemple pour la projection et la jointure. 4. hachage. Avant deffectuer lopration on hache une table. Cette technique est par exemple utilise pour la jointure. Ces techniques seront introduites lors des algorithmes pour chaque opration. Quelques remarques sont ncessaires ds prsent: Nous prenons comme hypothse dans ce chapitre que les index sils existent sont denses et que les tables ne sont pas ordonnes suivant la cl dindex. Ce type dorganisation est souvent appel dans la littrature anglophone non clustered index. On pourrait rajouter une cinquime catgorie, accs une table par son index de hachage. Nous supposons pour simplier que les tables ne sont pas pr-haches. Il nexiste pas dindex de hachage. Cependant le hachage dune table se fait en temps rel lors de lexcution dune opration (quatrime catgorie.) Le tri et le hachage (catgories 3 et 4) sont deux techniques de prtraitement bases sur le partitionnement dune table en fonction de la valeur dune cl en vue de dcomposer une opration en une collection doprations moins chres. Amlioration de lefcacit du parcours squentiel Comme le temps de rponse ou le temps dvaluation est le critre defcacit et que celui-ci dpend du nombre de lectures disque, non seulement on rduit ce nombre, mais on essaie galement de rduire le temps de lecture dune page. Or trs souvent, lorsquun nuplet est lu les nuplets suivants le sont ultrieurement. Le balayage squentiel dune table en est un exemple. Les pages de la relation 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 est moindre que si on lit ces pages une une (voir chapitre 1). Do la ncessit 1. de regrouper les pages dune table dans des espaces contigus appels extensions ou segments, 2. et de faire une lecture lavance: quand on lit une page, on lit galement les pages suivantes dans lextension. Une valeur typique de est 7 ou 15.
1. Pour simplier on parle de table. En fait on devrait parler de la reprsentation physique dune table, cest--dire soit un chier si la table est stocke sur disque, soit toute structure de donnes en mmoire centrale reprsentant un rsultat intermdiaire.

11.2. EVALUATION DUNE REQUTE

159

Par consquent lunit dentre/sortie dun SGBD (un bloc ou page) est souvent un multiple de celle du gestionnaire de chier: la taille dun tampon en mmoire est en gnral un multiple de la taille dun bloc (ou page) physique.

11.2.4

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 Il a deux phases: 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 Supposons que nous disposons pour faire le tri de tampons en mmoire. La relation est lue squentiellement, blocs par blocs. Lorsque les tampons ont t remplis par blocs de la table, les sont tris: ils forment alors une partition qui est crite sur disque. A lissue de nuplets de ces tampons cette phase on a  partitions tries, o est le nombre de blocs de la relation. Phase de fusion La phase de fusion consiste rcursivement fusionner les partitions. A chaque tape on obtient des partitions tries plus grosses jusqu ce qu on obtienne 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: 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 } ecrire a dans T a= lment suivant dans A } sinon { si tampon sortie T plein { vider } ecrire b dans T b= lment suivant dans B } } Algorithme fus: Fusion en mmoire de deux listes tries Par convention, lorsque tous les lments de aprs tous les lments de ( ).

( ) ont t lus, llment suivant est gal eof qui est

2. Ce type dalgorithmes a deux phases. Dans la premire phase on dcompose le problme rcursivement en sous problmes jusqu ce que le sous-problme peut tre rsolu de faon simple. La deuxime phase consiste fusionner rcursivement les solutions.

160 Remarquons que:

CHAPITRE 11. VALUATION DE REQUTES

Lalgorithme fus se gnralise facilement au cas de listes Si on fusionne

>3 tampons, o on fusionne en mme temps


listes de taille 1 page chacune, la liste rsultante a une taille de

pages.

# La premire tape de la phase de fusion de la relation consiste fusionner les partitions tries obtenues aprs la phase de tri, par . On obtient  partitions tries, chacune (sauf la dernire qui est plus petite) ayant pour taille & blocs. Pour ce faire, on commence par lire le premier bloc des premires partitions dans les premiers blocs, on applique lalgorithme fus. Les nuplets tris sont stocks dans une nouvelle partition sur disque. On continue avec les blocs suivants de chaque partition, jusqu ce que les partitions initiales aient t entirement lues et tries 3 . On a alors sur disque une nouvelle partition de taille . On rpte le processus avec les partitions suivantes, etc. La premire phase de la fusion est rsume par lalgorithme ci-dessous en supposant et que la table R est reprsente par un ensemble de chiers, un par partition trie. Le rsultat est un ensemble P de partitions.

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 fus(b,c). } mettre la partition rsultat dans P } Sil reste une partition p dans P { mettre p dans P }

Algorithme fusion-phase: une phase de la fusion La deuxime tape consiste recommencer le mme processus mais avec fois moins de partitions chacune tant fois plus grande. La gure 11.2 rsume la phase de fusion. La phase de fusion peut tre reprsente par un arbre, chaque noeud (agrandi droite) correspondant une fusion de partitions. La gure 11.3 rsume lalgorithme de tri-fusion sur un ensemble de lms quon trie sur le nom du lm. La partie gauche est un ensemble de 12 lms non tris. La phase de droite illustre les 3 tapes de fusion. Celle-ci dmarre avec 4 partitions tries de deux lms chaque. Cot du tri-fusion La phase de tri cote lectures et critures pour crer les partitions tries. A chaque tape de la phase fusion, chaque partition est lue une fois et les nouvelles partitions crs sont fois plus grandes mais fois moins nombreuses. Par consquent chaque tape (pour chaque niveau de larbre de fusion). il y a entres/sorties. Le nombre d tapes cest--dire le nombre de niveaux dans larbre est G#@P . Par consquent le cot de la phase de fusion est G##@P . Il prdomine celui de la phase de tri. En rsum, le cout de lalgorithme de tri-fusion est G##@P .
3. En fait on utilise une variante de fus dans laquelle ds quun bloc correspondant la partition a t entirement lu, on nattend pas que tous les autres blocs (des autres partitions) aient t entirement lus, mais on lit le bloc suivant de la partition. Lalgorithme correspondant cette variante est laiss comme exercice.

11.2. EVALUATION DUNE REQUTE

161

... ... ...


o o

...

F IG . 11.2 tri-fusion: la phase fusion

Vertigo Annie Hall Twin Peaks Brazil Psychose Metropolis

Shining Greystoke Underground Jurassic Park Manhattan Easy rider

Annie Hall Brazil Easy rider

Greystoke Jurassic Park Manhattan

Metropolis Psychose Shining

Twin Peaks Underground Vertigo

Annie Hall Brazil Jurassic Park

Twin Peaks Underground Vertigo

Easy Rider Greystoke Manhattan

Metropolis Psychose Shining

Annie Hall Twin Peaks Brazil Vertigo

Jurassic Park Underground

Greystoke Metropolis

Psychose Shining

Easy Rider Manhattan

Annie Hall Vertigo

Brazil Twin Peaks

Metropolis Psychose

Greystoke Shining

F IG . 11.3 tri-fusion: un exemple

11.2.5

La Slection

. Il existe deux algorithmes pour la slection suivant le chemin daccs la table. Le premier consiste balayer squentiellement la table et pour chaque nuplet vrier le critre de slection. La deuxime mthode, sil existe un index sur cette table dont la cl appartient lun des critres de slection, est de slectionner le sous-ensemble de nuplets satisfaisant ce critre par lindex 4 (Accs par index), et ensuite daccder ces nuplets (Accs par adresse) et de vrier les autres critres de slection. On montrera que les algorithmes permettent de grouper en une seule tape, lors de laccs aux nuplets, une conjonction de slections ainsi que des projections. Slection/projection par balayage squentiel dune table Le balayage squentiel dune table est utile dans un grand nombre de cas. Tout dabord on a souvent besoin de parcourir tous les nuplets dune relation par exemple pour faire une projection. Certains algo4. Nous avons pris comme hypothse quil nexiste pas dindex de hachage. Sil y en a un, si le critre est lgalit on peut accder aux nuplets satisfaisant ce critre par lindex de hachage en une ou deux lectures de page.

162

CHAPITRE 11. VALUATION DE REQUTES

rithmes de jointure utilisent le balayage dau moins une des deux tables. On peut galement vouloir accder un ou plusieurs nuplets dune table satisfaisant un critre de slection. Ainsi on peut implanter la slection relationnelle par un parcours squentiel de la table, nuplet par nuplet, 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 nuplets 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 nuplet du tampon est test en fonction du critre de slection. Sil le satisfait, il est projet et rang dans un tampon de sortie (gure 11.4). Lalgorithme ci-dessous rsume ces oprations. Comme la plupart des algorithmes de cette section, il correspond une boucle sur les lectures/critures de pages et une boucle sur les nuplets en mmoire centrale. p:= premire page de R; n:= premier nuplet de p; s:= premier octet de S; Pour chaque page p de R { lire p dans le tampon dentre E; pour chaque nuplet 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; } } } Algorithme Selbal: Slection/projection par balayage squentiel Le cot de cette opration est donc de B: B pages sont lues. Cependant rappelons que si nous avons M>1 tampons disponibles en mmoire centrale et si les pages de la relation sont contigues sur le disque, nous pouvons lire M pages la fois. Or la lecture de M pages contigues sur disque est beaucoup moins chre que la lecture successive de M blocs dont lemplacement sur disque est quelconque. Plus M est grand, plus important est le gain.

tampon Entree E

sel/proj

tampon Sortie S

F IG . 11.4 Balayage squentiel de R

11.2. EVALUATION DUNE REQUTE


Accs par adresse

163

Quand on connait ladresse dun nuplet, 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 nuplets dont on connait les adresses. Il peut se faire que les nuplets soient tous dans des pages diffrentes. Alors il suft de lire pour chaque nuplet sa page et de le traiter. Mais il peut arriver que plusieurs nuplets 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 nuplets 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. La manire la plus simple dconomiser le nombre de lectures est de trier la liste des nuplets lire sur leur adresse de 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 nuplets de la mme page. Dans lexemple prcdent, si les adresses de nuplets sont tries avant accs la table, on ne lira que 4 pages: aprs tri, on obtient la liste de pages 1,1,3,4,4,5. Lorsque la page 1 (la page 4) est lue on accde aux deux nuplets de cette page. Slection/projection par traverse dindex Laccs par adresse une table est une opration qui suit en gnral une traverse dindex. La traverse dun index fournit une liste dadresses de nuplets: supposons quon veuille faire une slection sur la table , avec pour condition et supposons quil existe un index sur lattribut pour la table . Alors plutt que de balayer squentiellement , on prfrera rechercher par lindex les adresses de nuplets qui ont pour valeur de cl . On lira alors seulement ces nuplets et si la condition de slection est une conjonction de avec dautres critres de slection, on fera le test et la projection seulement sur un petit nombre de nuplets: ceux qui sont tels que (voir gure 11.5). Le cot dune slection utilisant une traverse dindex suivie dun accs par adresse une table, a deux composantes: cot de la traverse dindex et cot daccs la table. Traverser lindex est trs efcace. Si lindex ne rside pas entirement en mmoire centrale, cette traverse ncessitera quelques lectures sur disque 5 . Cette traverse a pour rsultat une liste de une ou plusieurs adresses de nuplet, une par nuplet qui satisfait . S il ny a quun seul nuplet, (notamment lorsque lindex est unique) alors il suft dune lecture supplmentaire pour accder au nuplet. Si nuplets satisfont le critre , alors le cot dpend de lindex: sil sagit dun index dense, dans le pire des cas, les nuplets sont sur des pages diffrentes (gure 11.5.(i)). Alors il faut lectures supplmentaires. Rappelons que dsigne le nombre de nuplets de et la slectivit de dans . Alors on peut estimer . Si en revanche lindex est non dense, la table est trie sur et les nuplets tels que , sont regroups, et occupent des blocs voisins. Le nombre de lectures devrait tre beucoup plus petit. On peut lestimer . Dans la gure 11.5.(ii), les nuplets tels que sont sur deux pages. Lestimation du cot dune slection/projection par traverse dindex est rsume ci-dessous. On note par le nombre de pages lues lors de la traverse dindex. 1. index unique :

2. index non unique dense:

3. index non unique non dense:

Lalgorithme ci-dessous rsume ces oprations dans le cas dun index dense. Le cas dun index non dense est laiss comme exercice. p:= premire page de R; n:= premier nuplet de p; s:= premier octet de S; Pour chaque adr dans TRAV(I,a) { SI (page dadresse page(adr) non dans Dejalue){
5. Nous avons vu dans le chapitre 10 que mme si lindex est entirement sur disque, le nombre de lectures disque est gal la profondeur de larbre B, laquelle est logarithmique dans la taille de la relation indexe.

164
a

CHAPITRE 11. VALUATION DE REQUTES


a

R p1

.... p2 p3

b,a,a,a,a

a,a,c,...

autres E select. proj . S E

autres select. proj. S

(i)

(ii)

F IG . 11.5 Slection/projection par traverse dindex (i) index dense; (ii) index non dense

lire page dadresse page(adr) dans un tampon de Dejalue; } pour chaque nuplet n dans E { SI (n satisfait les critres 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; } } } Algorithme Selind: Slection/Projection par traverse dindex

La traverse dindex est implante par TRAV(I,a) qui prend en entre un index et une valeur de cl, et sort une liste de une ou plusieurs adresses de nuplet. Page (adr) o adr est une adresse de nuplet, donne ladresse de page. Noter que tous les nuplets de la page sont balays, y compris ceux pour lesquels . Pour viter de lire deux fois la mme page, au lieu de trier la liste dadresses, lalgorithme ci-dessus utilise une variante consistant tester si la page na pas t dja lue (elle nest pas dans Dejalue). Plus le nombre de tampons affects Dejalue est grand 6, plus on a de chances de trouver une page dja lue en mmoire lors dune lecture ultrieure.
6. Supposons une gestion LRU de Dejalue.

11.2. EVALUATION DUNE REQUTE

165

11.2.6

Projection

Sil ny a pas de slection, la projection dune relation consiste examiner ses nuplets un par un, effectuer sur chacun la projection, cest--dire liminer les champs quon ne veut pas garder et enn liminer les nuplets en double. Cest cette dernire tape qui cote cher. Pour liminer les dupliqus, il existe deux techniques, le tri et le hachage. Dans le cas o les champs projeter appartiennent la cl dun index de la table, il suft de parcourir en squence les feuilles de lindex. Celles-ci sont tries sur la cl. Il suft de garder la cl ou son prxe et dliminer les doublons voisins en squence. Ce cas laiss comme exercice est trs efcace puisquil cote lectures, si est le nombre de feuilles. Projection par tri Lalgorithme comporte trois tapes: 1. Accs squentiel de la table et projection de chaque nuplet. Cest lalgorithme Selbal de la slection/projection, voir Section 11.2.5. Le rsultat est une table de taille pages. 2. Tri de cette table temporaire sur les attributs projeter: voir lalgorithme de la section 11.2.4. Le rsultat est une deuxime table intermdiaire de pages. 3. Parcours squentiel de la table trie et en comparant les nuplets voisins, limination des doublons. La premire tape cote lectures , o est le nombre de pages de et critures; la deuxime tape est en G#@v . La troisime tape cote lectures. On peut amliorer cet algorithme en faisant la projection et llimination des dupliqus en mme temps que le tri: 1. Projeter les nuplets lors de la premire phase du tri. 2. Eliminer les dupliqus lors des phases de fusions. Projection par hachage Soit le nombre de tampons en mmoire centrale. Lalgorithme est fait en deux phases: dans la premire, la table est accde squentiellement et projete (algorithme Selbal, voir Section 11.2.5) en utilisant un seul des tampons. Chaque nuplet projet est plac dans lun des -1 tampons: la fonction de hachage distribue uniformment les nuplets dans un entier compris entre 1 et -1. Quand un tampon est plein il est stock sur disque. A lissue de cette phase on a -1 partitions. La deuxime phase consiste liminer les dupliqus. Elle repose sur le fait que si deux nuplets sont dupliqus ils sont dans la mme partition. On suppose que toute partition peut tre lue entirement en mmoire et donc que sa taille ne dpasse pas -1 pages. En supposant luniformit de distribution, soit le nombre de pages de la table aprs projection. Le nombre de tampons doit tre plus grand que la taille dune partition: . Donc approximativement doit tre suprieur  . La deuxime phase consiste lire en squence chaque partition entirement en mmoire et faire llimination des dupliqus. Celle-ci peut se faire par tri en mmoire en utilisant lalgorithme  U@aa . Lalgorithme ci-dessous rsume ces oprations: Pour chaque page p de R { lire p dans premier tampon, pour chaque nuplet n de p { t = projeter (n); crire t dans tampon h(t); si tampon h(t) plein, vider h(t); } } Pour chaque partition pa {

166 lire pa dans les M tampons; eliminer dupliqus; vider pa sur disque.

CHAPITRE 11. VALUATION DE REQUTES

} Algorithme Projhash: Projection par hachage Deux remarques sont ncessaires: Cet algorithme est adapt au cas o le nombre de tampons est assez important en comparaison avec la taille de la relation projete. Il ne marchera pas si la taille dune partition dpasse pages. Dans le cas de dbordement dune partition, on peut rcursivement recommencer la mme technique de partitionnement dune partition en sous-partitions et dlimination des dupliqus dans chaque souspartition. Pour llimination des dupliqus dans une partition en mmoire centrale nous avons suggr un algorithme bas sur le tri en mmoire des nuplets de la partition. Une autre faon de faire est dutiliser une fonction de hachage  diffrente de . La partition est lue page par page. Chaque nuplet de la partition est hach dans une table de hachage en mmoire centrale 7 (utilisant les -1 tampons restant). #$ est sa position en mmoire. Il suft pour chaque nuplet  lu de vrier sil y a collision, cest--dire sil existe un nuplet dja stock tel que # $ . Sil nen existe pas,  est stock lemplacement    . Dans le cas contraire, on vrie que  est diffrent de . Si cest le cas  est stock dans la table de hash un emplacement qui dpend de la technique de hachage et de collisions utilise. Sinon  est limin.

11.2.7

Jointure

On peut classer les algorithmes de jointure en deux catgories, suivant labsence ou la prsence dindex sur les attributs de jointure. On tudiera successivement trois algorithmes de la premire catgorie et deux algorithmes de la deuxime catgorie. Dans le cas o les deux tables joindre nont pas dindex sur lattribut de jointure on utilise gnralement lalgorithme par boucles imbriques, le tri-fusion ou un algorithme bas sur le hachage des tables. Lorsquune table au moins est indexe sur lattribut de jointure on utilise une variante de lalgorithme par boucles imbriques avec trverse dindex. Enn si les deux tables sont indexes, on utilise parfois une variante du tri-fusion sur les index. On notera et les relations joindre et la relation rsultat. Le nombre de pages est not respectivement  , . Le nombre de nuplets de chaque relation est respectivement ! et " . On prcisera pour chaque algorithme sil peut tre utilis quel que soit le prdicat de jointure. a) Pas dindex sur les attributs de jointure 1) Boucles imbriques Cet algorithme sadapte tous les prdicats de jointure. Il numre tous les nuplets dans le produit cartsien de et 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 nuplet de , on balaye entirement lautre relation , appele relation intrieure. Pour chaque nuplet  de , on compare lattribut de jointure de  avec celui de . Si le prdicat de jointure est satisfait, on fait la jointure $#% et on met le nuplet dans un tampon quon vide sur disque lorsquil est plein. La technique est illustre 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
7. Attention, les techniques de hachage en mmoire centrale diffrent lgrement des techniques prsentes dans le chapitre prcdent

11.2. EVALUATION DUNE REQUTE


} } Procdure BIM (R,S): boucles imbriques en mmoire Illustrons cet algorithme sur un exemple. Soit les tables Films et Artistes de schma: Films(nom-film, anne) Artistes(Nom,nom-film) La jointure naturelle

167

#&#@'HY(

par boucles imbriques est illustre dans la gure 11.6


Spielberg Hitchcock Allen Lang Hitchcock Allen Kubrik Spielberg Hitchcock Allen Lang Hitchcock Allen Kubrik ....... Jurassic Park Psychose Manhattan Metropolis Vertigo Annie Hall Shining Jurassic Park Psychose Manhattan Metropolis Vertigo Annie Hall Shining

Vertigo 1958

Annie Hall 1977

Brazil 1984

Comparaison Association

F IG . 11.6 Jointure par boucles imbriques

En fait lalgorithme prcdent ne marche que si ) et 0 sont entirement en mmoire centrale. Comme en gnral ce nest pas le cas, on lit en squence les pages de ) . Pour chaque page 1 de ) , on lit en squence, les pages de 0 . Pour chaque page 2 de 0 on fait la jointure avec la page 1 . On applique lalgorithme BIM ci-dessus pour les nuplets de la page 1 et les nuplets de la page 2 qui sont dans deux tampons mmoire. Lorsque la jointure entre 1 et 2 est termine, on passe la page suivante de 0 . Lorsque toutes les pages de 0 ont t visites, on recommence tout le processus avec la page suivante de ) . Cet algorithme illustr ci-dessous ncessite donc 3 tampons en mmoire, deux pour lire une page de chaque relation et un pour rsultat de la jointure. Le cot de la jointure avec cet algorithme est de 3465"37 lectures. Pour chaque p dans pages(R) { lire p Pour chaque q dans pages(S) { lire q BIM(p,q)} } Algorithme BIS: jointure par boucles imbriques simples Si le nombre de tampons disponibles est plus important on peut faire la jointure avec la variante suivante plus efcace.

168 2) Variante: Boucles imbriques par bloc

CHAPITRE 11. VALUATION DE REQUTES

Soit ) la relation la plus petite. Si le nombre de tampons 8 est au moins gal 34@9BA , la relation tient en mmoire centrale. On la lit dans 34 tampons, et pour chaque page q de 0 on fait la jointure (procdure BIM(R,q)). La table 0 nest lue quune seule fois. le cot est de 3469C37 lectures! Dun cot quadratique dans les tailles des relations, lorsquon na que 3 tampons, 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 D (comme pour la projection, algorithme Projhash). Alors pour chaque nuplet de 0 on cherche par h(s) les nuplets de ) joignables. Le cot de lectures disque est inchang, mais le cot CPU est linaire dans le nombre de nuplets des tables E 4 9@E 7 (alors quavec la procdure BIM il est une fonction quadratique du nombre de nuplets). Malheureusement il arrive souvent que ) ne tienne pas en mmoire: 3 4 > 8GFHA . On peut alors dcouper ) en blocs de taille 8IFPA pages et utiliser la variante ci-dessus pour chaque bloc. ) est lue une seule fois bloc par bloc, 0 est lue Q3 4SRT 8UF&AWVYX fois. Le cot est alors de 3 4 9PQ`3 4aRbT 8UFcAdVeXf5"3 7

3) Tri-fusion Lalgorithme de jointure par tri-fusion que nous prsentons ici sapplique lquijointure. Cest un exemple de technique deux phases: la premire consiste trier les deux tables sur lattribut de jointure si elles ne sont pas dj tries. Ce tri facilite lidentication des groupes de nuplets avec la mme valeur dattribut de jointure. Le rsultat est deux tables temporaires stockes sur disque. On utilise lalgorithme de tri externe vu prcdemment pour cette premire tape. La deuxime phase appele fusion consiste lire page par page, chacune des deux tables temporaires et parcourir squentiellement en parallle ces deux tables temporaires pour trouver les nuplets joindre. Comme les tables fusionnes sont tries, sauf cas exceptionnel, chaque page de chaque table nest lue quune fois. Regardons plus en dtail la fusion. Soit lquijointure de ) et 0 sur les attributs )hg i et 0pg 3 On commence avec les premiers nuplets q(r et s r de chaque relation. 1. Si

2. 3.

q r g iutsyx s r g 3 , on joint les deux nuplets, on au deuxime nuplet de 0 et on fait le test s passe qvrvg iwt g 3 , etc., jusqu ce que le nuplet de 0 soit tel que s g 3 >q(g i . On avance alors au deuxime nuplet de ) et on fait le test q x g iHt s g . Si qvrvg i < s r(g 3 on lit le deuxime nuplet de ) et on recommence. Si enn q r g i > s r g 3 , on passe au nuplet suivant de 0 , etc.

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 nuplets de ) en squence et plusieurs nuplets de 0 en squence. Ensuite on recommence. On donne ci-dessous lalgorithme de fusion en supposant comme dhabitude quon a trois tampons en mmoire, un pour lire une page de chaque table trie, et un pour le rsultat. tant que r diffrent de eof et s diffrent de eof { p = 1e page de R; lire p; r = 1er nuplet de p; q = 1e page de S; lire q; s = 1er nuplet de q; v = 1er nuplet de q; tant que r.A < s.B { si p lu entirement { p = page suivante de R; lire p; r = 1er nuplet de p;

11.2. EVALUATION DUNE REQUTE


} sinon

169

r = nuplet suivant dans p; } tant que s.B < r.A { si q lu entirement { q = page suivante de S; lire q; s = 1er nuplet de q; } sinon s = nuplet 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 = nuplet suivant dans q; } r = nuplet suivant dans p; } } Algorithme Trifus: quijointure par tri-fusion r est diffrent de la valeur spciale eof pour r et s indique quil ny a plus de nuplet dans la relation balaye. Si r= eof alors toute comparaison impliquant r.A sera value faux. La jointure naturelle e s iqyY s ' s par tri-fusion est illustre dans la gure 11.7
Allen Annie Hall 1977 Spielberg Jurassic Park 1992 ....

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 Fichier films

TRI Fichiers Artistes

F IG . 11.7 Jointure par tri-fusion

En gnral, on doit parcourir un groupe de nuplets en squence de 0 ayant mme valeur pour B, autant de fois quil y a de nuplets dans ) ayant la mme valeur pour i (boucle tant que r.A = s.B). Si le groupe

170

CHAPITRE 11. VALUATION DE REQUTES

de nuplets de 0 est cheval sur plusieurs pages, il va falloir rappeler plusieurs fois les mmes pages de 0 , ce qui peut augmenter sensiblement le nombre de lectures disque 8. Lalgorithme ci-dessus suppose que ce cas narrive jamais. Il suppose que lorsquun groupe de nuplets en squence de ) est joint un groupe de nuplets de 0 , les deux groupes sont entirement dans les pages p et q courantes dans le tampon. L hypothse dun parcours unique de chacune des 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 34937 lectures disque. En gnral, les relations ntant pas tries, le tri domine le cot de lalgorithme de tri-fusion qui est alors: T 34y T 34VVb9 T 37y T 37VV9C34&9C37 . 4) Jointure par hachage

Comme tous les algorithmes base de hachage, cet algorithme ne peut sappliquer une theta-jointure. Comme lalgorithme de tri-fusion (section 11.2.7), il a deux phases: une phase de partitionnement (v)Tj4.91997foi cet fusion phase estt48ges, o

11.2. EVALUATION DUNE REQUTE


crire s dans tampon h(s.B) } } pour i=1,...,k { lire partition (R,i); pour chaque page p de partition (S,i) { lire p; BIM(partition(R,i), p) } }

171

Le cot de la premire phase de partitionnement de cet algorithme est A T 3 4 9{3 7 V . Chaque relation est lue entirement et hache dans les partitions qui sont recopies sur disque page par page. A la n les tampons non pleins sont galement recopis sur disque dans la partition correspondante. Bien que le nombre de pages de ) ( 0 ) aprs partitionnement (hachage) puisse tre lgrement suprieur, on supposera quil est gal 34 ( 37 ). Le cot de la deuxime phase est de 34@9|37 . En effet les relations partitionnes sont lues une fois, partition par partition. Par consquent le cot total de cet algorithme est } T 34%9~37V . Noter que cet algorithme est trs gourmand en mmoire. Il suppose que toute partition de la plus petite relation ) tienne entirement en mmoire centrale, cest--dire, ait moins de 8mFPA pages. Cet algorithme est donc bien adapt aux jointures pour lesquelles un relation est petite en taille. En supposant que les partitions de ) sont gales en taille, celle-ci est gale 34 RT 8FAWV . On doit donc avoir 834 RbT 8FAdV9|A . Donc on doit avoir approximativement 8I{ 34 . 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. il faut prvoir le cas o la taille dune partition dpasse pour la projection par hachage).

8qFA

tampons (voir la mthode employe

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 ( 3 4% 8FwA ), il existe une variante de lalgorithme qui consiste (i) partitionner ) comme ci-dessus dans lun des M-2 tampons 10 et (ii) accder squentiellement 0 sans partitionnement pralable et faire la jointure en mmoire centrale entre ) et les nuplets de 0 lus dans un tampon. Soit s un tel nuplet. On le comparera avec les nuplets du tampon D T s g 3"V . Pour valuer le cot de cette variante, observons que chaque relation nest lue quune fois. Le cot est alors de 34&9C37 . b) Index sur lattribut de jointure de lune ou des deux relations 1) Boucles imbriques et traverse dindex Sil existe un index sur le ou les attributs de jointure 3 de lune des relations 0 , une variante de lalgorithme des boucles imbriques trs efcace est utilise dans tous les SGBD. On prend comme relation extrieure lautre relation ) sur laquelle on fait un accs squentiel. Pour chaque nuplet q de ) , q(g i sert de cl daccs lindex . La traverse de donne les adresses de nuplets s de 0 qui peuvent tre joints avec q , cest--dire ceux pour lesquels s g 3tpq(g i . Il suft ensuite daccder par adresse aux nuplets s et de les joindre avec q . On a vit le balayage de toute la relation 0 qui est fait pour chaque nuplet q de ) dans lalgorithme initial (Algorithme BIS). On donne lalgorithme ci-dessous: Pour chaque p dans pages(R) {
10. La diffrence avec lalgorithme ci-dessus est quon na quune partition pour R.

172

CHAPITRE 11. VALUATION DE REQUTES


lire p dans tampon E Pour chaque nuplet r dans p { adresses = TRAV (I,r.A) pour chaque a dans adresses { acces par adresse au nuplet s t= jointure de r et s si tampon resultat T plein { vider T } ecrire t dans T } }

} Algorithme BIT: jointure par boucles imbriques et traverse dindex Le cot de cet algorithme est le produit (i) du nombre de pages 3 4 de ) par (ii) le cot de la traverse dindex suivi du cot daccs au(x) nuplet(s) de 0 . Celui-ci dpend du type dindex et du nombre de nuplets de 0 , voir discussion ce sujet dans la section 11.2.5. En rsum le cot de lalgorithme de jointure est 34C5o T y T 37VV . Une variante de cet algorithme existe dans le cas o 0 est partitionne par hachage sur la valeur de lattribut 3 . Alors que la variante ci-dessus sapplique tous les prdicats de jointure, la variante avec hachage ne marche que pour lquijointure. 2) 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 ) et 0 ont un index sur lattribut de jointure, comme les feuilles de ceux-ci sont tries sur lattribut de jointure, en fusionnant les feuilles des index et , comme dans la phase de fusion de lalgorithme de jointure par tri-fusion (section 11.2.7), on obtient une liste de couples dadresses de nuplets de ) et 0 joindre. Dans le pire des cas, o les deux index sont non uniques, pour chaque couple de valeurs des attributs de jointure gk , on obtient un couple densembles dadresses de nuplets iWg3 . La deuxime phase consiste lire les nuplets, 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 est en gnral (voir discussion sur la jointure par tri-fusion) la somme du nombre de feuilles u et du nombre de feuilles u . Cet algorithme est trs intressant dans le cas o la deuxime phase daccs aux nuplets 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

11.3. COMPILATION DUNE REQUTE ET OPTIMISATION

173

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 11.2.5). 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 de nuplets obtenus sur les pages de la premire relation pour regrouper les nuplets 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, certains SGBD, en prsence dindex sur lattribut de jointure dans les deux relations, prfrent lalgorithme par boucles imbriques et traverse dindex cet algorithme.

Concluons cette section avec deux remarques: 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 de nuplets 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.

11.3
11.3.1

Compilation dune requte et optimisation


Traduction de la requte en un plan dexcution logique

Dcomposition dune requte en blocs Nous supposerons quune requete 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 11 . 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 directeur du dpartement ayant lemploy le plus rmunr: Employes (nom, departement, salaire) Departement(dept-id, directeur) SELECT directeur FROM Departement,Employes WHERE Departement.dept-id = Employes.departement AND salaire = (SELECT MAX (salaire) FROM Employes) On peut dcomposer cette requte en deux blocs: le premier calcule le salaire maximum 0 . Le deuxime bloc calcule le(s) directeur(s) de dpartement(s) avec un employ ayant pour salaire 0 une rfrence au rsultat du premier bloc. SELECT directeur FROM Departement,Employes
11. Nous naurons pas considrer les deux dernires clauses car nous avons dit dans la section 11.2 que nous nous concentrons sur les requtes faisant intervenir seulement des slections, des projections et des jointures.

174

CHAPITRE 11. VALUATION DE REQUTES

WHERE Departement.dept-id = Employes.departement AND salaire = rfrence au bloc imbriqu Bien entendu cette mthode peut savrer trs infcace 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 dquivalences. Enn nous supposerons que tout critre de slection est sous forme normale conjonctive (FNC). Toute condition de slection peut tre mise en FNC. Une condition en FNC est une conjonction de critres qui sont soit des slections atomiques soit des disjonctions de slections atomiques 12. La premire tape de la compilation dune requete (un bloc) consiste en son analyse syntaxique et en sa traduction en un plan dexcution logique (PEL). 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 EDbt~eWgWWgdWE@DbatdgdW . Enn un certain nombre de simplications sont effectues. Par exemple T i%v'3hVc3"V est remplac par iCc3 . Aprs analyse, la requte est traduite en un plan dexcution logique. Soit une base de schma: Departements(nom, num, prefecture) Communes(nom, numdept, Nbhab)

Soit la requte Select Dept.nom From Departements, Communes Where Nbhab > 1,000,000 And Communes.numdept=Departements.num qui cherche le nom des dpartements ayant une commune avec plus dun million dhabitants. La gure 11.8 est un plan dexcution logique (PEL) correspondant (quivalent) cette requte. Cest en fait un arbre reprsentant lexpression algbrique

W Tfev r T vc s v ` vB 1qv'ycy s V ,

quivalente la requte SQL 13 . Dans larbre, les feuilles reprsentent les tables arguments de lexpression algbrique. Les noeuds internes correspondent aux oprateurs algbriques. Un arc entre un noeud et son noeud pre 1 correspond la relation rsultat de lopration et argument dentre de lopration 1 . Linterprtation de larbre est la suivante. On commence par excuter les oprations sur les feuilles (ici la jointure entre Communes et dpartements); sur le rsultat, on effectue les oprations correspondant aux noeuds de plus haut niveau (ici une slection), etc. , jusqu ce quon obtienne le rsultat (ici aprs la projection).

11.3.2

Lois algbriques

On peut amliorer le PEL obtenu par traduction de la requte SQL, grce lexistence de proprits sur les expressions de lalgbre relationnelle, cest--dire sur des squences doprations relationnelles. 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
12. Les stratgies mettre en oeuvre en prsence dune disjonction sont simples. Sil existe un index la fois sur et sur , alors on peut retrouver les nuplets candidats par lindex et ensuite en faire lunion. Si en revanche la relation nest indexe que sur (ou que sur ), alors cela ne sert rien de passer par lindex: il faut faire un balayage squentiel de la relation. 13. Toute requte SQL a une expression algbrique quivalente.

o&ps&

11.3. COMPILATION DUNE REQUTE ET OPTIMISATION


.Departements.nom

175

Nbhab>1,000,000

#dept=num

Communes

Departements

F IG . 11.8 Exemple de plan dexecution logique

des PEL qui sont plus efcaces cest--dire qui sexcutent plus rapidement. Nous verrons cela dans la sous-section suivante. Pour linstant donnons la liste des rgles de rcriture les plus importantes: 1. Commutativit des jointures : 2. Associativit des jointures :

) 00 )

T ) 0aV P) T 0 V

3. Regroupement des slections :

j  T )$Va  T  T )$VV 

4. Commutativit de la slection et de la projection 5. Commutativit de la slection et de la jointure. 6. Distributivit de la slection sur lunion. NB : valable aussi pour la diffrence.

T T )$VVa T k T )$VVgS@dedggjgigjg1 T ) T gigjg igjgigV 0aVa  T )$V 0

T )%&0aVa T )V  T 0SV

7. Commutativit de la projection et de la jointure

8.

0aVa (T ) bT )$V WT 0aVVuS@dedggjgig1dgehdeWghgigjgjg2 Distributivit de la projection sur lunion bT ){0SVa T )V T 0aV
Amlioration dun plan dexcution logique

11.3.3

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 B, la rgle justie de ltrer sur i seulement les nuplets satisfaisant le critre 3t 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 PEL meilleur. 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

176

CHAPITRE 11. VALUATION DE REQUTES

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 extrmement considrable sur le temps de traitement de la jointure. Pousser les slections le plus bas possible dans larbre, cest--dire essayer de les faire 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). 4. Descendre les projections le plus bas possible (rgles 7 et 8). 5. Regrouper les projections sur une mme relation. Un exemple Le PEL de la gure 11.9 est un meilleur PEL que celui de la gure 11.8 pour effectuer la requte Dpartements ayant une commune de plus dun million dhabitants. Il a t obtenu en appliquant la rgle de rcriture 5.
Departements.nom

#dept=num

Nbhab>1,000,000

Communes

Departements

F IG . 11.9 PEL meilleur

Prenons un autre exemple sur une base de lms de schma:

Cinma (nom-cinma, adresse) Salle (salle,nom-cinma) Sance (salle, film, heure-dbut)

11.3. COMPILATION DUNE REQUTE ET OPTIMISATION


Soit la requte Quels lms passent au REX a 20 heures ? exprime par lordre SQL suivant. SELECT FROM WHERE AND AND AND film Cinma, Salle, Sance Cinma.nom-cinma = Le Rex Sance.heure-dbut = 20 Cinma.nom-cinma = Salle.nom-cinma Salle.salle = Sance.salle

177

Par traduction algbrique, on obtient le PEL suivant:

film
heure-dbut=20 nom=Le REX

CINEMA

SALLE

SEANCE

F IG . 11.10 PEL par traduction algbrique

En appliquant les rgles de rcriture, on obtient le PEL suivant:

film

salle

nom

nom,salle

salle,film

(CINEMA)

SALLE

nom=Le REX

(SEANCE) heure-dbut=20

F IG . 11.11 PEL aprs rcriture

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

178

CHAPITRE 11. VALUATION DE REQUTES


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.

11.3.4

Estimation des cots et choix dun plan dexcution physique

On commencera par dnir ce quest un plan dexcution physique (PEP) et on en donnera un exemple. Grosso modo un PEP est une squence doprations physiques (on parle dalgbre physique) propres lditeur de logiciel 14 . Dans la section 11.2 nous avons vu les algorithmes implantant les principales oprations physiques. Nous redonnons ici une liste doprateurs physiques quon retrouve dans tous les SGBD. Le choix du PEP dpend de nombreux facteurs: chemin daccs, statistiques, nombre de tampons en mmoire centrale. Typiquement en fonction de ces paramtres, loptimiseur choisit pour chaque noeud du PEL, une opration physique ou une squence doprations. La difcult vient du grand nombre de paramtres. Bien que les optimiseurs du commerce utilisent une heuristique prenant en compte tous les paramtres 15, nous considrons pour linstant que la place disponible en mmoire centrale pour la requte nest pas un facteur de choix et reportons la discussion la section 11.3.8. Une autre difcult vient du fait que le choix dun algorithme pour un noeud du PEL peut avoir un impact sur le choix dun algorithme pour le noeud 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 11.3.8). 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 du cot dune opration physique utilise un modle de cot simpli 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 in , sachant quil existe un index dense sur i , 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 noeuds internes sont les oprateurs physiques. Les feuilles reprsentent les oprations quon fait en premier. Larc entre un noeud et son noeud 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. Il est noter quune opration algbrique peut donner naissance plusieurs oprations physiques. La jointure par tri-fusion est un exemple. 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. Liste doprateurs physiques La gure 11.12 donne une notation pour quelques oprateurs physiques courants. Cette notation sera utilise dans les exemples de plans dexcution physique plus bas.
14. 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. 15. Ils mlangent dailleurs rcriture algbrique et choix des oprations physiques et nnumrent pas tous les PEL possibles.

11.3. COMPILATION DUNE REQUTE ET OPTIMISATION


CHEMINS DACCES
Sequentiel Critere

179

OPERATIONS PHYSIQUES
Critere

TABLE Parcours sequentiel


Adresse

Selection Selection selon un critere


Attribut(s)

Filtre Filtre dun ensemble en fonction dun autre


Critere

TABLE Acces par adresse


Attribut(s)

Tri Tri sur un attribut


Critere

Jointure Jointure selon un critere


Attribut(s)

INDEX Parcours dindex

Fusion Fusion de deux ensembles tries

Projection Projection sur des attributs

F IG . 11.12 Algbre physique

On distingue les oprations daccs des tables ou index stocks dans des chiers, des oprations proprement dites. Les oprations daccs des chiers sont reprsentes dans les arbres par des rectangles (feuilles du PEP). Le nom du chier est indiqu lintrieur du rectangles. La premire est le balayage squentiel. La deuxime est laccs par adresse, cest--dire laccs un ou plusieurs nuplets connaissant son (leur) adresse. Le troisime enn est la traverse dindex. On indique le ou les attribut(s) cl(s). Les oprations proprement dites 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 noeud 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 11.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). Exemples de plans dexcution physique Les gures 11.13 et 11.14 donnent deux PEP typiquement gnrs par loptimiseur pour le PEL de la gure 11.11 respectivement dans le cas o aucune des relations nest indexe sur les attributs de jointure et le cas o pour chaque jointure une table est indexe sur lattribut de jointure. Quand il ny a pas dindex, les slections sont faites par balayage squentiel et les jointures par trifusion. La table Cinema est balaye squentiellement. La slection garde seulement les cinmas Le REX ey& . La table Salle est galement balaye squentiellement et qui sont ensuite tris sur lattribut trie sur lattribut eyc . Les chiers rsultant du tri sont fusionns et tris sur lattribut s v d s . Le chier rsultant est fusionn avec les sances dbutant 20 heures galement tries sur lattribut y et obtenus par balayage squentiel et slection de la table Seance.

Notons que 1. lopration algbrique de slection est chaque fois traduite par un balayage squentiel (algorithme Selbal de la section 11.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 (noeud interne). La mme remarque joue pour le tri de la table Salle.

180

CHAPITRE 11. VALUATION DE REQUTES


Projection

Fusion ID_seance Tri

Fusion ID_cinema Tri Le Rex Selection Sequentiel Cinema Sequentiel Salle Tri ID_cinema Tri Horaire=20 Selection Sequentiel Seance ID_seance

F IG . 11.13 plan dexcution physique: pas dindex sur les attributs de jointure

Projection

Jointure

Le Rex Jointure Horaire=20 Selection Adresse Salle Adresse Cinema Selection

Sequentiel Seance

Id_salle Index Salle(ID_salle)

Id_cinema Index Cinema(ID_cinema)

F IG . 11.14 plan dexcution physique: table indexe pour chaque jointure

2. il faut rajouter : la premire tape consiste traverser lindex. Une estimation raisonnable de est les projections intermdiaires avant et aprs tri qui nont pas t indiques dans la gure 11.13 pour simplier, 3. chaque arc de larbre correspond un ot de nuplets (rsultat de lopration de plus bas niveau dans 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 11.3.8).

11.3. COMPILATION DUNE REQUTE ET OPTIMISATION

181

Dans le cas o il y a un index sur lattribut de jointure de chaque jointure (gure 11.14), les deux jointures se font par boucles imbriques. Linterprtation dun arbre ayant pour racine le noeud Jointure est particulier. Pour chaque nuplet gnr par la branche de gauche, la valeur de lattribut de jointure sert de cl daccs lindex dans la branche de droite. La traverse de lindex donne une ou plusieurs adresses de nuplets qui sont accds (accs par adresse) et joints avec le nuplet de la branche de gauche. Par exemple eyc sert de cl daccs lindex (premire jointure), pour chaque cinma de nom Le Rex, son IndexSalle. La traverse de lindex donne ladresse des salles de ce cinma. Le nuplet correspondant chacune de ces salles est joint avec le nuplet du cinma.

Reprenons lexemple des communes et d partements de schma Communes(nom,nbhab,#dept) Departements(num,nom,prefecture) La gure 11.15 montre un plan dexcution logique et le plan dexcution physique choisi pour excuter la requte: Select Dept.nom From Departements, Communes Where Nbhab > 1,000,000 And Communes.numdept=Departements.num
adresse Departements.nom Departements

Tri

adresses

#dept=num Jointure.

Nbhab>1,000,000 Nbhab>1,000,000 Selection #dept I_dept

Communes

Departements

sequentiel Communes

F IG . 11.15 plans dexcution logique et physique

Cette requte dtermine le nom des dpartements qui contiennent une commune de plus dun million dhabitants. c1 et reprsentent le numro de dpartement deux chiffres. La relation 1qv'ycy s est indexe sur ( ). Le plan logique ( gauche dans la gure) indique quon slectionne dabord les communes de plus dun million dhabitants et quensuite on fait la jointure. La slection est implante par un balayage squentiel du chier Communes ( droite dans la gure), lalgorithme de jointure tant la boucle imbrique: pour chaque commune de plus de 1 million dhabitants, son numro de dpartement (numdept) sert de cl daccs lindex . La traverse de lindex donne ladresse de larticle du dpartement. Le rsultat de la jointure est une liste dadresses darticles. Celles-ci sont tries par page. Les noms de dpartements sont alors obtenus par accs direct du chier Departements et projection

182

CHAPITRE 11. VALUATION DE REQUTES

sur le nom. Noter que chaque article de Departements accd par adresse est en mme temps projet sur le nom.

11.3.5

Exemple destimation du cot dune opration

Soit la slection bT )$V . La table a Et}WdW nuplets stocks sur unique sur i . Il existe deux algorithmes pour valuer cette slection:

3tpW

blocs et un index dense

1. le balayage squentiel de ) : la table ntant pas en gnral trie sur i , dans le cas du balayage squentiel, il faut parcourir toute la table et tester pour chaque nuplet lingalit. 2. la traverse dindex: on accde la feuille contenant le couple gdqv svs vdy1ye et on parcourt ensuite toutes les feuilles de lindex chaines en squence. Pour chacun des couples gWq( svs h , on accde au nuplet dadresse Wq( svs (une lecture de page), voir section 11.2 et chapitre 2.

Pour choisir entre ces deux algorithmes, loptimiseur compare les estimations du cot de chacun: 1. balayage squentiel: 2.

t 3ptehW B index: tP9C3 R eh9CE R ehtn}eyA

Lestimateur du cot de lalgorithme utilisant lindex est la somme de trois estimations: estimation du nombre de niveaux de lindex: la premire tape consiste traverser lindex. Une estimation raisonnable de est: htn} estimation du nombre de feuilles chaines lire en squence: les feuilles de lindex sont tries sur i . Lestimateur simpliste consiste dire qu un dixime des feuilles satisfait au critre 3 R ehtB 16

estimation du nombre de pages de ) lues pour accder aux nuplets: E R eh . Cet estimateur simpliste est justi par les hypothses suivantes: (i) environ E R eh nuplets satisfont le critre; (ii) pour chaque nuplet tel que itH 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 i (stock ou valu sur un chantillon), on peut arriver une estimation plus ne du nombre de nuplets satisfaisant le critre conduisant ventuellement au choix de la stratgie avec index.

11.3.6

Choix dun oprateur pour la slection

Considrons le cas gnral dune condition de slection qui est un iE de conditions de la forme itp ou 3 (voir note de bas de page de la section 11.3.1). Supposons pour simplier lexpos que les conditions portent sur attributs diffrents. Nous supposons galement que la relation a un index sur 1 parmi les attributs apparaissant dans un critre. Alors loptimiseur a le choix entre le balayage squentiel (la condition complte est teste sur chaque nuplet) et laccs par index suivi dun accs par adresse au nuplet (et le test sur ce nuplet des $Foe conditions restantes). Comme il y a 1 critres portant sur un attribut avec index, loptimiseur a 19~e cas considrer. Lestimation du cot de chacun des cas est rsum ci-dessous en fonction du nombre de nuplets E , du nombre de blocs 3 de la relation et de la slectivit 0 T )"giV de lattribut i . 1. balayage squentiel:

tB3

16. On pourrait penser quen moyenne nuplets satisfont le critre. Lintuition du rapport avec ingalit donne seulement une petite fraction des nuplets.

Sk

sur

vient de ce quune requte

11.3. COMPILATION DUNE REQUTE ET OPTIMISATION

183

2. stratgie avec index sur un critre avec galit (lindex est suppos tre dense et non unique, voir section 11.2): t$9%B9C o est le cot de traverse dindex, est le nombre de feuilles en squence lire et le nombre de pages lire pour accder aux nuplets (et tester les !F@e conditions restantes): t T EU5o0aV RT E R 3hVStP35o0 En effet le terme numrateur E560 indique le nombre moyen de nuplets par valeur dindex et le dnominateur E R 3 indique le nombre de nuplets par page. tE50 . En effet est le nombre de nuplets 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 tn9 T 39CEV5&0 . 3. stratgie avec index sur un critre avec ingalit: "9 T 39BEV R eh : le premier terme concerne la traverse dindex; le terme 3 R eh est lestimation du nombre de feuilles parcourues et le terme E R eh est lestimation du nombre de nuplets accds et tests sur les cF{e autres critres (voir discussion de la section prcdente)

11.3.7

Stratgies pour le choix dun oprateur pour la jointure

Lors de ltude des algorithmes de jointure dans la section 11.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 nuplets) 17 . 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 18 . 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.

11.3.8

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?
17. 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 nuplets des deux relations (voir discussion sur le cot de cet accs dans la section 11.2). 18. 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).

184

CHAPITRE 11. VALUATION DE REQUTES

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 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 entiement 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 nuplet. Si ( est un opration binaire il demande chacun de ses oprations lles dans larbre, respectivement et ( , un nuplet. Ce mcanisme de pipelinage " la demande" est implant au moyen dun arbre ditrateurs (correspondant au PEP) dont les fonctions sappellent des moments appropris. A chaque oprateur physique (chaque noeud 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:= premiere page de R; n:= premier nuplet dans la page p; FIN = false; } NextScan (R) {

11.3. COMPILATION DUNE REQUTE ET OPTIMISATION


IF (n a depass le dernier nuplet de la page p) { incrementer p la page suivante; IF (pas de page suivante) { FIN := true; RETURN; } ELSE lire page p; n:= premier nuplet de la page p; } vieuxn:= n; incrmenter n au nuplet suivant dans la page p; RETURN vieuxn; }

185

CloseScan (R) { liberer ressources; RETURN; }

} Un itrateur pour le balayage squentiel de R

OpenScan (R) initialise la lecture au premier nuplet de la premire page de R. La variable FIN est initialise false. NextScan (R) retourne un nuplet. Si la page courante a t entirement lue, il lit la page suivante et reourne le premier nuplet de cette page. Litrateur I qui appelle litrateur de balayage squentiel de R commence par appeler OpenScan (R). Tant que la variable globale FIN nest pas true, un nuplet est retourn (vieuxn) par un appel de NextScan(R). Quand la table est entirement lue (FIN=true), I lance litrateur CloseScan (R).

Illustrons ceci avec litrateur de jointure par boucles imbriques entre une table ) et une table 0 indexe, utilisant un balayage squentiel de ) et un accs lindex . Litrateur implantant cet algorithme aura pour entres R et . La table R est balaye. Pour chaque nuplet lu , la valeur de lattribut de jointure g Y sert de cl daccs lindex : La traverse de lindex retourne une (index unique) ou plusieurs adresses (index non unique) de nuplets de S. Un ou plusieurs couples ( , ) sont retourns comme rsultat. On itre avec le nuplet suivant de ) . Cette jointure est la plupart du temps suivie par un accs par adresse S 19 . OpenBI(R,I) { OpenScan(R); OpenIndex(I); } NextBI(R,I) { IF (FIN =false){ n:= NextScan(R); FOR each a in NextIndex(I,n.at),
19. On peut alors, avant daccder S, comme dans le plan dexcution ci-dessus, trier les adresses pour viter de lire deux fois la mme page.

186 RETURN [n,a]; } ELSE { RETURN; } }

CHAPITRE 11. VALUATION DE REQUTES

CloseBI (R,I) { CloseScan(R); CloseIndex(I); RETURN; }

} Un itrateur pour la jointure par boucles imbriques avec un index Noter que lappel de NextIndex prend comme argument lindex et la valeur de la cl. Il retourne un ensemble dadresses de nuplets. La construction de litrateur daccs un index (OpenIndex,NextIndex et CloseIndex) est laisse comme exercice. En conclusion ce mcanisme ditrateurs permet de gnrer des plans dexcution par simple assemblage ditrateurs construits au pralable.

187

Chapitre 12

Introduction la concurrence daccs


Sommaire
12.1 Prliminaires . . . . . . . . . . . . . . . . . . 12.1.1 Excutions concurrentes : srialisabilit . 12.1.2 Transaction . . . . . . . . . . . . . . . 12.1.3 Excutions concurrentes : recouvrabilit 12.2 Contrle de concurrence . . . . . . . . . . . . 12.2.1 Verrouillage deux phases . . . . . . . 12.2.2 Contrle par estampillage . . . . . . . . 12.3 Gestion des transactions en SQL . . . . . . . 12.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 188 189 190 192 192 195 195 196

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 multi-utisateur 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.

12.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 s Le nombre de places souhait E@$ Le client debut Lire la sance s si (nombre de places libres {E$ s ) Lire le compte du spectateur

188

CHAPITRE 12. INTRODUCTION LA CONCURRENCE DACCS


Dbiter le compte du client Soustraire E@$ s au nombre de places vides Ecrire la sance s Ecrire le compte du client nsi

n 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 )!0!)i E se reprsente donc simplement par la squence r[s] r[c] w[c] w[s]

12.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 r , du programme x . Exemple 12.1 Voici un exemple de deux excutions concurrentes du programme )!0)$$i Epr et x . Chaque programme veut rserver des places dans la mme sance, pour deux clients distincts r et x.

1. Il reste 50 places libres pour la sance s . 2. 3.

dans cet ordre. Imaginons maintenant que lon se trouve dans la situation suivante :

q(r T s Y V qvr T r V'q x T s Y Vq x T x ' V x T s V' x T x V'r T s V'r T rV Donc on effectue dabord les lectures pour pr , puis les lectures pour x enn les critures pour x pr x
veut rserver 5 places pour la sance s . veut rserver 2 places pour la sance s .

et

Voici le droulement imbriqu des deux excutions pr T s gg rV et x T s geyg x V , en supposant que la squence des oprations est celle donne ci-dessus. On se concentre pour linstant sur les volutions du nombre de places vides. 1. 2. 3. 4. 5. 6.

pr x x x r r p

lit s et lit s et

r . Nb places vides : 50. x . Nb places vides : 50. x. r.

crit s avec nb places = WFA$tPd . crit le nouveau compte de crit s avec nb places = WF$tP . crit le nouveau compte de

12.1. PRLIMINAIRES

189

A 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 r et x : x lit et modie une information que r 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.

sexcuter et ne crera donc plus dinterfrence.

q r Ts ' ( V qvr T VYr T s Y V r T VYq x T s VYq x T VY x T s VY x T V On est assur dans ce cas quil ny a pas de problme : x lit une donne crite par r

Exemple 12.2 Excution en srie de

et

qui a ni de

Cela tant cette solution de concurrence zro nest pas viable : on ne peut se permettre de bloquer tous les utilisateurs sauf un, en attente dun programme qui peut durer extrmement longtemps. Heureusement lexcution en srie est une contrainte trop forte, comme le montre lexemple suivant. Exemple 12.3 Excution imbrique de r et

q(r T s Y V qvr T r V'r T s ' Vq x Ts Y Vq x T x ' V x T s V'r T r V' x T x V

x.

Suivons pas pas lexcution : 1. 2. 3. 4. 5. 6. 7.

pr r x x x r x

s r . Nb places vides : 50. crit s avec nb places = WF$tP . lit s . Nb places vides : 45. lit syx . crit s avec nb places = FA$tPd} . crit le nouveau compte du client r . crit le nouveaux compte du client x .
lit s et

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.

12.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 entane 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 :

q(r T s Y V qvr T r VYr T s V

190

CHAPITRE 12. INTRODUCTION LA CONCURRENCE DACCS

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 r T s V . 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. 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. Exemple 12.4 Les deux premires transactions ne sont pas correctes, la troisime lest ( signie ){)( d ). 1. 2. 3.

vce ,

q Ts Y V q T V' T s V T V q T s VYq T V' T s V) T V vYb '!v'!

Du point de vue de lexcution concurrente, cela soulve de nouveaux problmes qui sont illustrs cidessous.

12.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 12.5 (Excutions recouvrables).

vWvY(h'y'hvYyyYfdvYfdvWhh'$
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.

12.1. PRLIMINAIRES

191

Le problme ici vient du fait que la transaction est annule aprs que la transaction ait 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 MAJ 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 effectus par une transaction et les commit dune autre. On pourrait penser interdire une transaction ayant effectu des dirty read dune transaction de valider avant . On accepterait alors la situation suivante : Exemple 12.6 (Annulations en cascade).

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. 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 , puis quun donne 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 12.7 (Excution non stricte)

(vYvWyYWvYyvYydh'v'y'Wy'$ 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

vY ' vY vY Y ' y ' 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
Exemple 12.8 Cette fois cest qui annule et qui valide : ses mises--jour par la suite. Au moment o va annuler, le gestionnaire de transaction doit remettre la valeur du tuple au dbut de la transaction : ce qui revient annuler la mise--jour de . Autre exemple.

connue

v(vYvdh'hvYWv'dh'hvYfv'$kfy 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 .
1. Recouvrabilit : on ne doit pas avoir annuler une transaction dj valide.

En rsum, on distingue trois niveaux de recouvrabilit selon le degr de contrainte impos au systme :

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.

192

CHAPITRE 12. INTRODUCTION LA CONCURRENCE DACCS


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.

12.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. 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 12.1, 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 12.3. 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.

12.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 nots wl (comme write lock). Donc ( indique par exemple que la transaction a pos un verrou en lecture sur la 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. Denition 12.1 Deux verrous criture. 

et (d sont en conit si   ,    et ou ( est un verrou en

12.2. CONTRLE DE CONCURRENCE

193

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 : 1. Le scheduler reoit   et consulte le verrou dj pos sur , (

2.

le gestionnaire de donnes GD. 3. Ds que

 , sil existe. si  est en conit avec (d  , est retarde et la transaction est mise en attente. sinon, obtient le verrou  et lopration  est excute. Un verrou pour nest jamais relch avant la conrmation de lexcution par un autre module,
relche un verrou, elle ne peut plus en obtenir dautre.

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. Theorem 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). 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 12.9 (Non-respect de la rgle de relchement des verrous). Soit les deux transactions suivantes : 1. T : r [x]  2. T : w [x]  w [y]  w [y]  c c

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 : 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 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 12.10 (excution correcte)

(  

"!$#&%'%("!)%(

d j j d 

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 12.11 Une excution srialisable impossible par verrouillage r [x] w [x] c w0 [y] c0 r [y] w [z] c T relche rl[x] pour w 1 [x], mais a besoin ensuite de rl[y] pour r [y].

194

CHAPITRE 12. INTRODUCTION LA CONCURRENCE DACCS

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 12.12 Les deux transactions sont les suivantes :

2 )U d)U 2 d) 4U 3 Considrons maintenant que


phases :

et

sexcutent en concurrence dans le cadre dun verrouillage deux


"!8#9%'%("!)%(

( j  ( j j 56!7#&%'%("!)%( j
et

sont en attente lune de lautre : il y a interblocage (deadlock en anglais).

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. A titre dexercice, on peut reprendre le programme de rservation donn initialement, mais dans une version lgrement diffrente :

Programme RESERVATION2 Entre : Une sance @ Le nombre de places souhait ACBED$ #  @ Le client debut Lire la sance @ si (nombre de places libres FGAHBED$ #  @ ) Lire le compte du spectateur Dbiter le compte du client Soustraire ACBED$ #  @ au nombre de places vides Ecrire le compte du client Ecrire la sance @ nsi n 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. Exemple 12.13 Toujours avec le programme PIRQSIUTUVWYXPA . Chaque programme veut rserver des places dans la mme sance, pour deux clients distincts et .

a` @b' 9` bY 9` @"b' &` Y b c` @bY &` @bY &` Y b c` b


Sans verrou en lecture : on bloque mois

, mais la transaction nest plus srialisable.

12.3. GESTION DES TRANSACTIONS EN SQL

195

12.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 de et de , on vrie simplement que lordre du conit est compatible depqde ). Sinon on rejette la transaction qui veut effectuer avec lordre des transactions (i.e. fgih 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.

c` @b'  60 j  

12.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; 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.

196

CHAPITRE 12. INTRODUCTION LA CONCURRENCE DACCS

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

12.4

Exercices

Exercice 12.1 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.

12.4. EXERCICES

197

2. On a maintenant une excution concurrente de Places (C, M, 1500) et de Augmenter (SF, 1000), r tant un match qui se droule au Stade de France. Voici le dbut de lexcution 2 : H = 6s r 6sf QStj"u QSt vuf Qft wuyxx6x (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 ? 3. Soit lhistoire suivante, reprsentant deux excutions concurrentes du programme Places : Places (C, M, 100) et = Places (C, M, 200) pour le mme match et le mme client. H = (( Qujyd Qu v r vW  r hW r h  fd rj hd  (a) Montrer que H nest pas srialisable. (b) On suppose quil y a 1000 places prises dans r #&% 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.

2. lindice

dsigne S , iw&def .

198

CHAPITRE 12. INTRODUCTION LA CONCURRENCE DACCS

199

Chapitre 13

Travaux pratiques
Sommaire
13.1 Environnement . . . . . . . . . . . . . 13.1.1 Connexion au systme . . . . . . 13.1.2 Les commandes utiles . . . . . . 13.1.3 Utilisation de SQLPLUS . . . . 13.2 Requtes SQL . . . . . . . . . . . . . 13.2.1 Slections simples . . . . . . . . 13.2.2 Jointures . . . . . . . . . . . . . 13.2.3 Ngation . . . . . . . . . . . . . 13.2.4 Fonctions de groupe . . . . . . . 13.3 Concurrence daccs . . . . . . . . . . 13.4 Normalisation dun schma relationnel 13.5 gih)j Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 199 200 201 203 203 203 204 204 204 206 208

Ce petit document explique lessentiel de ce quil faut savoir pour les TP Oracle. Pour tout ce qui nest pas essentiel, lenseignant est l pour vous aider ! Commencez par lire en entier la section Connexion au systme avant de toucher la machine. Cela peut vous viter des ennuis. Ensuite, essayez de vous connecter en procdant lentement la premire fois. Une fois que vous tes connects et aue vous avez effectu votre premier ordre SQL, le plus dur est fait ! Dans ce qui suit, la partie Les commandes utiles vous explique les commandes UNIX de base : situer son rpertoire, diter un chier, obtenir la liste de ses chiers, etc. La partie Comment effectuer des requtes SQL donne quelques recommandations pour utiliser de manire optimale votre environnement de travail. Les subsections suivantes traitent du coeur du sujet : la base SQL et les exercices proposs. Bon courage !

13.1

Environnement

Prenez la peine de lire ceci jusqu la n sans toucher rien.

13.1.1

Connexion au systme

Sauf imprvu, vous tes face un terminal connect au rseau du CNAM. Vous disposez dun compte sur la machine du rseau qui sappelle celsius. Pour accder celsius, on procde comme suit : 1. Avec le bouton droite de la souris, on clique sur le fond de lcran.

200

CHAPITRE 13. TRAVAUX PRATIQUES

2. Un menu aparat, proposant entre autres le choix telnet : il faut activer ce choix. 3. On demande le nom de votre serveur : il faut taper celsius. Il peut y avoir quelques variantes en fonction de votre terminal, mais en exprimentant un peu, vous devez vous en tirer. Si tout sest bien pass, votre terminal communique avec celsius et vous demande votre nom (username), puis votre mot de passe. 1. Votre username est votre nom propre, limit aux 6 premires lettres, plus le caractre _ (soulign) , plus la premire lettre de votre prnom. Exemple : lauditeur Michel Platini a pour username platin_m. 2. Votre mot de passe gure sur votre carte CNAM. ATTENTION : il sagit du numro en haut gauche. Une fois connect, vous devez initialiser votre environnement ORACLE. Cela se fait avec la commande suivante : source ~rigaux/env_oracle Vous avez maintenant accs ORACLE en tapant la commande suivante : sqlplus / Attention : il y a un blanc aprs les sqlplus. SQLPLUS est lutilitaire dORACLE qui permet de soumettre directement des commandes SQL. Vous devriez normalement obtenir lafchage des messages suivants : SQL*Plus: Release 3.2.2.0.0 - Production on Mon Nov 24 12:16:03 1997 Copyright (c) Oracle Corporation 1979, 1994. All rights reserved.

Connected to: Oracle7 Server Release 8.0.1.0.0 - Production Release With the distributed option PL/SQL Release 2.2.3.0.0 - Production SQL> Il ne reste plus qu effectuer votre premire requte (attention au point-virgule la n de la commande) : SQL> select titre from film; Et voil ! Si quelque chose cloche et que vous ne comprenez pas pourquoi (aprs y avoir rchi ...) demandez lenseignant. Un bon truc pour nir : la touche CTRL-C interrompt une commande.

13.1.2

Les commandes utiles

La machine celsius fonctionne sous le systme dexploitation UNIX. Pas besoin dtre un expert pour les TP SQL. Voici juste quelques commandes qui peuvent savrer utiles. % % % % % % % % ls -l pwd cd rep cd cp source cible mv source cible nedit & netscape & // // // // // // // // Liste des fichiers du repertoire courant Nom du repertoire courant Se positionne dans le repertoire rep Ramene au repertoire de depart Copie le fichier source vers le fichier cible Renomme le fichier source en fichier cible Lance lediteur de texte nedit en tache de fond Lance netscape en tache de fond

13.1. ENVIRONNEMENT

201

Il est conseill de lancer nedit et netscpape. Le premier permet dditer trs facilement des chiers pour y saisir des requtes (ou autres) ; le deuxime donne accs au WEB et donc beaucoup dinformations, y compris le corrig du TP. Le fait de lancer un processus en tche de fond avec loption & siginie quil sexcute sans bloquer votre terminal.

13.1.3

Utilisation de SQLPLUS

Vous allez utiliser SQLPLUS pour excuter des commandes SQL de type DDL (cration de tables) et DML (recherche, mises--jour, ...). On peut entrer directement les commandes en les tapant sous SQLPLUS, mais en cas de faute de frappe ou derreur, il est difcile de corriger le texte. Il est donc fortement recommand de procder de la manire suivante : 1. Avec nedit, tapez votre commande, et sauvegardez-la dans un chier (par exemple, entrez select titre from film; dans nedit et enregistrez ce texte dans le chier req0.sql). 2. Sous SQLPLUS : demandez lexcution du chier req0.sql comme suit : SQL> @req0

3. Si quelque chose cloche, corrigez avec nedit, enregistrez le chier, et r-excutez-le. Crez ainsi un chier pour chaque commande : cel vous permettra de ne rien perdre et davoir un minimum de frappe clavier. Sous SQLPLUS, vous avez quelques commandes utiles dont voici une brve liste. SQL> desc tab SQL> select table_name from user_tables; SQL> list SQL> spool fic SQL> spool off SQL> exit; // Donne le schema de la table tab. // // // // // Liste des tables que vous avez creees. Affiche le dernier ordre execute Copie laffichage a lecran dans fic.lst Stoppe la copie dans fic.lst Sortir de SQLPLUS

Les commandes DROP TABLE permettent dexcuter le chier de cration plusieurs fois de suite, en dtruisant dabord les tables ventuellement cres lors des excutions prcdentes. Il faut dtruire les tables dans lordre inverse de cration, an de ne pas violer les contraintes de FOREIGN KEY. Au dpart, il ny a aucune table dans votre propre espace ORACLE, mais vous avez accs au schma et la base de donnes Ofciel des spectacles, vue et revue en cours, qui est partage (en lecture) par tout le monde. Voici les commandes qui ont tes utilises pour la cration du schma de cette base (attention : les tables existent dj, ne retapez pas les commandes de cration ci-dessous) : DROP DROP DROP DROP DROP DROP TABLE TABLE TABLE TABLE TABLE TABLE seance; salle; cinema; role; film; artiste; (Nom VARCHAR2 (20) NOT NULL, Prenom VARCHAR2 (15), Annee_naissance NUMBER(4) , PRIMARY KEY (Nom)); NUMBER(10) NOT NULL, VARCHAR2(30),

CREATE TABLE Artiste

CREATE TABLE film

(ID_film Titre

202

CHAPITRE 13. TRAVAUX PRATIQUES


Annee NUMBER(4), Nom_Realisateur VARCHAR2(20), PRIMARY KEY (ID_film), FOREIGN KEY (Nom_realisateur) REFERENCES Artiste);

CREATE TABLE Role

(Nom_role VARCHAR2(20) NOT NULL, ID_film NUMBER (10) NOT NULL, Nom_acteur VARCHAR2 (20) NOT NULL, PRIMARY KEY (ID_film, nom_acteur), FOREIGN KEY (ID_film) REFERENCES Film ON DELETE CASCADE, FOREIGN KEY (Nom_acteur) REFERENCES Artiste ON DELETE CASCADE); (Nom_cinema VARCHAR2 (10) NOT NULL, Arrondissement NUMBER (2), Adresse VARCHAR2 (30), PRIMARY KEY (Nom_cinema)); (Nom_cinema VARCHAR2(10) NOT NULL, No_salle NUMBER(2) NOT NULL, Climatise CHAR(1), Capacite NUMBER(4), PRIMARY KEY (Nom_cinema, No_salle), FOREIGN KEY (Nom_cinema) REFERENCES cinema ON DELETE CASCADE); (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 cinema

CREATE TABLE salle

CREATE TABLE seance

Vous pouvez remarquer que des hypothses simplicatrices ont t faites sur les cls de certaines tables : on admet par exemple que le nom du cinma est la cl pour un cinma. Ce nest certainement pas tout fait correct (cf. le cours sur le modle relationnel), mais cela permet de simplier les requtes. Remarques importantes : TOUTES LES COMMANDES SQL DOIVENT SE TERMINER PAR UN ;. Si vous oubliez le ;, une ligne 2 vous est propose. Dans ce cas tapez un ; pour nir la commande. Les chanes de caractres scrivent avec une simple quote : Vertigo et pas Vertigo. Les majuscules et les minuscules sont interprts diffremment. Par exemple Vertigo est considr comme diffrent de vertigo ou VERTIGO. Pensez-y en faisant des slections ! Un moyen dviter les probmes est dutiliser la fonctions UPPER qui met tout en majuscule. Par exemple : select * from film where UPPER(titre) = VERTIGO;

Sinon, vous pouvez vous baser sur la convention suivante : toutes les chanes de caractres commencent par une majuscule suivie de minuscules.

13.2. REQUTES SQL


Oracle nimplante que partiellement la norme SQL2. Voici quelques diffrences importantes : 1. La clause ON UPDATE .. nexiste pas.

203

2. La notion de schma se confond avec celle dutilisateur : toutes les tables (et les vues, contraintes, triggers, etc) cres par un mme utilisateur constituent un schma. 3. On ne peut pas utiliser de sous-requtes dans une clause CHECK. Maintenant, vous de jouer !

13.2

Requtes SQL

Quand vous vous connectez la base, vous avez automatiquement accs la base Ofciel des spectacles dont le schma a t prsent prcdemment. Cette base contient un petit jeu de donnes plus ou moins raliste. A vous de jouer : il faut concevoir, saisir et excuter les ordres SQL correspondant aux requtes suivantes.

13.2.1

Slections simples

1. Les titres de lms tris. 2. Nom et anne de naissance des artistes ns avant 1950. 3. Les cinmas du 12me arrondissement. 4. Les artistes dont le nom commence par H (commande LIKE). 5. Quels sont les acteurs dont on ignore la date de naissance ? (Attention : cela signie que la valeur nexiste pas). 6. Combien de fois Bruce Willis a-t-il jou le role de McLane ?

13.2.2

Jointures

1. Qui a jou Tarzan (nom et prnom) ? 2. Nom des acteurs de Vertigo. 3. Films dont le ralisateur est Tim Burton, et un des acteurs avec Jonnhy Depp. 4. Quels lms peut-on voir au Rex, et quelle heure ? 5. Titre des lms dans lesquels a jou Woody Allen. Donner aussi le rle. 6. Quel metteur en scne a tourn dans ses propres lms ? Donner le nom, le rle et le titre des lms. 7. Quel metteur en scne a tourn en tant quacteur ? Donner le nom, le rle et le titre des lms o le metteur en scne a jou. 8. O peut-on voir Shining ? (Nom et adresse du cinma, horaire).

204

CHAPITRE 13. TRAVAUX PRATIQUES

9. Dans quels lms le metteur-en-scne a-t-il le mme prnom que lun des interprtes ? (titre, nom du metteur-en-sc` ne, nom de linteprte). Le metteur-en-scne et linterprte ne doivent pas tre la mme personne. 10. O peut-on voir un lm avec Clint Eastwood ? (Nom et adresse du cinma, horaire). 11. Quel lm peut-on voir dans le 12e arrondissement, dans une salle climatise ? (Nom du cinma, No de la salle, horaire, titre du lm). 12. Liste des cinmas (Adresse, Arrondissement) ayant une salle de plus de 150 places et passant un lm avec Bruce Willis. 13. Liste des cinmas (Nom, Adresse) dont TOUTES les salles ont plus de 100 places.

13.2.3

Ngation

1. Quels acteurs nont jamais mis en scne de lm ? 2. Les cinmas (nom, adresse) qui ne passent pas un lm de Tarantino.

13.2.4

Fonctions de groupe

1. Total des places dans les salles du Rex. 2. Anne du lm le plus ancien et du lm le plus rcent. 3. Total des places offertes par cinma. 4. Nom et prnom des ralisateurs, et nombre de lms quils ont tourns. 5. klnm Nom des cinmas ayant plus de 1 salle climatise.
k lnm Les artistes (nom, prnom) ayant jou au moins dans trois lms depuis 1985, dont au moins un 6. passe a lafche a Paris (donner ausssi le nombre de lms).

13.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;

13.3. CONCURRENCE DACCS


2. MAJpas.sql PROMPT Augmentation du client Pascal =>; UPDATE client SET solde = solde + 1000 WHERE client = Pascal;

205

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 W9AHQ lexcution de linstruction W&AHQp par lutilisateur . Par exemple roVUpnq  corespond lexcution du chier MAJker dans la premire fentre par la commande @MAJker. On note de mme PXPr et UXUr 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 ?
QSIr "sQSIRr seroVUpnq  asQSIRr aseroVUpt # @9sQSIRr as PXPr seQSIr

S .

2. idem, mais avec des wdu8u$ % .


QSIr seQSIr sroVUpnq 

(sQfIrScsUXUrCasQSIr seroVUpnq  v asQSIsUXUrCsQSIRrS .

3. Maintenant les deux utilisateurs effectuent des MAJ simultanes.


QSIr

sQSIr

sroVpnq 

seroVUpt # @

seQSI

sQSIr

sroVpnvwd"x

sroVpnvwd"x

sQSIRr

k s UXUr k s UXUr .

Un bloquage est apparu. Pourquoi ? 4. Idem, avec un ordre des oprations qui diffre dun utilisateur lautre.
QSIRr

seQSIr

sroVp4q 

seroVUpt # @

sQfI

seQSIr

sroVUpt # @

sroVUpnq 

UXPr PXPr .

Que constate-t-on ? 5. k lnm 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;

206

CHAPITRE 13. TRAVAUX PRATIQUES


Chaque ligne slectionne est alors verrouille. Refaites les expriences prcdentes avec un verrouillage explicite des lignes que vous voulez modier.

6. klnm Exprimentez les excutions cdentes en spciant le mode suivant : SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

13.4

Normalisation dun schma relationnel

On va maintenant crer des tables, y insrer des informations et effectuer des requtes sur le schma obtenu. Lapplication vise est le systme dinformation dun zoo, et on suppose que lon se trouve dans la situation suivante : une personne peu avertie (elle na pas suivi les enseignements du CNAM !) a cr en tout et pour tout une seule table dans laquelle on trouve toutes les informations. Voici le schma de cette table. CREATE TABLE Zoo (Animal Nom Annee_naissance Espece Gardien Prenom Salaire Classe Origine Emplacement Surface Type_empl Libelle_empl Number(4), VARCHAR2 (20), NUMBER(4), VARCHAR2(10), VARCHAR2 (20), VARCHAR2 (10), NUMBER (10,2), VARCHAR2 (10), VARCHAR2 (10), NUMBER(4), NUMBER (3), NUMBER(2), VARCHAR2 (20));

Chaque ligne corrrespond un animal auquel on attribue un nom propre, une anne de naissance et une espce (Ours, Lion, Boa, etc.). Cet animal est pris en charge par un gardien (avec prnom et salaire) et occupe un emplacement dans le zoo (numro demplacement, surface, type_emplacement et libell_emplacement : savane, dsert, fort, etc.). Enn chaque espce appartient une classe (les mammifres, poissons, reptiles, batraciens ou oiseaux) et on considre pour simplier quelle provient dune origine unique (Afrique, Europe, etc.). Vous pouvez consulter avec SQL le contenu de cette table Zoo qui vous est acessible en lecture. On constate loeil nu de nombreuses redondances et anomalies (les voyez-vous ?). Commencez par copier la table chez vous avec la commande suivante : CREATE TABLE zoo AS SELECT * FROM zoo; Le schma nest videmment pas correct : on ny trouve mme pas de contraintes (NOT NULL) ou de dnition de cl primaire. Le premier travail est donc de dnir un bon schma relationnel. Pour cela, on vous donne les spcications suivantes, sous forme de dpendances fonctionnelles : Animal  Nom, Anne_naissance, Espce, Emplacement. Animal.

Nom, Espce  Espce  Gardien 

Origine, Classe. Prnom, Salaire. Surface, Type_emplacement, Gardien.

Emplacement 

13.4. NORMALISATION DUN SCHMA RELATIONNEL


Type_emplacement  Questions Libell_emplacement.

207

1. Le contenu actuel de la table est-il conforme ces spcications ? Indication : pour chaque dpendance fonctionnelle Vyqz , o z est un attribut, excutez lordre SQL SELECT A, count(DISTINCT B) FROM zoo GROUP BY A; Si la table respecte la DF, count(*) doit valoir x6xx ( votre avis ?). Vous pouvez donc chercher les anomalies en ajoutant un HAVING COUNT (DISTINCT B) >... la requte ci-dessus. 2. Effectuez les corrections ncessaires avec des ordres UPDATE. Quand il y a une anomalie ou une incohrence entre deux lignes, on considre que la premire est la bonne. IMPORTANT : on valide une mise--jour avec la commande commit;. 3. Montrer que Animal et Nom, Espce sont des cls de la table Zoo ? 4. klnm Montrer que ce sont les seules cls. 5. Est-elle en troisime forme normale (donnez un argument formel) ? Y-a-t-il des redondances/anomalies prvisibles ? Les retrouvez-vous dans la table Zoo ? 6. Trouvez un schma en troisime forme normale, crez les ordres CREATE TABLE correspondant (avec des contraintes PRIMARY KEY, FOREIGN KEY NOT NULL, UNIQUE) et excutez-les. ATTENTION : une table laquelle on fait rfrence dans un FOREIGN KEY doit avoir t cre avant. Il faut donc faire attention lordre de cration des tables. 7. Une fois le schma cr, insrez les donnes dans les tables du bon schma en les copiant partir de la table Zoo. Pour copier des donnes dune table A vers une table B(B1,B2, ... Bn) , SQL fournit une commande qui est un mlange de SELECT et de INSERT. INSERT INTO TABLE B (B1, B2, ... Bn) SELECT DISTINCT A1, A2, ... An FROM A WHERE ...;

En fait lordre SELECT peut accder plusieurs tables (jointures, diffrences). Contrainte importante : il doit y avoir autant de Ai que de Bi, et pour les mmes types. Exemple : INSERT INTO ESPECE (espece, classe, origine) SELECT DISTINCT espece, classe, origine FROM zoo; Vous devez maintenant avoir un bon schma et un mauvais (la table Zoo toute seule). Sur ces deux schmas, exprimez les requtes SQL qui suivent. 1. Quels sont les Ours du zoo ? 2. Quels animaux sappellent Martin ? 3. Quels animaux habitent dans la jungle ? 4. De quels animaux soccupe le gardien Dupond ?

208

CHAPITRE 13. TRAVAUX PRATIQUES

5. rentes (no, surface et libell du type k lnm Sur quel(s) emplacement(s) y-a-il des animaux de classes diff de lemplacement). 6. Somme des salaires des gardiens. 7. ... Considrons les anomalies qui existaient initialement : sont-elles encore possibles dans le bon schma. Dun autre ct, y-a-t-il des requtes que lon peut exprimer sur Zoo et pas sur le nouveau schma ? (autrement dit : a-t-on perdu de linformation ?) Conclusion : qua-t-on gagn, qua-t-on perdu ?
`e{ b

13.5

Optimisation

ORACLE fournit sous SQLPLUS un outil, EXPLAIN, qui donne une description du plan dexcution choisi par le systme pour une requte quelconque. EXPLAIN est trs simple utiliser. Il fonctionne de la manire suivante : 1. Tout dabord on cre une table, plan_table, qui est destine contenir toutes les informations relatives un plan dexcution. La table doit tre cre avec le chier de commandes plan_table.sql 1. 2. Ensuite on excute une requte en demandant le stockage des explications relatives cette requte. Exemple : EXPLAIN PLAN SET statement_id = cin0 FOR SELECT titre, heure_debut FROM seance s, film f WHERE s.id_film = f.id_film AND f.titre=Vertigo; La clause statement_id = cin0 attribue un identiant au plan dexcution de cette requte dans la table plan_table. Bien entendu chaque requte stocke dans plan_table doit avoir un identiant spcique. 3. 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 au mme endroit que prcdemment). Quand on excute ce chier, il demande (2 fois) le nom de la requte expliquer. Dans le cas de lexemple ci-dessus, on rpondrait deux fois cin0. On obtient lafchage suivant qui prsente de manire relativement claire le plan dexcution (cf. le cours). Plan dexecution --------------------------------------------------------------------------0 SELECT STATEMENT 1 NESTED LOOPS 2 TABLE ACCESS FULL SEANCE 3 TABLE ACCESS BY ROWID FILM 4 INDEX UNIQUE SCAN SYS_C004709 Ici, le plan dexcution est le suivant : on parcourt en squence la table SEANCE (ligne 2) ; pour chaque sance, on accde la table FILM par lindex 2 (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).
1. Vous pouvez rcuprer ce chier en le copiant avec la commande suivante : /users/ensinf/rigaux/PUBLIC/utlxplan.sql . 2. Cet index a t automatiquement cr en association avec la commande PRIMARY KEY lors de la cration de la table. cp

13.5. klnm OPTIMISATION


Questions

209

1. Reprendre les requtes dnies au dbut du TP sur la base de donnes Ofciel des Spectacles, et expliquer le plan dexcution donn par ORACLE. 2. Supprimer quelques index, et regarder le changement dans les plans dexcutions. NB : vous pouvez obtenir la liste des index existant sur vos tables avec la commande : SELECT table_name, index_name FROM user_indexes;