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 formulaires (fin)
        Révision : 20 décembre 2002
 
                  Les bases de données
relationnelles		                  
Chap.
précéd.		 Plan du
tutoriel		 Liste des
tutoriels		 Chap.
suivant
 
Chapitre 29 : les formulaires sur deux tables
 
1 - Le formulaire avec liste de choix
                  Lorsque la table sous-jacente est dotée d'une liste (laquelle provient le plus souvent d'une table auxiliaire), le formulaire en hérite automatiquement. Pour le montrer, nous créons un formulaire sur la table "Personnes". Après un peu de mise en forme, il se présente comme le montre la figure ci-dessous :          
Dans la table "Communes", qui sert de liste, nous avons déclaré nulle la largeur de la colonne "code_commune". Comme pour une table, c'est alors le nom de la commune qui s'affiche à la place du code. Nous devrions donc modifier l'étiquette, en remplaçant "Code_commune" par "Commune", afin que l'utilisateur du formulaire ne soit pas troublé.
2 - Le formulaire avec liste indépendante
                  Le logiciel Access nous permet de créer une liste indépendante, contenant par exemple les noms et prénom déjà saisis. Pour ce faire, nous ouvrons le formulaire en mode création, puis nous agrandissons la zone d'en-tête pour y placer la liste. Si la boite à outils n'est pas apparente, nous cliquons sur "Affichage", puis "Boite à outils" (nous pouvons aussi cliquer sur l'icône ). Dans cette boite, nous activons l'icône "Assistants contrôle". Comme son nom l'indique, cette icône active un certain nombre d'assistants relatifs à la création de contrôles.          
Nous cliquons ensuite sur l'icône "Zone de liste déroulante", puis à l'endroit choisi pour implanter la liste. La boite de dialogue "Assistant de zone de liste déroulante" s'ouvre. Nous dialoguons ainsi avec l'assistant :
            nous choisissons la troisième option "Rechercher un enregistrement dans mon formulaire basé sur la valeur que j'ai sélectionnée..." ;
  nous sélectionnons ensuite le nom et le prénom ;
  nous réglons graphiquement la largeur des colonnes ;
  nous baptisons l'étiquette "Liste des personnes", et nous cliquons sur terminer ;
  nous ajustons graphiquement la position de la liste (lorqu'une petite main noire apparait) ;
  nous réglons les détails de présentation, puis nous basculons en cliquant sur l'icône "Ouvrir" pour observer le résultat.
Si nous avons pris la précaution de baser le formulaire sur une requête qui trie la table "Table01", la liste indépendante que nous venons de créer est triée par ordre alphabétique. Nous pouvons donc vérifier rapidement si le nom d'une personne donnée a déjà été saisi. De plus, si nous sélectionnons un nom dans cette liste, les informations correspondantes s'affichent immédiatement, comme le montre la figure ci-dessous. Par contre, le fait de changer d'enregistrement n'a pas d'influence sur la liste indépendante.
Une telle liste indépendante rend-elle réellement service ? A l'internaute de juger !
3 - Le formulaire basé sur deux tables
                  L'assistant permet de créer un formulaire basé sur plusieurs tables. Il suffit de répéter l'opération de saisie des champs pour les tables considérées. Réalisons l'expérience à l'aide des tables "Personnes" et "Communes". La procédure est la suivante :          
            nous sélectionnons la table "Personnes", et nous introduisons tous les champs correspondants ;
  nous sélectionnons la table "Commune", et nous sélectionnons le champ "Code postal". Il est inutile que nous sélectionnions le champ "Code _commune", puisque nous l'avons déjà pris dans la table "Personnes". Il est également inutile que nous sélectionnions le champ "Commune", puisque le nom de la commune s'affichera dans le contrôle "Code_commune", comme nous l'avons vu dans le paragraphe précédent ;
  l'assistant nous demande alors si nous souhaitons afficher les données "par Communes" ou "par Personnes". Nous choisissons la deuxième option, et nous voyons que cela nous conduit à un formulaire unique. Nous ferons l'essai de la première option dans le paragraphe suivant ;
  nous choisissons la disposition et le style, nous renommons le formulaire, et nous examinons le résultat, qui est représenté sur la figure ci-dessous, après un peu de mise en forme.
Formulaire basé sur deux tables
Nous constatons que, si nous saisissons ou modifions le nom d'une commune, le code postal correspondant s'affiche automatiquement -- ce que nous ne pouvons pas faire dans une table. Il faut par contre éviter que l'opérateur puisse modifier le code postal. Pour cela, nous désactivons ou nous verrouillons le contrôle "Code postal".
4 - Le formulaire avec sous-formulaire
                  Reprenons la procédure précédente, mais demandons cette fois l'affichage des données par communes. Le dialogue avec l'assistant s'établit ainsi :          
            nous sélectionnons la table "Communes", et nous introduisons les champs "commune" et "Code postal" ;
  nous sélectionnons la table "Personnes", et nous introduisons les champs "nom", "prénom" et "adresse" ;
  nous demandons l'affichage des données par Communes, dans un formulaire avec sous-formulaire, et non dans des formulaires attachés ;
  la meilleure disposition pour un sous-formulaire est "feuille de données" ;
  nous choisissons un style, nous renommons le formulaire et le sous-formulaire, et nous terminons l'opération.
Nous obtenons ainsi un formulaire principal dans lequel nous pouvons saisir des noms de communes avec leur code postal,et les utiliser dans le sous-formulaire associé. La figure ci-dessous illustre le résultat obtenu :
Formulaire avec sous-formulaire
Nous voyons que le sous-formulaire correspond -- avec une présentation différente -- à la sous-table que nous avons rencontrée au chapitre 3, et dont nous reproduisons un exemple ci-dessous :
Il est possible d'introduire plusieurs sous-formulaires dans un même formulaire, mais l'assistant ne permet d'en créer qu'un seul. Les sous-formulaires supplémentaires peuvent être introduits avec l'aide de la boite à outils.
5 - Conclusion
                 

Ce chapitre, étalé sur deux pages web, donne un aperçu de l'objet formulaire dans les bases de données. Il ne prétend pas, loin de là, épuiser le sujet, qui est fort vaste. A un formulaire on peut associer des boutons, de la programmation événementielle, etc. On peut modifier la présentation, l'étaler sur plusieurs pages, créer des onglets, etc. Du point de vue de l'auteur de ces lignes, tout ceci ressemble un peu à du décorum, mais... à chacun ses goûts !

          
En fait, ce n'est pas tellement le formulaire que nous critiquons, mais l'usage qui en est fait. Les administrateurs de BDD font presque toujours en sorte que les utilisateurs ne puissent voir les données qu'à travers les formulaires. Privés de tables, les utilisateurs ne peuvent pas créer de requêtes, et la base de données de l'entreprise perd pour eux une grosse part de son intérêt. Se doter d'un outil coûteux (très coûteux, même, dans la plupart des cas), et en limiter le plus possible l'usage, quel paradoxe !
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