Leçon 13 : La clé primaire (L'identifiant)

Temps nécessaire pour suivre cette leçon : Une petite demie heure

Pour suivre cette leçon, vous devez avoir suivi les leçons précédentes. Ou plus précisément, vous devez être en possession de la base de données ProFormation.mdb telle qu'elle était à la fin de la leçon précédente. Si vous n'êtes pas certain de l'avoir, vous pouvez la télécharger ici

Aperçu de cette leçon

Dans cette leçon, nous allons parler de la clé primaire : Pourquoi, comment ? En fait, le terme "Clé primaire" a été traduit de l'anglais littéralement (Primary Key). La traduction la plus correcte en français serait "Identifiant".

Sommaire

  1. Application d'une clé primaire à un champ
  2. Un seul enregistrement vide empêche la clé primaire
  3. Erreurs de doublons lors de l'application d'une clé primaire
  4. Visualisation de l'impossibilité de créer des doublons sur une clé primaire
  5. Application d'une clé primaire composée (Sur plusieurs champs)
  6. Création d'un champ qui servira de clé primaire (Appelé Index)
  7. Type de données : NuméroAuto : Particularités
  8. Trous de numérotation inhérents à l'utilisation d'un NuméroAuto
  9. La clé primaire est-elle indispensable ?
  10. Création automatique de clés primaires

Il y a une chose qui me tracasse : à partir d'un certain nombre de clients, j'ai peur d'entrer par erreur une 2ème fois un client qui existe déjà...

Je comprend : Ouvrez la table T_Client en mode Saisie de données, et entrez, exprès, 2 fois le même client : Amélie Miresmo : . Evidemment c'est une erreur évidente parce que nous les avons entrées juste l'une en dessous de l'autre... Mais si elles sont séparées par 1000 autres clients, c'est plus délicat ! Comment empêcher ça ?

Application d'une clé primaire à un champ

Revenez dans la table en mode création, et cliquez sur NomClient, puis cliquez sur la petite clé : . ça donne pour résultat d'afficher cette petite clé à gauche du champ : On dit alors en termes techniques que "Le champ NomClient est défini en Clé Primaire" - ou que "NomClient est l'Identifiant de la table T_Client". ça veut simplement dire qu'il va être à présent STRICTEMENT IMPOSSIBLE d'avoir 2 fois le même nom de client ! Eh oui... Mais... C'est ce que nous venons de faire ! Et exprès en plus ! Nous avons installé deux Amélie Miresmo, et ensuite nous définissons le champ NomClient en Clé Primaire ! On ne manque pas de toupet !!!

Que va dire Access ? Eh bien il ne va pas du tout être d'accord ! Essayez : Cliquez sur pour aller en mode saisie de données. Comme d'habitude, Access va vous prévenir que la table "Doit être enregistrée"... Répondez oui (Pas le choix), et c'est maintenant qu'il se fâche : . Cliquez sur OK, vous aurez ce 2ème message d'erreur : . (Ce qui veut dire qu'il ne veut rien savoir :Votre clé primaire, il n'en veut pas !) Cliquez sur OK.

Un seul enregistrement vide empêche la clé primaire

Tiens ! "Ne peut contenir une valeur Null" ! Qu'est-ce que ce message a à voir avec le fait que nous avons deux Amélie Miresmo ???

La clé primaire, en plus de ne pas accepter les Doublons (2 fois le même nom de client), n'accepte non plus pas qu'un client n'ait pas de nom ! Si vous avez cent mille clients, et qu'UN SEUL n'a pas de nom, alors, il sera IMPOSSIBLE de définir une clé primaire/identifiant sur ce champ !

Mais comment puis-je faire alors ? Si Access m'empêche d'aller en mode saisie de données pour mettre des noms à tout le monde, je suis bloqué !

Non. Pas tant que ça, restons logiques : Voici comment vous allez procéder:

  1. Vous allez retirer la clé primaire de NomClient : C'est à dire que vous allez cliquer sur NomClient, et RE-cliquer sur la petite clé : Ca l'enlèvera. Quand on clique sur cette petite clé , une fois ça la met, une autre fois ça l'enlève.
  2. Lancez la table en mode saisie de données (Vous pouvez, maintenant que vous avez retiré la clé primaire !)
  3. Mettez un nom à Juliette :
  4. Supprimez Colushe et Roméo (Cliquez bien ici , et appuyez sur Delete)

Votre table ne devrait maintenant plus contenir QUE des enregistrements qui contiennent CHACUN un nom ET un prénom. : , à part bien sûr la dernière ligne qui est complètement vide, mais vous savez que c'est parce qu'il ne s'agit pas d'un enregistrement, c'est une nouvelle ligne pour pouvoir justement entrer un nouvel enregistrement. Celle ligne ne peut pas évidemment pas s'effacer.

Je replace la clé primaire sur le nom, maintenant ?

Erreurs de doublons lors de l'application d'une clé primaire

Oui. Vous revenez en mode création, et vous remettez la clé primaire sur le nomclient. Relancez ensuite encore une fois la table en mode saisie de données. Access va donc encore vous prévenir qu'il doit enregistrer la table. Dites oui, et cette fois, c'est ce message d'erreur que vous obtenez : .

Eh oui : N'oubliez pas qu'à la base, nous avons voulu définir une clé primaire sur NomClient pour empêcher les doublons ! Ce message est plus explicite : "Risque de doublons dans champs Index, clé principale ou relation interdisant les doublons"... En gros, tant que vous avez deux personnes qui s'appellent Miresmo (même si elles ont des prénoms différents), la clé primaire (Clé principale - identifiant : Ce sont des synonymes) ne sera PAS applicable !

Logique ! Implacable logique ! Que fait-on alors ?

Vous devriez voir venir l'astuce :

  1. On enlève la clé primaire de NomClient
  2. On lance la table en mode saisie de données
  3. On supprime la 2ème Amélie Miresmo
  4. On revient en mode création
  5. On remet la clé primaire sur NomClient
  6. On relance la table en mode saisie de données
  7. On dit "Oui" quand Access nous informe que la table doit être enregistrée
    SUSPENSE...
  8. OUI ! ça marche ! Vous êtes dans votre table en mode saisie de données AVEC la clé primaire sur NomClient !!!

Allez-y, faites-le !

C'est bizarre, il a changé l'ordre de mes clients...

Disons plus exactement qu'il les a rangé par ordre alphabétique

Et si je voulais les retrouver dans l'ordre dans lequel je les ai rentrés ?

Ici, c'est fichu. On ne peut plus. Mais, entre nous, est-ce vraiment important ?

Visualisation de l'impossibilité de créer des doublons sur une clé primaire

Non pas vraiment en fait parce que de toutes façons, je peux les trier comme je veux. Et maintenant, si on essaie d'entrer une 2ème fois Amélie Miresmo ?

Access va vous envoyer sur les roses. Essayez : . Il accepte, c'est vrai... Mais il n'a pas encore enregistré: Souvenez vous du petit crayon (). Dès que vous allez enregistrer - par exemple en descendant d'un enregistrement - alors, vous aurez instantanément ce message d'erreur :

Cliquez sur OK, et vous revenez à cet état : access va vous laisser affiché la 2ème Amélie Miresmo, mais il va refuser de l'enregistrer ! Vous ne pouvez plus rien faire : Vous êtes totalement bloqué. Vous ne pouvez même plus revenir en mode création !

Oui, c'est vrai... Qu'est-ce que je peux faire ?

Appuyez sur ESC . Ca fera disparaître votre 2ème client.

D'accord. Et si par exemple, j'entrais une autre Miresmo : Par exemple Claudine Miresmo, ça ne marcherait pas ?

Non, évidemment, parce que vous avez défini le champ NomClient comme étant la clé primaire. Essayez, vous verrez : Vous ne pourrez pas la enregistrer.

Ca ne va pas, ça ! Et si j'ai VRAIMENT une Claudine Miresmo ? .. J'ai trouvé : J'écris la 2ème Miresmo avec un point à la fin de Miresmo : "Miresmo.", comme ça Access va voir que ce sont 2 noms différents, et le tour est joué !

Non. C'est nul de faire comme ça. Et si vous avez par exemple 10 clients avec le même nom de famille, vous allez commencer à faire des fautes d'orthographe exprès ?

Non... Donc, si je comprend bien, soit je ne met pas de clé primaire, et je prend le risque de placer par erreur plusieurs fois le même client, ou soit j'en met une, et je ne pourrai jamais avoir deux clients avec le même nom ?

Oui, c'est très exactement ça... MAIS... Il y a l'astuce de la mort-qui-tue: C'est la clé primaire composée : C'est à dire qu'il est possible de placer une clé primaire sur plusieurs champs en même temps. Ici, par exemple, on pourrait placer une clé primaire sur le nom ET le prénom. Dans ce cas, on pourra avoir plusieurs clients avec le même nom, plusieurs clients avec le même prénom, mais on ne pourra PAS avoir 2 fois un client avec le même nom et le même prénom !

Application d'une clé primaire composée (Sur plusieurs champs)

Comment faire ? Allez en mode création, et sélectionnez en cliquant dans la partie de gauche les DEUX champs NomClient ET Prenom. Une fois qu'ils sont sélectionnés (en noir), vous cliquez sur la petite clé. Vous aurez ce résultat :

A partir de maintenant, vous allez pouvoir avoir plusieurs noms et prénoms identiques, mais pas ensemble. Je m'explique : Par exemple, vous allez pouvoir mettre : (Plusieurs fois Martin avec des prénoms différents, et plusieurs fois Michel avec des Noms différents). Par contre un 2ème Michel Piccolo sera impossible (Même nom ET même prénom)

D'accord. Mais je suis en train de penser que si on a vraiment beaucoup de clients, il est bien possible d'avoir 2 clients distincts avec le même nom et le même prénom... Je peux supposer qu'il y a pas mal de Jean Dupont par exemple...

Et bien vous enlevez la clé primaire et voilà tout...

Mouais... Ou alors on combine carrément 3 champs : Le nom, le prénom ET la date de naissance... Comme ça on est tranquille. On peut faire ça ?

Oui, oui. Comme ça vous pourrez avoir plusieurs clients qui ont le même nom ET le même prénom, mais alors, ils ne pourront pas avoir la même date de naissance. Et si jamais le cas se présente : Incroyable : Vous avez 2 clients né le même jour, et qui ont le même nom ET le même prénom !

Là, vous coupez les cheveux en quatre... Est-ce vraiment plausible?

Disons qu'il y a vraiment peu de chance que ça se produise. Mais on peut essayer quand même de simplifier. Plutôt que de déterminer une clé primaire combinée, qui est quand même un peu compliqué, n'y aurait-il pas un champ qui pourrait servir de clé primaire à lui tout seul ?

Je réfléchis... Le salaire ... Non, la date de naissance... Non.. Hmmm... Ah ! Oui : bien sûr : Le numéro de téléphone ! Il ne peut PAS y en avoir 2 les mêmes !

Non, c'est vrai, mais imaginez par exemple que vous avez 2 clients : Ce sont 2 frères qui habitent dans le même appartement : Ils ont donc le même numéro de téléphone, et pourtant ce sont 2 clients distincts...

Vous avez raison. Ou alors.. Le numéro AVS ? C'est comme me numéro de sécurité sociale : ça, c'est unique !

Là, d'accord. Mais comment allez-vous faire si vous devez entrer dans votre base un client qui ne vous a pas encore communiqué son numéro AVS ? Vous allez l'écrire sur un Post-il collé à l'écran en attendant d'avoir son numéro à disposition ? Ou alors vous allez mettre un faux numéro AVS exprès pour pouvoir entrer le client ? Pas terrible ! ...

Donc ?

Donc, dans notre cas, nous constatons que ce n'est pas si simple d'installer une clé primaire sur cette table. Nous allons donc faire ce que toutes les entreprises du monde font : Nous allons assigner un numéro d'identification unique à chacun de nos clients : Ce sera un numéro tout droit sorti de notre imagination.

Création d'un champ qui servira de clé primaire (Appelé Index)

Dans votre table T_Client, ajoutez un nouveau champ que vous appellerez IDClient (comme IDentification Client), définissez-le en clé primaire , et lancez la table en mode saisie de données.

Je l'ai fait mais il me donne l'erreur du début :

Oui. qu'y a-t-il actuellement dans IDClient ?

Rien !

Eh bien voilà... Et comme une clé primaire DOIT contenir quelque chose, et EN PLUS quelque chose de différent pour chaque enregistrement... Voilà la source de l'erreur. Il vous reste à :

  1. Enlever la clé primaire
  2. Lancer la table en mode saisie de données
  3. Ecrire quelque chose de différent pour chaque client : (Vous n'êtes pas obligé de recopier scrupuleusement les IDClient, vous mettez n'importe quoi pourvu qu'il n'y ait pas 2 fois le même numéro)
  4. Revenir en mode création
  5. Définir IDClient comme clé primaire
  6. Relancer la table en mode saisie de données : Il devrait cette fois se laisser faire.

Type de données : NuméroAuto : Particularités

Ca marche. On ne peut pas demander à Access de numéroter automatiquement lui-même les clients ?

Si. C'est d'ailleurs la possibilité la plus intéressante. Pour ce faire, vous revenez en mode création, et vous définissez IDClient comme NuméroAuto : . Malheureusement, quand vous faites ça comme ça, vous obtenez ce message d'erreur :

Ca veut dire que comme vous avez déjà rentré des données dans IDClient, Access se rend compte qu'il va devoir effacer vos données pour les remplacer par une numérotation automatique. Afin de vous obliger à en prendre bien conscience, il vous demande de bien vouloir effacer le champ IDClient, et de le recréer juste après. C'est ce que vous allez faire : Effacez IDClient (Cliquez à gauche de IDClient , et appuyez sur DELETE ). Ensuite, recréez une ligne vide au-dessus de NomClient (Cette fois je vous laisse vous rappeler comment faiure), et remettez IDClient : Définissez-le immédiatement en NuméroAuto . Définissez-le également en Clé primaire, et lancez la table en mode saisie de données. Si tout s'est bien passé, vous devriez obtenir ce résultat : .

Pourquoi met-il (NuméroAuto) sur le dernier enregistrement ?

Ce n'est pas le dernier enregistrement. C'est un nouvel enregistrement. Dès que vous allez essayer d'entrer un nouveau client, immédiatement, il sera numéroté 14, et un nouvel enregistrement (NuméroAuto) se tiendra déjà prêt pour le suivant. Essayez : Vous voyez ? Il suffit d'une lettre. Complétez le nom et le prénom : .

Combien puis-je ajouter d'enregistrements de cette façon ?

Si mes souvenirs sont exacts, au moins seize millions. Ceci dit, votre PC sera à genoux avant que vous n'arriviez aux limites du nombre d'enregistrements... C'est beaucoup mieux qu'Excel qui lui, est limité à 65'536 lignes...

Qu'est-ce qui se passe si je supprime un enregistrement ? Il renumérote tous les autres ?

Non. Nous allons essayer : effacez Catherine Deneuves : . voici le résultat : Le numéro 6 est définitivement perdu ! Il n'y a aucun moyen de le récupérer.

Pourquoi ne renumérote-t-il pas tous les autres clients pour que les numéros continuent de se suivre ?

Parce que s'il faisait ça, les clients changeraient constamment de numéro ! Ca n'aurait plus aucune utilité... Vous, vous avez bien un numéro de client par exemple chez votre plombier, ou même chez votre médecin... Ce serait invivable si votre numéro de client changeait sans arrêt.

Trous de numérotation inhérents à l'utilisation d'un NuméroAuto

Même si on recrée Catherine Deneuves comme nouveau client, elle ne récupère pas non numéro ?

Evidemment pas. Essayons : . C'est maintenant le numéro 15... Attention donc : Vous êtes en possession de 14 enregistrements, mais ils sont numérotés jusqu'à 15... Eh oui ! Il y a un trou :

Ok ! Mais puisque c'est Access qui gère cette numérotation automatique, on n'a pas besoin de définir cet IDClient en clé primaire tout à coups ?

Disons que le NuméroAuto est très très copain avec la clé primaire. Si vous ne définissez pas IDClient (NuméroAuto) en clé primaire, nous aurons des problèmes. Pas maintenant, mais bien plus tard lorsque nous allons lier cette table avec d'autres tables, mais c'est vrai que c'est de la musique d'avenir. Il faudra attendre la leçon 16 pour s'en rendre compte.

A la base, on voulait éviter d'avoir des doublons dans les clients, et finalement, nous avons tellement retourné le problème dans tous les sens que nous pouvons à nouveau avoir plein de doublons dans les noms des clients par erreur - mis à part que maintenant ils sont numérotés ?

Eh oui... Bienvenue dans le monde merveilleux des bases de données... Vous avez vu et constaté par vous-même que c'est vraiment difficile à gérer.

On ne peut vraiment rien faire pour empêcher les doublons finalement ?

Si. Il existe un genre de requête qui s'appelle "Requête Trouver les doublons" qui va nous aider à repérer les clients entrés par erreur à double, et à les comparer avec des cleints qui sont bien différents, mais qui ont le même nom, et/ou le même prénom par exemple, mais c'est l'objet de la leçon 45.

La clé primaire est-elle indispensable ?

A la limite, on ne met pas de clé primaire du tout, et puis voilà !

Non, ce n'est pas génial comme solution. Imaginez une base de données beaucoup plus complexe (des milliers de clients, des commandes, des factures, etc...): Imaginons que vous avez un certain José Lopez qui vous appelle en vous demandant où en est sa commande. Vous recherchez dans votre table "José Lopez". Vous le trouvez, et vous constatez qu'il a commandé 2 fois, livré dans les temps, mais qu'il n'a jamais payé, et qu'il est maintenant en poursuite. Vous allez lui expliquer que comme c'est un mauvais payeur, vous refusez dorénavant de le livrer ! Or... Il se trouve que dans votre base de données, vous avez DEUX José Lopez... Bien distincts... Et celui qui vous appelle est, au contraire, un de vos meilleurs clients... Très bon payeur de surcroit ! Alors là, c'est LA gaffe ! Si vous lui aviez attribué un numéro de client, vous lui auriez demandé, en plus de son nom et prénom, son numéro de client (qu'il doit connaître évidemment - mais c'est facile : Sur chaque facture, le numéro de client est reporté), ce qui vous aurait permis de constater que vous n'étiez pas sur le bon José Lopez, et ainsi éviter la catastrophe commerciale.

Il y a une autre bonne raison, cette fois technique, pour mettre un numéro de client, mais nous verrons celà bien plus tard, notamment dans la leçon 57.

Finalement, on met systématiquement un NuméroAuto pour chaque table?

Justement pas ! Ici oui, parce que nous n'avons pas le choix : Il peut y avoir des clients avec le même nom, mais dans certaines tables, il n'est PAS POSSIBLE d'avoir 2 fois la même chose, nous verrons celà dans la leçon 16.

Création automatique de clés primaires

Access adore les clés primaires. Il vous fait même croire qu'il est impensable d'avoir une table sans clé primaire. Aussi, il se propose, par excès de zèle, de vous créer une clé primaire quasiment contre votre gré. Faisons un test :

  1. Créez une nouvelle table. Installez y deux champs : NomAmi, et Prenom (Laissez-les en texte, et ne mettez pas de clé primaire).
  2. lancez-là en mode saisie de données
  3. Access vous informe que la table doit être enregistrée : Dites Oui. Donnez comme nom : T_Ami
  4. Vous avez alors cette boîte de dialogue :
    En gros, il dit : "Une clé primaire, c'est vaaaaachement bien ! Quoi ??? Vos n'allez quand même pas me dire que vous ne voulez pas de clé primaire !!! Bon, je ne peux pas vous obliger, mais quand même, je vous la conseille fortement"
  5. Il faudra à l'avenir TOUJOURS TOUJOURS répondre non à cette question. Si vous répondez oui, voilà ce qu'il va faire : . Il va vous ajouter un champ N° qu'il va définir lui-même en NuméroAuto, ET en clé primaire : . Essayez, vous verrez.

Voilà... Résultat, il ne vous reste plus qu'à effacer ce champ. Ne laissez pas Access "Penser à votre place". Tandis que si vous aviez répondu "non" à cette question , il aurait simplement enregistré la table telle quelle, et vous auriez travaillé dedans sans autre forme de procès.

Bon... Hem... On peut résumer ?

La clé primaire est un attribut de champ. On dit que tel ou tel champ est la clé primaire de la table dans laquelle il se trouve. N'importe quel champ (A part un champ mémo) peut faire office de clé primaire pour autant qu'il ne soit pas répété. Dans l'exemple des clients, on ne peut pas vraiment mettre la clé primaire sur le nom du client, parce qu'il peut y avoir plusieurs clients distincts avec le même nom.
Une clé primaire composée est une clé primaire que l'on pose sur 2 ou plusieurs champs à la fois. Ceci permet d'avoir plusieurs clients qui ont le même nom, mais ils doivent avoir un prénom différent (dans le cas où la clé est posée sur le nom et le prénom).
Comme il est toujours possible d'avoir 2 ou plusieurs clients qui sont homonymes par le nom et le prénom, on décide alors d'attribuer un numéro automatique (NuméroAuto) à un nouveau champ que l'on pourrait appeler IDClient.
Le NuméroAuto est tout à fait bon copain avec la Clé Primaire - Un champ NuméroAuto est de manière presque systématique la clé primaire d'une table.

Avez-vous bien compris ?

  1. Une clé primaire est synonyme d'identifiant ?
    a. Oui ***
    b. Non
  2. Il est possible d'avoir une table sans clé primaire ?
    a. Oui ***
    b. Non
  3. Quand on regarde le dernier enregistrement d'une table pourvue d'un champ en NuméroAuto, ce dernier enregistrement donne aussi le nombre d'enregistrements de la table ?
    a. Oui
    b. Non ***
  4. J'ai une table T_Client, avec une clé primaire composée sur NomClient et Prenom. J'ai déjà Jacques Dupont et Paul Durand. Quel enregistrement ne sera pas possible à ajouter ?.
    a. Jacque Dupont
    b. Paul Durant
    c. Paul Durand ***
    d. Jacques Dupont. (A cause du petit . après Dupont, il est possible de le mettre)
  5. Est-il possible de créer une clé primaire sur un champ Mémo ?
    a. Oui
    b. Non ***
  6. J'ai une table qui contient simplement tous les pays du monde (T_Pays): Un seul champ, donc : Pays. J'y insère tous les pays : Allemagne, Belgique, Zimbabwe, etc... Comment vais-je définir ma clé primaire ?
    a. Directement sur Pays *** (Oui : Il ne peut PAS y avoir 2 fois le même pays)
    b. Je vais créer IDPays en NuméroAuto pour y mettre la clé primaire
    c. Je ne met pas de clé primaire sur cette table
    d. Je vais créer IDPays en NuméroAuto,     et je vais faire une clé primaire composée en 2 champs : IDPays et Pays

Pour voir les solutions, il vous suffit de sélectionner le questionnaire ci-dessus : 3 petites étoiles *** apparaîtront en face des bonnes réponses.

Exercice

Créez une base de données Municipalité.mdb. Dans cette base, vous allez créer plusieurs tables :

T_Pompier : Va contenir le nom, le prénom et le numéro de téléphone de chaque pompier du village. En tout, il y a 7 ou 8 pompiers
T_Contribuable : Va contenir le nom, le prénom et l'adresse de chaque contribuable du village (14'500 personnes environ)
T_Rue : Va répertorier le nom de chaque rue de la commune (Il y a 28 rues)
T_Manifestation : Va répertorier les manifestations de la salle des fêtes. Il ne peut y avoir qu'une manifestation par jour, mais il n'y en a pas tous les jours Il faut donc le nom de la manifestation, et la date

L'exercice consiste à créer les tables, et, surtout, à installer les clés primaires logiquement sur chaque table.

Téléchargez la solution de l'exercice ici

Si vous n'êtes pas tout à fait certain d'avoir suivi correctement toutes les étapes de cette leçon, vous avez la possibilité de télécharger ici la version de ProFormation.mdb exactement dans l'état ou elle devrait être à la fin de cette leçon.

Avez-vous une question technique concernant cette leçon ? Cliquez ici !
Une remarque sur cette leçon ? Un problème ? Une erreur ? une ambiguité ? Soyez gentil de m'en informer