Il est de bon ton de se souhaiter la bonne année. Mais vous, et vous seul, pourrez faire en sorte que cette année soit bonne, meilleure que celle qui vient de s'écouler. Apprenez à ne compter que sur vous, car personne n'est plus qualifié que vous-même pour bâtir, réparer ou améliorer votre propre vie. Personne ne fera les choses à votre place. D'ailleurs, tout ce que les autres peuvent faire, c'est souhaiter que vous le fassiez. Et ne croyez pas que tout ceux qui vous entourent vous apporteront des solutions : certains font juste partie de vos problèmes. Transformez vos résolutions en actes, et dans douze mois, retournez-vous et souriez-vous fièrement : C'était long. C'était difficile. Mais ça y est : 2017 était une bonne année, merci Moi.

Leçon 15
 
Clé primaire

Dans cette leçon, nous allons apprendre à créer des clés primaires (également appelées Identifiant, primary key ou clé principale).

Une clé primaire interdit les enregistrements en double.

Nous verrons également la numérotation automatique des enregistrements. Nous verrons les erreurs communes, et analyserons les situations : est-il toujours nécessaire de créer une clé primaire dans une table ?

Laquelle ? Pourquoi ?

 
Sommaire

Dans la leçon précédente, nous avons appris à créer des listes déroulantes basées sur d'autres tables. Il serait bien qu'on ne puisse pas accidentellement créer plusieurs fois le même Pays dans la table T_Pays, comme ceci (Faites-le):


Ensuite, ce serait bien aussi qu'on ne puisse pas effacer le contenu d'un enregistrement, sans effacer l'enregistrement lui-même : Faites-le : effacez CH (Le contenu CH, pas l'enregistrement).

Ca, c'est simple, nous avons déjà vu la propriété Chaîne vide autorisée dans la leçon 5. Comment ? Vous aviez oublié ??? Pas bien, ça ! Ne laissez pas s'enfuir vos connaissances, relisez de temps à autre les anciennes leçons !

Création d'un champ en clé primaire

Voici une astuce qui va permettre à la fois d'interdire les doublons et les enregistrements vides.

 

Revenez en mode création de T_Pays. Cliquez sur le champ Pays, et dans le ruban Création de table, cliquez sur l'icone Clé primaire.

Ca affiche le dessin d'une petite clé à gauche de Pays :

Erreurs communes (Doublons et vides)

Lancez la table en mode saisie de données. Vous avez un premier message d'erreur :

Clé primaire est la traduction littérale de Primary Key en anglais. Une traduction plus correcte serait Identifiant (C'est un terme que vous risquez de rencontrer)

C'est à cause du CH qui a disparu. Access refuse de définir un champ en clé primaire s'il existe des données vides dans ce champ.

Lorsque vous cliquez sur OK, vous avez un 2ème message d'errreur :

 

Oui, bon, OK, on a compris ! On a fait une erreur, pas besoin de le dire deux fois avec des mots différents !

Et il refuse finalement de vous afficher le mode saisie de données !

Réglons le problème du champ vide : nous allons supprimer carrément l'enregistrement vide. Mais nous devons aller en mode saisie de données, et, du coup, nous sommes obligés de retirer la clé primaire : cliquez à nouveau sur l'icône clé, et ça l'enlève de votre champ : .

Lancez la table en mode saisie de données (C'est donc possible, maintenant), et supprimez carrément l'enregistrement vide :

Revenez en mode création, et remettez la clé sur le champ Pays .

Relancez la table en mode saisie de données : voici un autre message d'erreur !

Cette fois, c'est à cause des deux France.

 

  1. Comme tout à l'heure, supprimez la clé primaire du champ Pays
  2. lancez la table en mode saisie de données
  3. Supprimez le premier France
  4. Revenez en mode création
  5. Remettez encore une (dernière) fois la clé primaire sur Pays
  6. Relancez la table en mode saisie de données : Enfin ça maaaaaaaaaaaaaaaarche !!!

Ajoutez Italie : . Appuyez sur ENTER - ou changez d'enregistrement - pas de problème !!!

 

Maintenant, essayez d'ajouter un pays qui existe déjà : Espagne.

Vous pouvez l'écrire, mais à l'instant d'enregistrer, vous aurez alors le même message d'erreur que tout à l'heure :

Vous vous rappelez de la touche qu'il faut appuyer en cas de blocage, comme ici, ou le message d'erreur vous empêche de faire quoi que ce soit ?

Si vous avez oublié, on a vu ça ici, dans la leçon 3.

Erreurs de ressemblances

Si vous essayez d'ajouter un pays qui ressemble énormément à un autre pays, à une nuance près, Access vous laissera faire, malgré la clé primaire.

Ne le faites pas, mais nous pourrions avoir :

Vous avez vu la différence ? Il y a juste un petit point en plus à la fin du 2ème U.S.A. Selon le même principe, Access considérerait que Bresil et Brésil sont des pays différent. Par contre SUISSE et suisse seraient considérés comme un seul pays, avec une orthographe identique.

Le simple fait de définir un champ en clé primaire le trie par ordre alphabétique, et non plus par l'ordre dans lequel nous avons entré les pays... Bon, est-ce vraiment gênant ? ... Personnellement, je trouve plutôt ça pratique...

Je pense que vous comprenez l'intérêt de définir Pays en clé primaire pour la table T_Pays.

Choix judicieux de la clé primaire

Mais dans la table T_Client, que fait-on ? Doit-on également mettre le champ PaysOrigine en clé primaire ? ... Sûrement pas !

Il y a plein de gens qui viennent du même pays, et, de plus, il y a des gens dont on ignore le pays d'origine, et dont le champ est donc vide.

Réfléchissons : y a-t-il un champ qui peut-être défini en clé primaire ?

En d'autres mots, y a-t-il un champ dont il n'est pas possible qu'il y ait deux fois la même chose, et qui soit toujours rempli ?

Le pays, on vient de voir que non..

DateNaissance ? ... Non, plusieurs clients pourraient être nés le même jour, même si ce serait exceptionnel.

La taille ? Non... Le salaire ? Non plus !

NomClient ? Oui, pourquoi pas ! Regardez : ils sont tous remplis et tous différents ... Ou presque ... Eh oui ! Il y a 2 Spielberg !

Du coup, a-t-on vraiment besoin d'une clé primaire dans T_Client ? Pas forcément !

 

Mais faites ceci : déplacez la Remarque à droite du Prenom, et inscrivez ces deux Remarque pour les deux Spielberg :

Confusion d'enregistrements

Imaginez que vous avez la table sous les yeux, et un client vous appelle au téléphone :

- Bonjour monsieur !

- Bonjour ! Je suis Monsieur Spielberg, et ma commande de 100 Schmilblicks n'est toujours pas arrivée !

- Un instant, je consulte ma super base de données Access, avec ma table T_Client toute neuve dont je suis très fier... Mmmmmm... Ecoutez, je lis que vous avez eu des problèmes de paiement dans le passé !

- Quoi ! Jamais de la vie ! Je vais changer de fournisseur ! Foi de Max Spielberg !

Et il raccroche... Aïe ! Vous vous êtes trompé de client ! C'était Max, pas Steven ! Trop tard !

Que font toutes les entreprises du monde pour identifier leurs clients de manière absolument unique, sans risque de confusion ? ...

Elle vous attribuent un numéro de client !

C'est ce que nous allons faire !

Champ dédié à la clé primaire

Créez un nouveau champ au tout début de la table (on met, par simple convention, les champs clé primaire en début de table), que vous appellerez IDClient (IDentification Client).

Laissez-le en texte, mais en taille 5.

Si vous essayez de le définir immédiatement en clé primaire, ça ne fonctionnera pas, puisque le champ est actuellement tout vide, normal !

Vous constaterez-peut-être que, malgré le fait que vous avez expressément créé votre IDClient tout au début de la table, en mode saisie de données, il apparaît tout à droite. C'est un bug d'Access : fermez simplement la table et rouvrez-la.

Lancez-donc la table en mode saisie de données, et mettez ce que vous voulez dans ce champ IDClient, du moment qu'il n'y a pas deux clients qui ont le même IDClient... Par exemple, les 3 premières lettres du NomClient, suivi de 2 chiffres, ou numéroter 1,2,3, etc... ou même ce que vous voulez, c'est vous qui voyez comment vous avez envie d'identifier vos clients.

C'est donc seulement lorsque vos clients ont tous bien un IDClient rempli et différent que vous pouvez revenir en mode création et installer la clé primaire sur IDClient. A partir de maintenant, il ne sera plus possible de créer un nouveau client avec un numéro déjà existant, ni vide.

Une fois la clé primaire installée, relancez la table en mode saisie de données. Créez un nouveau client : 

Vous ne vous êtes pas occupé de la clé primaire, et vous vous êtes juste concentré sur le NomClient, le prenom et la Remarque. Du coup, lorsque vous essaierez d'enregistrer, vous aurez ce message d'erreur que vous connaissez déjà.

C'est troublant dans le sens que vous ne vous êtes pas du tout préoccupé de IDClient, et le message d'erreur ne mentionne pas son nom !

Mettez-lui 99 (par exemple) comme IDClient, sinon, votre seul salut sera d'annuler ce nouveau client... Eh oui ! selon les cas, on peut être tenté d'écrire n'importe quoi dans un champ pour pouvoir continuer !

Numérotation automatique (NuméroAuto)

Finalement, vous vous contenteriez peut-être bien d'une simple numérotation (1,2,3,4,5,6,...), non ?

Revenez en mode création. Choisissez NuméroAuto comme type de données de IDClient :

 

Access vous assène un message d'erreur. En fait NuméroAuto est une sorte de Numérique Entier long (Vous vous rappelez des Entiers Longs ?).

Le NuméroAuto a ceci de particulier que ce n'est pas vous qui entrez les données, mais c'est Access qui décide : il va numéroter les clients 1,2,3, ...

Du coup, tous vos beaux IDClient que vous avez rempli consciencieusement seraient écrasés par la nouvelle numérotation !

C'est pourquoi Access préfère vous renvoyer un message comme quoi ce n'est pas possible. Eh bien, on va le faire quand-même ! Non mais !

  1. Supprimez le champ IDClient, ce qui aura pour effet de supprimer ses données, évidemment
  2. Recréez le même champ IDClient, toujours tout en haut, mais précisez tout de suite que c'est un type NuméroAuto

Constatez que, sur le coup, il n'est plus en clé primaire. ce n'est pas grave !

Lancez la table en mode saisie de données :

Et voilà ! Ils sont numérotés ! Peu importe comment, d'ailleurs, ils ne sont pas triés par ordre alphabétique, ni rien : l'important est juste que chaque client possède un identifiant unique.

- Bonjour monsieur !

- Bonjour ! Je suis Monsieur Spielberg, et ma commande de 100 Schmilblicks n'est toujours pas arrivée !

- Un instant, je consulte ma base de données Access. Vous savez que j'ai fait beaucoup de progrès ces derniers temps ?

- Heu oui, bon... Mes schmilblicks ?

- Quel est votre numéro de client, monsieur ?

- 4.

- Alors, oui, je vous que vous êtes notre meilleur client, c'est marqué, juste là, sous mes yeux !

- Oui, merci. Bon, vous me racontez votre vie, ou bien vous finissez par me dire où en est cette commande ?!?!

- Je vais voir avec notre service expédition et on vous rappelle immédiatement. A tout de suite, Cher Client !

Spécificités des NuméroAuto

Vous ne pouvez absolument pas changer un numéro de client à la main. Si vous essayez de modifier 6 en 14 (par exemple), vous subirez un message d'erreur très (trop) discret qui va s'afficher dans la barre d'état (tout en bas de la fenêtre Access).

Le simple fait d'ajouter un client lui attribue le numéro suivant. Entrez Laurent Ruquier :

Numéros ne se suivent pas

Si vous effacez un enregistrement, le numéro est perdu à jamais ! Faisons un test :

  1. Effacez l'enregistrement Chuck Norris :
  2. Constatez le "trou" dans les numéros :
  3. Recréez Chuck Norris dans un nouvel enregistrement (Mais ne l'enregistrez pas - laissez le petit crayon sur la gauche). Il est maintenant numéro 11.
    Dans mon cas, j'ai fait une petite erreur, et j'ai dû effacer et recréer mon champ IDClient, ce qui fait qu'il a tout renuméroté, et le "trou" entre Coluche et Di Caprio a donc disparu, ce qui décale Di Caprio, Ruquier et Norris. Mais ça ne change rien au principe de base.
  4. Appuyez 2 fois sur la touche (Comme si vous voulez annuler ce que vous veniez de faire), et effacez ainsi ce nouvel enregistrement, et recréez directement Chuck Norris, comme ceci :

Et voilà : Le numéro 10 n'a pas eu le temps d'exister...

Cette numérotation automatique n'est donc pas une manière de compter les enregistrements ! Chuck Norris est N°11 (N° 12, chez vous), et pourtant, c'est le 10ème enregistrement.

Et si vous vouliez supprimer les "trous", il vous suffirait de supprimer le champ IDClient, et de le recréer, mais, du coup, tous les clients changeraient de numéro, ce qui n'est pas souhaitable !

Clé primaire proposées par défaut

Maintenant, vous comprenez pourquoi, lors de la création d'une nouvelle table, Access vous demande si vous voulez installer une clé primaire (leçon 2, ici). Il veut simplement ajouter un champ nommé , défini en NuméroAuto.

Mais quel intérêt si on ne sait pas à quoi ça sert ?

Et la clé primaire alors, dans tout ça ?

Dans le cas d'un champ de type NuméroAuto, elle ne sert plus à rien, puisqu'il est impossible d'avoir deux fois le même numéro, puisque c'est Access qui décide. Du coup, que vous mettiez une clé primaire ou pas sur IDClient, ça ne change rien.

(En fait, si, mais seulement quand nous verrons les relations !)

Mauvaise utilisation de la clé primaire

Un dernier mot sur la table T_Pays : Y aurait-il un intérêt à lui adjoindre un champ IDPays en NuméroAuto ? ... Si IDPays devient la clé primaire, vous pourriez alors écrire plusieurs fois le même nom de pays avec des numéros différents, et si vous laissez la clé primaire reste sur le champ Pays, quel serait son intérêt ? ... Dans la table T_Client, Spielberg peut donnier lieu à confusion, mais France, Italie, ou Espagne, non ! Il n'y a pas deux pays dans le monde qui possèdent le même nom, heureusement !

Dans cette leçon, nous avons appris à définir les champs en clé primaire, ce qui permet de rendre notre base de données plus cohérente, et moins sujette aux erreurs de saisie.

Nous avons vu que les clés primaires n'étaient pas indispensables, mais seulement conseillées. Les clé primaires ne supportent ni les doublons, ni les vides. Nous avons vu qu'une clé primaire peut être en texte ou en numérique (elle peut même être en date/heure)

Nous avons ensuite scruté le type de champ NuméroAuto, et nous avons constaté qu'il n'est pas forcément défini en clé primaire.

Nous avons enfin constaté qu'il est possible de mal définir ses clés primaires, et qu'une analyse de la situation était indispensable avant de les utiliser n'importe comment.

Exercice

L'exercice consiste à créer une nouvelle base de données que vous nommerez ExerciceLecon015.accdb.

Vous y créerez une table T_CodePostalVille, dans laquelle vous installerez 2 champs :

  • CodePostal (Numérique, Entier)
  • Ville (Texte, 50 caractères)

Vous y insérerez ces quelques villes (Pour info : ce sont des localités réelles du canton de Genève) :

  • 1217 - Meyrin
  • 1200 - Genève
  • 1227 - Carouge
  • 1203 - Genève
  • 1227 - Acacias

Cette table doit avoir 1 champ en clé primaire.

A vous de découvrir s'il s'agit d'un de ces deux champs, ou s'il faut en rajouter un troisième.

Quizz
1. Clé primaire peut également s'appeler
Clé absolue
Champ bloqué
Compteur
Identifiant
2. Un champ de type NuméroAuto :
Peut se définir en clé primaire
Ne peut pas se définir en clé primaire
Doit se définir en clé primaire
3. Un champ défini en clé primaire peut parfois rester vide 
Non, jamais
Oui, sans problème
Oui, mais la propriété "Null interdit" doit être à Non
Oui, mais la propriété "Chaîne vide autorisée" doit être à Oui
4. Un champ défini en clé primaire peut parfois contenir des doublons
Non, jamais
Oui, mais la propriété "Doublon autorisé" doit être à Oui
Oui, mais la propriété "Clé principale" doit être à "Doublons autorisés"