Clés primaires et étrangères
Maintenant que les index n'ont plus de secret pour vous, nous allons passer à une autre notion très importante : les clés.
Les clés sont, vous allez le voir, intimement liées aux index. Et tout comme NOT NULL et les index UNIQUE, les clés font partie
de ce qu'on appelle les contraintes.
Il existe deux types de clés :
les clés primaires, qui ont déjà été survolées lors du chapitre sur la création d'une table, et qui servent à identifier une
ligne de manière unique ;
les clés étrangères, qui permettent de gérer des relations entre plusieurs tables, et garantissent la cohérence des
données.
Il s'agit à nouveau d'un chapitre avec beaucoup de blabla, mais je vous promets qu'après celui-ci, on s'amusera à nouveau ! Donc
un peu de courage.
Clés primaires, le retour
Les clés primaires ont déjà été introduites dans le chapitre de création des tables. Je vous avais alors donné la définition
suivante :
La clé primaire d'une table est une contrainte d'unicité, composée d'une ou plusieurs colonnes, et qui permet d'identifier de
manière unique chaque ligne de la table.
Examinons plus en détail cette définition.
Contrainte d'unicité : ceci ressemble fort à un index UNIQUE.
Composée d'une ou plusieurs colonnes : comme les index, les clés peuvent donc être composites.
Permet d'identifier chaque ligne de manière unique : dans ce cas, une clé primaire ne peut pas être NULL.
Ces quelques considérations résument très bien l'essence des clés primaires. En gros, une clé primaire est un index UNIQUE sur
une colonne qui ne peut pas être NULL.
D'ailleurs, vous savez déjà que l'on définit une clé primaire grâce aux mots-clés PRIMARY KEY. Or, nous avons vu dans le
précédent chapitre que KEY s'utilise pour définir un index. Par conséquent, lorsque vous définissez une clé primaire, pas besoin
de définir en plus un index sur la (les) colonne(s) qui compose(nt) celle-ci, c'est déjà fait ! Et pas besoin non plus de rajouter une
contrainte NOT NULL
Pour le dire différemment, une contrainte de clé primaire est donc une combinaison de deux des contraintes que nous avons vues
jusqu'à présent : UNIQUE et NOT NULL.
Choix de la clé primaire
Le choix d'une clé primaire est une étape importante dans la conception d'une table. Ce n'est pas parce que vous avez
l'impression qu'une colonne, ou un groupe de colonnes, pourrait faire une bonne clé primaire que c'est le cas. Reprenons
l'exemple d'une table Client, qui contient le nom, le prénom, la date de naissance et l'email des clients d'une société.
Chaque client a bien sûr un nom et un prénom. Est-ce que (nom, prenom) ferait une bonne clé primaire ? Non bien sûr : il est
évident ici que vous risquez des doublons.
Et si on ajoute la date de naissance ? Les chances de doublons sont alors quasi nulles. Mais quasi nul, ce n'est pas nul…
Qu'arrivera-t-il le jour où vous voyez débarquer un client qui a les mêmes nom et prénom qu'un autre, et qui est né le même jour ?
On refait toute la base de données ? Non, bien sûr.
Et l'email alors ? Il est impossible que deux personnes aient la même adresse email, donc la contrainte d'unicité est respectée. Par
contre, tout le monde n'est pas obligé d'avoir une adresse email. Difficile donc de mettre une contrainte NOT NULL sur cette
colonne.
Par conséquent, on est bien souvent obligé d'ajouter une colonne pour jouer le rôle de la clé primaire. C'est cette fameuse
colonne id , auto-incrémentée que nous avons déjà vue pour la table Animal.
Il y a une autre raison d'utiliser une colonne spéciale auto-incrémentée, de type INT (ou un de ses dérivés) pour la clé primaire.
En effet, si l'on définit une clé primaire, c'est en partie dans le but d'utiliser au maximum cette clé pour faire des recherches dans la
table. Bien sûr, parfois ce n'est pas possible, parfois vous ne connaissez pas l'id du client, et vous êtes obligés de faire une
recherche par nom. Cependant, vous verrez bientôt que les clés primaires peuvent servir à faire des recherches de manière
indirecte sur la table. Du coup, comme les recherches sont beaucoup plus rapides sur des nombres que sur des textes, il est
souvent intéressant d'avoir une clé primaire composée de colonnes de type INT.
Enfin, il y a également l'argument de l'auto-incrémentation. Si vous devez remplir vous-mêmes la colonne de la clé primaire, étant
Partie 2 : Index, jointures et sous-requêtes
89/414
www.openclassrooms.com
Maintenant que les index n'ont plus de secret pour vous, nous allons passer à une autre notion très importante : les clés.
Les clés sont, vous allez le voir, intimement liées aux index. Et tout comme NOT NULL et les index UNIQUE, les clés font partie
de ce qu'on appelle les contraintes.
Il existe deux types de clés :
les clés primaires, qui ont déjà été survolées lors du chapitre sur la création d'une table, et qui servent à identifier une
ligne de manière unique ;
les clés étrangères, qui permettent de gérer des relations entre plusieurs tables, et garantissent la cohérence des
données.
Il s'agit à nouveau d'un chapitre avec beaucoup de blabla, mais je vous promets qu'après celui-ci, on s'amusera à nouveau ! Donc
un peu de courage.
Clés primaires, le retour
Les clés primaires ont déjà été introduites dans le chapitre de création des tables. Je vous avais alors donné la définition
suivante :
La clé primaire d'une table est une contrainte d'unicité, composée d'une ou plusieurs colonnes, et qui permet d'identifier de
manière unique chaque ligne de la table.
Examinons plus en détail cette définition.
Contrainte d'unicité : ceci ressemble fort à un index UNIQUE.
Composée d'une ou plusieurs colonnes : comme les index, les clés peuvent donc être composites.
Permet d'identifier chaque ligne de manière unique : dans ce cas, une clé primaire ne peut pas être NULL.
Ces quelques considérations résument très bien l'essence des clés primaires. En gros, une clé primaire est un index UNIQUE sur
une colonne qui ne peut pas être NULL.
D'ailleurs, vous savez déjà que l'on définit une clé primaire grâce aux mots-clés PRIMARY KEY. Or, nous avons vu dans le
précédent chapitre que KEY s'utilise pour définir un index. Par conséquent, lorsque vous définissez une clé primaire, pas besoin
de définir en plus un index sur la (les) colonne(s) qui compose(nt) celle-ci, c'est déjà fait ! Et pas besoin non plus de rajouter une
contrainte NOT NULL
Pour le dire différemment, une contrainte de clé primaire est donc une combinaison de deux des contraintes que nous avons vues
jusqu'à présent : UNIQUE et NOT NULL.
Choix de la clé primaire
Le choix d'une clé primaire est une étape importante dans la conception d'une table. Ce n'est pas parce que vous avez
l'impression qu'une colonne, ou un groupe de colonnes, pourrait faire une bonne clé primaire que c'est le cas. Reprenons
l'exemple d'une table Client, qui contient le nom, le prénom, la date de naissance et l'email des clients d'une société.
Chaque client a bien sûr un nom et un prénom. Est-ce que (nom, prenom) ferait une bonne clé primaire ? Non bien sûr : il est
évident ici que vous risquez des doublons.
Et si on ajoute la date de naissance ? Les chances de doublons sont alors quasi nulles. Mais quasi nul, ce n'est pas nul…
Qu'arrivera-t-il le jour où vous voyez débarquer un client qui a les mêmes nom et prénom qu'un autre, et qui est né le même jour ?
On refait toute la base de données ? Non, bien sûr.
Et l'email alors ? Il est impossible que deux personnes aient la même adresse email, donc la contrainte d'unicité est respectée. Par
contre, tout le monde n'est pas obligé d'avoir une adresse email. Difficile donc de mettre une contrainte NOT NULL sur cette
colonne.
Par conséquent, on est bien souvent obligé d'ajouter une colonne pour jouer le rôle de la clé primaire. C'est cette fameuse
colonne id , auto-incrémentée que nous avons déjà vue pour la table Animal.
Il y a une autre raison d'utiliser une colonne spéciale auto-incrémentée, de type INT (ou un de ses dérivés) pour la clé primaire.
En effet, si l'on définit une clé primaire, c'est en partie dans le but d'utiliser au maximum cette clé pour faire des recherches dans la
table. Bien sûr, parfois ce n'est pas possible, parfois vous ne connaissez pas l'id du client, et vous êtes obligés de faire une
recherche par nom. Cependant, vous verrez bientôt que les clés primaires peuvent servir à faire des recherches de manière
indirecte sur la table. Du coup, comme les recherches sont beaucoup plus rapides sur des nombres que sur des textes, il est
souvent intéressant d'avoir une clé primaire composée de colonnes de type INT.
Enfin, il y a également l'argument de l'auto-incrémentation. Si vous devez remplir vous-mêmes la colonne de la clé primaire, étant
Partie 2 : Index, jointures et sous-requêtes
89/414
www.openclassrooms.com