Requêtez une base de données avec SQL

Voilà, vous connaissez maintenant les opérations les plus utilisées en SQL (tout au moins pour les requêtes de type SELECT).

Vous verrez, c'est très puissant. Mais… comme dit l'adage, “À grand pouvoir, grandes responsabilités”. En effet, il ne faut pas faire n'importe quoi quand vous écrivez une requête !

Identifiez l'importance des clés

Connaître au moins une clé candidate par table, c'est très important.

Pourquoi ? Parce qu'elles déterminent la nature des objets que vous représentez dans une table.

On voit cela tout de suite en pratique !

Voilà, maintenant que vous savez qu'il est important de connaître ses clés primaires potentielles, voyons comment les déterminer.

Déterminez les potentielles clés primaires après chaque opération

Quand on interroge une BDD avec des requêtes qui commencent par SELECT, une seule requête ne suffit pas. En effet, on est souvent amené à effectuer plusieurs opérations à la suite, comme par exemple des jointures ou des filtrages. C'est ce que vous faites quand vous imbriquez des requêtes les unes dans les autres (souvenez-vous, nous avons déjà vu cela !)

Eh bien, à chaque résultat intermédiaire que vous obtiendrez, il faudra vous poser la question de la clé primaire.

Heureusement, vous ne devez pas spécifier au SGBDR la clé primaire de chaque résultat intermédiaire, mais posez-vous cette question à chaque fois : « Quelle serait la potentielle clé primaire que je donnerais à cette table si je devais l'enregistrer dans la BDD ?».

Vous pouvez tout à fait utiliser la méthode que l'on a vue précédemment dans le chapitre sur les clés primaires, en trouvant un groupe de colonnes unique et minimal.

Mais il y a quelques règles qui permettent d'aller plus vite :

Le SELECT

Commençons par le cas du SELECT : quand vous sélectionnez quelques colonnes avec un SELECT, si parmi les colonnes que vous sélectionnez, il y a une potentielle clé primaire, alors cette clé peut être la clé primaire de votre résultat, c'est facile !

Mais si parmi les colonnes que vous sélectionnez, il n'y a pas de potentielle clé primaire, alors votre résultat… n'aura pas de clé primaire possible ! Vous aurez donc potentiellement des doublons dans la table. En général, les doublons, c’est problématique.

Le WHERE

Passons maintenant au WHERE, quand vous filtrez des lignes selon une condition.

Dans la plupart des cas, le WHERE ne modifie pas la clé primaire, sauf dans certains cas particuliers, où, une fois le filtrage appliqué, la clé primaire sera simplifiable.

Simplifiable ça veut dire que, si vous avez, avant le filtrage, une clé composée de 2 colonnes, par exemple, eh bien après le filtrage, vous pouvez ne garder qu'une colonne sur les 2 dans votre nouvelle clé primaire.

Alors, pour différencier si vous êtes dans le cas où la clé ne change pas, ou bien dans le cas où la clé est simplifiable après un WHERE, il n'y a pas vraiment de règle ; il faudra utiliser la bonne vieille méthode à laquelle vous êtes habitué : trouver un groupe unique et minimal.

Le FROM

Quand vous faites un produit cartésien entre 2 tables, (donc avec un FROM), alors la table résultante peut avoir comme clé primaire le regroupement des clés primaires des 2 tables.

La jointure

Pour la jointure, ça va dépendre.

Rappelez-vous qu'une jointure entre A  et B  , c'est un produit cartésien puis un filtrage avec un WHERE.

1. Tout d'abord, le produit cartésien nous donne une nouvelle clé primaire composée du regroupement des clés de A  et B  .

2. Mais quand on va appliquer le WHERE, eh bien dans certains cas, la clé sera simplifiable, et dans d'autres non.

Vous allez voir, suivez mon raisonnement !

Quand on fait une jointure, c'est très très souvent d'une clé étrangère d'une table A  vers une potentielle clé primaire d'une table B  . 

• Si c'est le cas, alors la table que vous obtiendrez après la jointure pourra avoir comme clé primaire la même clé primaire que la table A  , et c'est tout ! Ici, c'est le cas où le WHERE a simplifié la clé primaire.

• Le cas contraire se retrouve beaucoup plus rarement lors d'une jointure. C'est le cas où on fait une jointure de A  vers un groupe de colonnes de B  qui n'est pas unique (donc qui ne peut pas être clé primaire de B  ). Dans ce cas, le résultat de votre jointure a comme clé primaire le regroupement des 2 clés primaires des 2 tables. En fait, c'est ce que nous avait donné le produit cartésien initial ; le WHERE n'a rien simplifié du tout. 

Si vous êtes dans ce cas plus rare, c'est possible, mais vérifiez bien que vous n'avez pas fait d'erreur de raisonnement, par exemple en comptant le nombre de lignes, comme on va le voir juste après.

Comptez les lignes après vos jointures

Bien connaître ses clés, c'est également très important lors des jointures.

En général, on effectue une jointure :

• d'une clé étrangère d'une table A  ...

• .... vers une potentielle clé primaire d'une table B  .

Dans ce cas, le nombre de lignes de la table que vous obtiendrez aura :

• autant, ou moins de lignes que A  si vous faites une jointure interne ;

• autant de lignes que A  si vous faites une jointure externe à gauche (avec A  à gauche).

À la fin de votre jointure, pensez bien à compter le nombre de lignes.

En règle générale, dans votre condition de jointure de ce type :

A.cle_étrangere = B.cle_primaire

... assurez-vous qu'au moins l'un des 2 termes de part et d'autre du =  soit une potentielle clé primaire.

Si ce n'est pas le cas, ce n'est pas interdit, mais vérifiez bien que vous ne faites pas une erreur de raisonnement. Soyez sûr que c'est ce dont vous avez vraiment besoin. Surtout, vérifiez bien la table finale en termes de cohérence, et surtout en termes de nombre de lignes.

En résumé

• À chaque nouvelle table, déterminez une potentielle clé primaire ! Vous saurez ainsi ce que représente une ligne.

• Déterminez les potentielles clés primaires après chaque opération.

• À la suite d'une jointure, vérifiez bien le nombre de lignes obtenues.

Voilà ! Vous savez maintenant manier à merveille les requêtes SELECT. Mais pour notre enquête, cela ne suffit pas encore. Nous aurons besoin d'apprendre de nouvelles fonctionnalités pour nos requêtes.