Le langage SQL est déclaratif : l'utilisateur indique ce qu'il veut, mais il ne s'occupe pas de comment l'obtenir. C'est au système de chercher comment accéder aux données, quelles sont les différentes solutions, et quelle est la meilleure.
Exemple :
select ue.* from diplome natural join unite_enseignement where nb_etudiants>100;
Cette requête retourne 70 enregistrements. Il y a 28 diplomes, 271 unites d'enseignement, et 3 diplomes avec plus de 100 étudiants inscrits. Chaque unite d'enseignement concerne un seul diplome.
Soit
Pour l'optimisation : on utilise les règle de réécriture autorisées par les propriétés de l'algèbre relationnelle.
Ainsi, on favorisera les sélections à un niveau bas, car cet opérateur est considéré comme plus réducteur, tandis que les produits sont remontés le plus tard possible (le plus haut dans l'arbre de la requête).
Est-ce que cela est toujours vrai?
Prenons un exemple :
(base bibliothèque) Quelles sont les oeuvres dont un exemplaire a été acheté il y a plus d'un mois et dont l'auteur est Pierre Bourdieu?
select o.titre
from livre l , oeuvre o
where l.date_achat+ cast('1 month' as interval)<current_date
and o.id_oeuvre = l.id_oeuvre
and o.auteur = 'Pierre Bourdieu';
La table Livre : 1500 enregistrements, la table oeuvre : 300 enregistrements. 98% des achats ont plus d'un mois, et seulement 30% des oeuvres ont un exemplaire à la bibliothèque. Il y a 3 titres de Pierre Bourdieu dans la bibliothèque, en 2 exemplaires chacun, qui ont tous été achetés il y a plus d'un mois.
1ère solution (2 sélections puis une jointure) :
Total : 1500 + 1470 + 300 + 3 + 4410 + 3 = 7686 E/S
2ème solution (1 sélection, 1 jointure puis 1 sélection) :
Total : 300 + 3 + 4500 + 6 + 6 + 6 = 4821 E/S
Il s'agit d'un cas où une jointure est plus réductrice qu'une sélection!
Ce cas est rare, mais il illustre bien le fait qu'une bonne optimisation ne peut pas se contenter d'une réécriture algébrique. L'optimiseur tient compte