Accueil Recherche | Plan Technique | Liens | Actualités | Formation | Emploi | Forums | Base
TUTORIEL cerig.efpg.inpg.fr 
Vous êtes ici : Accueil > Formation > Tutoriels > Bases de données relationnelles > Les listes de choix
        Révision : 19 janvier 2003
 
                  Les bases de données
relationnelles
                 
Chap.
précéd.
Plan du
tutoriel
Liste des
tutoriels
Chap.
suivant
 
Chapitre 4 : Les listes de choix
 
1 - Introduction
                  Considérons l'exemple d'une table (que nous appellerons "Personnes") constituée comme le montre l'exemple ci-dessous.          
Nom Prénom Titre Adresse Commune Code postal
Durand Pierre M. 31 rue des champs Uriage 38410
Chose Stéphanie Melle 2 place Stanislas Nancy 54000
Trombe Jean M. 18 cours de la libération Grenoble 38001
Machin Andrée Mme 10 cours Berriat Grenoble 38000
etc.
Il est tout à fait fastidieux de saisir de nombreuses fois la même information, telle que celle du titre (Mme, Melle, M.). En outre, si la liste est assez longue, le même nom de commune sera saisi à plusieurs reprises -- avec le risque d'une faute de frappe, suivie d'une erreur si l'on effectue dans la table des recherches basées sur le nom de la commune. Enfin, on n'est pas à l'abri d'une erreur de saisie conduisant à associer à une commune un code postal erroné.
Pour éviter de saisir plusieurs fois le titre ou le même nom de commune, nous pouvons l'enregistrer dans une table séparée, et travailler ensuite par copier/coller. C'est encore mieux s'il nous suffit d'indiquer au système où se trouve l'information correspondante pour l'enregistrement que nous sommes en train de renseigner.
Pour ce faire, certains SGBD sont dotés d'un outil appelé liste de choix (ou plus simplement liste), que nous allons maintenant examiner. Comme dans le chapitre précédent de ce tutoriel (encore appelé "cours en ligne" ou tutorial), nous utiliserons le SGBD Access comme support pratique.
2 - La liste simple (liste interne)
                  Dans un premier temps, nous créons une table "Personnes" contenant seulement les trois champs "Nom", "Prénom" et "Titre", possédant tous le type de données texte. Nous allons faire en sorte de faire écrire le titre par le système lors du remplissage de la table.          
Lors de la création de la table, lorsque nous arrivons au type de données du champ "Titre", nous sélectionnons "Texte", puis "Assistant liste de choix..." dans la liste déroulante qui est à notre disposition. Nous procédons alors aux opérations suivantes :
            nous choisissons l'option "Je taperai les valeurs souhaitées". Il ne serait pas raisonnable, en effet, de créer une table pour y introduire seulement trois abréviations ;
  nous conservons le nombre de colonnes égal à 1. Nous saisissons les trois valeurs (M., Mme, Melle) les unes sous les autres dans la colonne intitulée "Col1" (utiliser la tabulation ou les flèches pour passer d'une valeur à l'autre). Enfin, nous réglons la largeur de la colonne, en la saisissant par le haut de son bord droit ;
    nous laissons le choix au système du nom de la liste (l'étiquette), et l'opération est terminée.
Dans la fenêtre de définition de la table, aux "Propriétés du champ", onglet "Liste de choix", nous trouvons les informations représentées sur la figure suivante :
Propriétés du champ "Titre"
Commentons ces propriétés :
            Afficher le contrôle : Zone de liste déroulante. Une liste non déroulante conviendrait tout aussi bien, puisque la liste est fort courte, et le système ne nous proposera pas de barre de défilement. Mais attention : choisir "zone de texte" conduit à supprimer la liste, et il faudra la recréer ;
  Origine source : Liste valeurs. Pour nous rappeler que nous avons saisi la liste directement dans l'assistant ;
  Contenu : "M.";"Mme";"Melle". Les trois termes saisis sont rassemblés ici, séparés par des points-virgules, et mis entre guillemets pour rappeler qu'il s'agit de chaînes de caractères ;
  Colonne liée : 1. La colonne liée (ici la première colonne) est celle qui contient l'information que le système copiera / collera pour nous ;
  Nbre colonnes : 1. Nous n'avons demandé qu'une seule colonne ;
  En-têtes colonnes : Non. Sans objet pour nous ;
  Largeurs colonnes : 1 cm (par exemple). C'est la valeur que nous avons fixée dans l'assistant ;
  Lignes affichées : 8. C'est la valeur par défaut, mais le système limitera aux seules trois lignes utiles ;
  Largeur liste : 1 cm. C'est la largeur de l'unique colonne. La valeur "auto" convient également ;
  Limiter à liste : Non. C'est la valeur proposée par défaut. Nous reviendrons sur ce choix au paragraphe suivant.
Enregistrons et passons en mode "feuille de données" pour introduire du contenu dans la table. Quand nous cliquons dans le champ "Titre", l'icône de la liste apparaît. Si nous cliquons dessus, la liste que nous avons saisie nous est proposée telle quelle par le système pour remplir le champ "Titre". Il suffit que nous cliquions sur la valeur désirée pour que le système l'inscrive à notre place, comme le montre la figure ci-dessous.
Liste de choix dans une table
3 - La liste obligatoire
                  En saisissant des données dans la table "Personnes", nous constatons que nous pouvons introduire la chaîne de notre choix dans la colonne titre. Or il serait plus judicieux que nous soyons limités aux seules trois valeurs qui ont un sens. Pour ce faire, il nous faut revenir en "mode création". Dans la ligne du champ "titre", nous cliquons dans la colonne "type de données". Dans l'onglet "liste de choix", nous réglons à "oui" la propriété "Limiter à liste". Puis nous revenons au"mode feuille de données".          
Nous constatons alors que le système nous permet toujours de saisir dans le champ "Titre" une information qui n'est pas dans la liste, mais il refuse de l'enregistrer lorsque nous passons à la ligne suivante. Notre liste de titres est effectivement devenue obligatoire, le contrôle s'effectuant lors du passage à l'enregistrement suivant, ou lors de la fermeture de la table.
Rendre une liste obligatoire est une décision qui doit être prise au coup par coup, en fonction des besoins. Il est souvent utile de rendre une liste obligatoire, mais ce n'est pas une règle absolue.
Remarque : on ne peut rendre la liste obligatoire que si la propriété "Afficher le contrôle" est à "Zone de liste déroulante". Une "Zone de liste" ne le permet pas... et seul l'éditeur Microsoft sait pourquoi.
4 - La liste issue d'une table (liste externe)
                  Lorsque le nombre d'éléments de la liste est important, et / ou s'il est susceptible d'être complété de temps en temps, il est plus judicieux de placer les éléments de la liste dans une table plutôt que de les saisir dans l'assistant. C'est le cas, par exemple, de la liste des communes.          
La liste peut de nouveau être mise en place avec l'aide de l'assistant, mais il faut au préalable créer la table correspondante. Nous l'appelons "Communes", nous lui attribuons un seul champ (intitulé "commune"), doté du type de données "texte". Passons en mode "feuille de données" et introduisons quelques noms de communes dans la nouvelle table.
Nous retournons à la table "Personnes" en mode création, et nous rajoutons le champs "Commune" en mode texte. Nous lançons l'assistant liste de choix et nous procédons aux opérations suivantes :
            nous choisissons l'option "Je veux que la liste de choix recherche les valeurs dans une table ou requête" ;
  nous choisissons la table "Communes" ;
  nous sélectionnons son unique champ, intitulé "Commune" ;
  nous réglons la largeur de la future liste ;
  nous laissons le système régler tout seul son problème d'étiquette ;
  nous répondons "oui" à la demande d'enregistrement, et l'opération est terminée.
Les propriétés du champ "Commune" de la table "Personnes", apparaissent ainsi (onglet "liste de choix") :
Liste de choix issue d'une table
Par comparaison avec la liste simple, nous remarquons les deux différences suivantes :
            la propriété "Origine source" contient maintenant "Table/Requête", ce qui est normal ;
  la propriété "Contenu" contient le code SQL "SELECT Communes.commune FROM Communes; ", ce qui signifie en clair : "choisir le champ commune de la table Communes".
De retour dans la table "Personnes" en mode "feuille de données", nous constatons que la liste contenue dans la table "Communes" nous est proposée, et que de plus elle est triée par ordre alphabétique (parce que la propriété "Indexé" est passée de "Non" à "Oui - Avec doublons").
Pour assurer la cohérence entre la table principale "Personnes" et la table "Communes", nous avons tout intérêt à rendre la liste obligatoire comme précédemment. Ceci nous astreint à renseigner le nom de commune dans la table "Communes" avant de saisir l'enregistrement correspondant dans la table "Personnes", ce qui n'est pas très commode. Nous verrons plus loin comment l'usage d'une sous-table permet de régler élégamment le problème.
5 - La clé (clé primaire)
                  Nous pouvons améliorer la fiabilité du système précédent en faisant en sorte que nous ne puissions pas saisir deux fois le même nom dans la table Communes. Nous ouvrons cette dernière en mode "création", nous sélectionnons le champ "Commune", et nous cliquons sur l'icône qui représente une petite clé.          
La clé (encore appelée "clé primaire") identifie de manière unique chaque enregistrement de la table. Le champ auquel on applique une clé acquière les propriétés suivantes :
            les doublons (deux informations identiques ou plus) sont désormais interdits par le système. La propriété "Indexé" passe automatiquement à "Oui - Sans doublons" ;
  la présence de la clé interdit la présence d'un champ vide dans un enregistrement. Bien que cela n'apparaisse pas dans dans les propriétés du champ (encore un petit bug !), la valeur "Null" est désormais bannie ;
  le champ auquel on applique une clé est automatiquement trié par ordre croissant.
Pour supprimer une clé, il faut sélectionner le champ et cliquer sur l'icône de la clé ; cette icône fonctionne comme un commutateur. Notons enfin qu'il ne peut y avoir qu'une seule clé par table.
6 - La sous-table
                  La présence de la clé a aussi pour effet de faire apparaître la table "Personnes" comme sous-table de la table "Communes". En effet, si nous ouvrons cette dernière, nous voyons que chaque ligne commence maintenant par un signe + (appelé "indicateur de développement" dans Access). Si nous cliquons sur ce signe (en face de la commune "Uriage", par exemple), la liste des personnes de la table "Personnes" habitant Uriage apparaît (figure ci-dessous), et nous pouvons la compléter. Si nous cliquons sur le signe - qui se trouve maintenant en face de la commune "Uriage", la sous-table disparaît. On peut faire apparaître plusieurs sous-tables de la table "Personnes" dans la table "Communes" si on le désire.          
Sous-table
L'existence de la sous-table nous permet de remplir simultanément la table "Personnes" et la table "Communes" qui lui sert de liste, d'autant que la liste simple du champ "Titre" fonctionne effectivement dans la sous-table. Comme on peut le constater, les sous-tables sont fort commodes, et elles rendent superfétatoire l'usage des formulaires.
7 - L'usage d'un code
                  Nous désirons maintenant associer le code postal au nom de la commune. Un problème naît immédiatement du fait que, en France du moins, plusieurs codes postaux peuvent être attribués à une même commune, lorsque cette dernière est une grande ville. A Paris, par exemple, chaque arrondissement possède son code postal, lequel varie donc de 75001 à 75020. A Grenoble, bien qu'il n'y ait pas d'arrondissement, il existe deux codes postaux (38000 et 38001). Si nous rajoutons une colonne "Code postal" à la table "Communes", nous serons amenés à écrire deux fois Grenoble dans la colonne "Commune", ce que la présence de la clé interdit.          
La solution consiste à utiliser un code. Le code est une donnée qui identifie un enregistrement de manière univoque. En d'autres termes, on ne peut pas trouver dans une table deux lignes possédant le même code.
Nous rajoutons donc une colonne "Code_com" à la table "Communes", et nous attribuons la clé à cette nouvelle colonne (ce qui assure l'unicité du code). Ainsi, les couples 38000-Grenoble et 38001-Grenoble seront dotés d'un code différent. De même, il y aura 20 codes pour Paris, un par arrondissement.
La gestion du code peut être confiée au SGBD. Pour ce faire, il suffit d'utiliser le type de données NuméroAuto (entier long) pour le champ "Code". Le système attribuera les codes dans l'ordre croissant, ou de manière aléatoire, comme nous le désirons.
La première opération consiste à détruire la liste externe que nous avons créée au paragraphe 4. En mode création, nous modifions la propriété "Afficher le contrôle" (du champ "Commune" de la table "Personnes") de "Zone de liste déroulante" à "Zone de texte". Si nous repassons en mode "Feuille de données" (après avoir enregistré), nous constatons qu'il n'y a plus de liste pour alimenter le champ "Commune". Mais tout n'a pas disparu pour autant, car une liste externe implique une relation. Comme nous n'avons pas encore étudié les relations, nous ne savons pas comment les détruire. Nous allons donc procéder de la manière suivante :
            nous sélectionnons la table "Communes",  nous donnons l'ordre de la supprimer, et nous confirmons ;
  le système nous alerte : "Impossible d'effacer la table 'Communes' avant la suppression de ses relations avec d'autres tables. Effacer les relations maintenant ?" ;
  nous confirmons et la table "Communes" disparaît avec les dernières traces de la liste de choix.
Nous recréons maintenant la table "Communes", qui va désormais comporter trois colonnes :
            la première colonne ("Code_com") est du type NuméroAuto. Elle est dotée de la clé ;
  la seconde colonne ("Commune") est recréée à l'identique ;
  la troisième colonne ("Code postal") est en mode texte (5 caractères), et non en numérique. En effet, certains codes postaux commencent par un zéro (exemple : 01000 pour l'Ain), et le mode numérique supprimerait le premier zéro.
Nous revenons dans le champ "Commune" de la table "Personnes", et nous relançons l'assistant "Liste de choix". Nous procédons aux opérations suivantes :
            nous choisissons "Je veux que la liste de choix recherche les valeurs dans une table ou requête" de manière à créer une liste externe ;
  nous choisissons la table "Communes" ;
  nous sélectionnons les deux champs "Code_com" et "Commune" ;
  nous conservons la coche "Colonne clé cachée" et nous réglons la largeur de la liste ;
  nous laissons le système donner un nom (étiquette) à la liste, nous cliquons sur "Terminer", et nous enregistrons.
Si nous regardons ce que sont devenues les propriétés du champ "Commune" de la table "Personnes", nous constatons de sérieux changements :
            le champ "Commune" est devenu numérique, avec comme taille de champ "Entier long" ;
  la propriété "Valeur par défaut" vaut zéro. Nous supprimons cela immédiatement, pour des raisons d'esthétique uniquement ;
  le code SQL de la propriété "Contenu" a changé, ce qui est normal (la liste implique désormais deux colonnes au lieu d'une) ;
  dans la propriété "Largeurs colonnes", nous constatons que la première colonne de la liste possède une largeur nulle.
Mais nous ne sommes pas au bout de nos surprises : si nous utilisons la liste de choix ainsi créée dans la table "Personnes", nous constatons que le système propose et écrit le nom de la commune et non son code (figure ci-dessous). Des noms de commune (c'est à dire du texte) dans un champ numérique, c'est une catastrophe ! Pas de panique : le champ est, et reste, numérique. Simplement, le SGBD a affiché la traduction du code en texte, pour nous faciliter la lecture de la table.
Que le code soit caché résulte directement du fait que la largeur de sa colonne soit déclarée nulle dans les propriétés de la liste de choix. Il suffit que nous donnions une valeur non nulle à cette largeur pour que le code remplace le nom de la commune (faire l'expérience). L'opération est réversible, et nous retrouvons l'affichage de la figure ci-dessus si nous donnons de nouveau une valeur nulle à la première colonne de la liste.
Si le code "Code_com" est caché dans la table "Personnes", pourquoi ne pas en faire autant dans la table "Communes" ? Il suffit de tirer avec la souris sur le bord droit de la colonne "Code_com" jusqu'à ce que cette dernière disparaisse. La table "Communes" se présente alors (avec la sous-table "Personnes") comme le montre la figure ci-dessous. Désormais, le SGBD gère les codes, mais nous ne les voyons pas. Aucun regret !
En cas de besoin (ou si nous aimons les codes...), nous pouvons faire réapparaître le champ "Code_com". Affichons la table "Communes" en mode feuille de données et, dans le menu, utilisons "Format > Afficher les colonnes...". La boite de dialogue "Afficher les colonnes" s'ouvre ; cochons "Code_com", et refermons.
8 - Compléments
                  Comme nous pouvons le constater sur la figure ci-dessus, la champ "Commune" n'est pas trié par ordre alphabétique, ce qui n'est pas pratique du tout. Nous pouvons le trier en le sélectionnant, puis en cliquant sur l'icône "Tri croissant".          
Par contre, nous pouvons faire en sorte que, dans la table "Personnes", la liste des communes apparaisse automatiquement triée par ordre alphabétique. Nous ouvrons la table "Personnes" en mode modification, nous cliquons sur le champ "Commune" puis sur l'onglet "Liste de choix", et nous modifions comme suit le code SQL de la propriété "Contenu" :
SELECT Communes.Code_com, Communes.Commune FROM Communes ORDER BY Communes.Commune;
Nous aurions pu obtenir le même résultat en cliquant sur le code, puis sur le bouton . Une fenêtre intitulée "Instruction SQL : Générateur de requête" s'ouvre. Nous pouvons alors demander un tri croissant dans la colonne "Commune". Nous apprendrons l'usage de ce type de fenêtre lorsque nous étudierons les requêtes.
Notons que l'on peut remplacer le code SQL de la propriété "Contenu" par le nom de la table contenant la liste. C'est souvent ce que pratiquent ceux qui n'utilisent pas l'assistant pour créer leurs listes. Mais on ne peut plus demander que la liste apparaisse automatiquement triée par ordre alphabétique. Évidemment, on peut toujours la trier via l'icône "Tri croissant". En pratique, il est fortement conseillé de toujours utiliser l'assistant pour créer une liste de choix.
Arrivés à ce stade, vous souhaiteriez sans doute que le code postal s'inscrive automatiquement dans la table "Personnes", dès lors que le choix de la commune a été effectué. Dit comme tel, c'est impossible. Mais il existe deux solutions pour rassembler les informations réparties dans les deux tables "Personnes" et "Communes" :
            créer une vue via une requête portant sur les deux tables ;
  créer un formulaire basé sur les deux tables.
Ces deux opérations seront étudiées dans les chapitres suivants de ce tutoriel.
9 - Conclusion
                  Il existe deux façons de réaliser une liste de choix : en saisissant immédiatement les valeurs (liste interne), ou en les introduisant dans une table auxiliaire (liste externe). La première façon est recommandée lorsque la liste est courte, et peu susceptible de changer. La seconde façon est recommandée lorsque la liste est longue, et / ou susceptible d'être souvent modifiée ou complétée. Quelle que soit la manière utilisée pour réaliser une liste de choix, l'usage de l'assistant "liste de choix" est fortement recommandé.          
Rappelons que le codage constitue une solution pour régler un problème d'homonymie. Si un tel problème n'est pas susceptible de se poser, le codage constitue une complication inutile. Si l'usage de codes s'avère indispensable, on peut toujours faire en sorte de ne pas les voir, alors que le SGBD continue à les gérer.
Nous reviendrons, au chapitre 9, sur l'usage des listes, et sur les rapports complexes qui existent entre liste et relation.
Chapitre précédent Plan du tutoriel Liste des tutoriels Chapitre suivant
Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base
Copyright © CERIG/EFPG 1996-2003
Réalisation et mise en page : J.C. Sohm