1

OPTIMISATION DE QUESTIONS

1. INTRODUCTION
La plupart des SGBD relationnels offrent aujourd’hui des langages de manipulation basés sur SQL, non procéduraux et utilisant des opérateurs ensemblistes. Avec de tels langages, l’utilisateur définit les données qu’il veut visualiser sans fournir les algorithmes d’accès aux données. Le but des algorithmes d’optimisation de questions est justement de déterminer les algorithmes d’accès. Ces algorithmes sont aussi utiles pour les mises à jour, car une mise à jour est une question suivie d’un remplacement.
Plus précisément, il s’agit d’élaborer un programme d’accès composé d’opérations de bas niveau attachées à des algorithmes efficaces de recherche dans les tables. Il est essentiel pour un système de déterminer des plans d’accès optimisés — ou au moins proches de l’optimum — pour les questions les plus fréquentes. Ce n’est pas là un problème facile, comme nous allons le voir dans ce chapitre.
Depuis les années 1975, l’optimisation de requêtes dans les bases de données relationnelles a reçu une attention considérable [Jarke84, Kim85, Graefe93]. Les systèmes ont beaucoup progressé. Alors que les premiers étaient très lents, capables seulement d’exécuter quelques requêtes par seconde sur les bases de données du benchmark TPC/A ou B [Gray91], ils supportent aujourd’hui des milliers de transactions par seconde. Bien sûr, cela n’est pas dû seulement à l’optimiseur, mais aussi aux progrès du matériel (les temps d’entrée-sortie disque restent cependant de l’ordre de la dizaine de millisecondes) et des méthodes d’accès. L’optimiseur est donc un des composants essentiels du SGBD relationnel ; avec les nouveaux SGBD objetrelationnel ou objet, il devient encore plus complexe. Dans ce chapitre, nous nous consacrons au cas relationnel. Nous étudierons plus loin dans cet ouvrage le cas des nouveaux SGBD, où l’optimiseur doit être extensible, c’est-à-dire capable de supporter des opérateurs non prévus au départ.