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 procd.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
Résumé
de la leçon précédente| Nous avons vu la dernière fois comment faire pour traiter les tables de manière générale : Les copier, les effacer, les renommer. Nous avons vu qu'il est possible de voir les dates de création et de modification de ces tables. Nous avons enfin constaté que la sauvegarde régulière et fiable de la base de données complète est très importante, même si ACcess n'est pas pourvu d'un outil de sauvegarde complète de la base de données. |
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). En réalité, la traduction la plus correcte en français serait Identifiant. |
Essayons : 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 de 1000 clients... c'est plus délicat !
Comment empêcher ça ?
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... Maiiiiiiiis... 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. Comem d'habitude, Access
va vous prévenir que la table "Doit être sauvegardée"... Répondez oui (Pas le
choix), et c'est maintenant qu'il n'est pas d'accord : 
. Cliquez sur OK, vous
aurez ce 2ème message d'erreur : 
. (Ca veut dire qu'il ne veut rien savoir :Votre clé
primaire, il n'en veut pas !) Cliquez sur OK.
Eh bien, la clé primaire, en plus de ne pas accepter les Doublons (2 fois le même nom de client), elle n'accepte non plus pas qu'un client n'ait pas de nom ! Si vous avez cent mille client, et qu'UN SEUL n'a pas de nom, alors, il sera IMPOSSIBLE de définir une clé primaire sur ce champ !
Non. Pas tant que ça. Voici comment vous allez faire :
. ça l'enlèvera. Quand on clique
sur cette petite clé , une
fois ça la met, une autre fois ça l'enlève.
, 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 c'est parce que ce n'est pas un
enregistrement, c'est une nouvelle ligne pour pouvoir justement entrer un nouvel
enregistrement. Celle ligne ne peut pas s'effacer évidemment.
Oui. Vous revenez en mode création, et vous remettez la clé primaire sur le
nom. Relancez ensuite encore une fois la table en mode saisie de données. Access
va donc encore vous prévenir qu'il doit sauvegarder 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 !
Vous devriez voir venir l'astuce :
Allez-y, faites-le si ce n'est pas déjà fait !
Disons que plus exactement, il les a rangé par ordre alphabétique
Ici, c'est fichu. On ne peut plus. Mais, entre nous, est-ce vraiment important ?
Access va refuser. Essayez : 
. Il accepte, c'est vrai... Mais il n'a pas encore
sauvegardé : Souvenez vous du petit crayon (
). Dès que vous allez
sauvegarder - par exemple en descendant d'un enregistrement - alors, vous aurez
instntané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 sauvegarder. Vous ne
pouvez plus rien faire : Vous êtes totalement bloqué. Vous ne pouvez même plus
revenir en mode création.
. Ca fera disparaître votre 2ème client.
Oui... MAIS... Il y a une combine : 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. Alors, 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 !
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 : 
Voilà. A partir de maintenant, vous allez pouvoir avoir plusieurs noms et
prénoms les mêmes, mais pas ensemble. 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) 
Et bien vous enlevez la clé primaire et voilà tout...
Disons qu'il y a vraiment peu de chance que ça se produise. Mais on peut essayer quand même de simplifier. Plustôt que de faire 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 ?
Donc, dans notre cas, nous constatons que ce n'est pas si simple de mettre une clé primaire sur cette table. ALors, nous allons 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.
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.
Ben 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 à :
(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)
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 on fait), 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 ceci :
.
Vous voyez ? Il suffit
d'une lettre. Complétez le nom et le prénom : 
.
. Vocii le résultat : 
Le numéro 6 est
définitivement perdu ! Il n'y a aucun moyen de le récupérer.
. C'est
maintenant le numéro 15... Attention donc : Vous êtes en possessions de 14
enregistrements, mais ils sont numérotés jusqu'à 15... Eh oui ! Il y a un trou :
Non, ce n'est pas génial de ne pas en mettre. Imaginez une base de données beaucoup plus complexe que ça (des milliers de clients, des commandes, des factures, etc...): Vous avez un certain José Lopez qui vous appelle en vous demandant ou 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. Voius 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.
Ah non, justement... 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à ultérieurement.
Access aime bien les clés primaires. Il 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 :
. 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 est.
N'importe quel champ 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. |
Avez-vous bien compris ?
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 L'exercice consiste à créer les tables, et, surtout, à mettre les clés primaires correctement sur chaque table |
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 procd.mdb exactement dans l'état ou elle devrait être à la fin de cette leçon.
Aperçu
de la leçon suivante| La prochaine leçon sera très amusante ! En effet, vous allez apprendre à créer vous même des listes de choix déroulantes ! Plutôt que d'écrire en toute lettres le pays d'origine de chaque client, avec le risque d'erreur que ça comporte, vous apprendrez comment faire pour le choisir parmi une liste de pays que vous aurez-vous-même défini ! (En réalité, nous ne nous occuperons pas du pays, mais plutôt du champ Titre (Madame, mademoiselle ou monsieur), mais le principe est le même |