 |
 |
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 
!
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 :
Lancez la table en mode saisie de données. Vous avez un premier message d'erreur :
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.
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.
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.
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.
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 :
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 !
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 !
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 !
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 !
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 !
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 :
Si vous effacez un enregistrement, le numéro est perdu à jamais ! Faisons un test :
(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 !
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é N°, 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 !)
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.
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 :
Vous y insérerez ces quelques villes (Pour info : ce sont des localités réelles du canton de Genève) :
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.
