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 simples
        Révision : 17 décembre 2002
 
                  Les bases de données
relationnelles
                 
Chap.
précéd.
Plan du
tutoriel
Liste des
tutoriels
Chap.
suivant
 
Chapitre 28 : les formulaires simples
 
1 - Introduction
                  Le formulaire est souvent considéré comme le troisième objet des bases de données, par ordre d'importance décroissante, après la table et la requête. En fait, son importance réelle dépend de la manière dont on utilise le SGBD.          
    Le formulaire est avant tout un outil de saisie d'information au clavier. A ce titre, il entre en concurrence avec :  
   
            l'écriture directe dans les tables ;
  l'importation des données.
 
La facilité d'écriture directe dans les tables peut varier de très pratique à parfaitement impraticable suivant les cas. Un formulaire peut rendre la saisie de certaines informations plus facile, principalement dans les SGBD qui, au contraire d'Access, n'affichent pas les sous-feuilles de données. Enfin, les formulaires permettent l'ajout de boutons, menus, etc. qui donnent à l'application un aspect très "fini". Les SSII (sociétés de service en informatique) soignent donc les formulaires pour donner la meilleure impression possible à leur client -- surtout si ce dernier n'est pas capable de juger sur autre chose que la présentation.
    Certaines bases de données sont principalement alimentées en données par importation des données : le formulaire ne sert alors plus à rien. C'est, par exemple, le cas des magasins à grande surface, qui alimentent leur BDD directement et en temps réel depuis les caisses enregistreuses. C'est aussi le cas des sites web qui déversent quotidiennement leur fichier journal dans la BDD qui sert au suivi du site et à la mesure d'audience. C'est encore le cas de tous ceux qui font de l'acquisition de données via des capteurs couplés à des ordinateurs, etc.  
    Accessoirement, le formulaire sert aussi d'outil de visualisation, c'est à dire de consultation du contenu de la base à l'écran. On reproche parfois au formulaire de montrer les enregistrements un par un, alors qu'une table en montre un grand nombre à la fois, mais on peut concevoir le formulaire de telle sorte que sa présentation soit très proche de celle d'une table.  
    Cette discussion peut en fait se résumer ainsi :  
   
            lorsque la BDD est utilisée par des personnes très diverses sans expérience particulière en matière de SGBD, ou lorsque  l'accès aux tables est interdit aux utilisateurs, ou lorsque la saisie directe dans les tables est malaisée, les formulaires constituent un passage obligé ;
  lorsque la BDD est utilisée par un petit groupe de professionnels formés à l'usage des SGBD, ou lorsque les données sont importées au lieu d'être saisies, les formulaires constituent un simple habillage de la BDD et n'ont guère d'utilité.
 
    Comme pour l'ensemble de ce tutoriel (encore appelé "cours en ligne" ou tutorial), nous utiliserons le SGBD Access comme support pratique.  
2 - La création d'un formulaire simple
                  Un formulaire est avant tout un outil permettant de saisir au clavier des données qui sont immédiatement introduites dans une ou plusieurs tables. Le formulaire est donc lié à une ou à plusieurs tables, et il hérite de leurs propriétés : types de données, propriétés des champs, listes de choix et protection contre les doublons via un index. A l'inverse, les propriétés du formulaire ne rejaillissent pas sur les tables sous-jacentes. Il arrive enfin que l'on puisse attribuer à un champ de formulaire une propriété qui modifie ou contredit celle du champ correspondant de la table.          
    Pour étudier les formulaires, nous utiliserons une table (nommée "Personnes") dotée d'une liste de choix (nommée "Communes"), comme le montre la figure ci-dessous. Nous faisons en sorte (comme expliqué au chapitre 3) que le nom de la commune, et non son code, s'affiche dans le champ "Code_commune" de la table "Personnes".  
Table avec liste de choix
    Pour travailler sérieusement, nous créons un index sans doublon sur les champs Nom+Prénom dans "Personnes", et sur les champs "commune+code postal dans "Communes". Nous interdisons de plus le Null et la chaîne vide dans tous les champs sauf "Adresse". Le champ "code_commune" de la table "Communes" est du type NuméroAuto.  
    Créons, pour commencer, un formulaire simple qui nous permette de saisir les noms des communes et les codes postaux correspondants. Dans la fenêtre "Base de données", nous sélectionnons (colonne de gauche) l'objet "Formulaires". Nous double-cliquons sur "Créer un formulaire à l'aide de l'Assistant" et nous répondons aux demandes de ce dernier :  
   
            d'abord, nous sélectionnons la table "Communes". Les champs disponibles s'affichent (code_commune, commune, code postal), et nous sélectionnons les deux derniers. En effet le code, qui sert à faire fonctionner la mécanique relationnelle, est implémenté par le système lui-même (type de données NuméroAuto) ;
  ensuite, nous choisissons une disposition -- "Colonne simple" par exemple ;
  puis nous choisissons l'un des styles proposés ;
  enfin nous nommons le formulaire "Formulaire des communes", et nous cliquons sur "Terminer".
 
Voici comment se présente le formulaire, dont le nom apparaît désormais dans la fenêtre "Base de données" :
Le formulaire des communes
    Le formulaire est constitué d'étiquettes (les noms des champs dans la table) et de contrôles correspondant aux champs de la table. Lorsqu'ils sont directement dérivés de la table, les contrôles sont appelés "contrôles dépendants", ou encore "champs". La table à partir de laquelle est construit le formulaire est la table sous-jacente.  
    Nous constatons d'abord que nous pouvons examiner le contenu de la table "Communes" enregistrement par enregistrement, le formulaire jouant alors son rôle d'outil de visualisation. Certes, l'aspect est plus joli que celui de la table, mais cette dernière présente l'avantage de nous donner une vue globale des informations. Si nous avions choisi la disposition "Tabulaire", nous aurions obtenu une présentation par lignes plus proche de la table sous-jacente. La disposition "Feuille de données", quant à elle, fournit une présentation pratiquement identique à celle de la table sous-jacente.  
    Nous constatons ensuite que nous pouvons nous placer sur la première ligne vide de la table sous-jacente, et saisir des données (noms et prénoms des personnes). Ces données sont automatiquement introduites dans la table sous-jacente, comme nous pouvons le constater en fermant le formulaire et en ouvrant la table. Le formulaire joue alors son rôle d'outil de saisie des données. Mais les problèmes de synchronisation que nous avons déjà rencontrés demeurent : si nous laissons la table sous-jacente ouverte, nous constatons que les données saisies dans le formulaire n'y apparaissent pas. On peut fermer, puis rouvrir la table sous-jacente, pour que les nouvelles données s'y trouvent inscrites, mais il est plus simple de rendre la table active, de cliquer dans le menu sur "Enregistrements", puis sur "Afficher tous les enregistrements". La table se complète immédiatement.  
    Notons que le formulaire nous présente les informations dans l'ordre où elles se trouvent dans la table sous-jacente. Pour faire en sorte que les informations apparaissent triées, nous disposons de plusieurs méthodes :  
   
            nous pouvons effectuer une requête de sélection simple sur la table (en sélectionnant tous les champs, en triant d'abord sur le nom et ensuite sur le prénom), puis créer le formulaire à partir de cette requête. Toutes les saisies que nous effectuons dans ce nouveau formulaire sont automatiquement transmises à la table "Personnes", au travers (si l'on peut dire) de la requête de tri ;
  si un tri simple nous convient, nous plaçons le curseur dans le champ désiré du formulaire, puis nous cliquons sur l'icône du tri ;
  pour effectuer un tri multiple, nous cliquons dans le menu sur "Enregistrements", puis sur "Filtrer", puis sur "Filtre/tri avancé..." et nous intervenons dans la grille qui s'affiche.
 
3 - La mise en forme du formulaire
                  Il est fréquent que les administrateurs de BDD empêchent les utilisateurs de voir les tables (et par la même occasion, d'effectuer des requêtes -- quelle politique !). Les formulaires constituent alors (avec les états et les menus, que nous étudierons plus loin) la seule interface entre la base et ses utilisateurs. Le SGBD Access met à disposition des concepteurs de BDD de multiples outils permettant de rendre cette interface aussi soignée que possible. Avec la mise en forme du formulaire, nous entrons quelque peu dans le domaine de l'informatique "cosmétique".          
    Sélectionnons le formulaire que nous venons de créer, et cliquons sur l'icône   "Modifier". Le formulaire s'ouvre en mode de création (on devrait dire plutôt en mode de modification, car il est déjà créé). Notons que, à partir de l'option "Affichage" du menu, nous pouvons passer du mode création au mode formulaire, ou au mode feuille de données, la présentation duquel est très proche de celle de la table sous-jacente. Nous obtenons le même résultat en cliquant sur l'icône située à gauche de la barre d'outils "Création de formulaire", à condition que cette dernière soit affichée.  
    Comme les tables et les requêtes, le formulaire se présente donc sous deux aspects :  
   
            la structure (titre, étiquettes, contrôles, etc.), que l'on définit en mode création ;
  l'outil de saisie et de visualisation des données, que l'on utilise en mode formulaire.
 
    Le mode création met à notre disposition de multiple outils (entre lesquels il existe une redondance partielle) pour modifier le formulaire que nous avons créé. Nous pourrions même les utiliser pour créer le formulaire de toutes pièces, mais il est plus simple de passer d'abord par l'assistant. Ces outils peuvent être regroupés ainsi :  
            une intervention via un clic droit sur une partie spécifique du formulaire, et choix de "Propriétés" dans la liste déroulante. Une boite de dialogue s'ouvre, dans laquelle nous sélectionnons l'onglet "Format". Il nous est alors possible de régler de nombreux détails de présentation ;
  une intervention graphique directe dans la fenêtre. Nous pouvons développer les parties "en-tête" et "pied de page", régler la hauteur et la largeur du formulaire, déplacer les contrôles et les étiquettes, étendre le formulaire sur plusieurs pages (séparées ou en onglet), etc. ;
  une boite à outils qui s'affiche en même temps que le formulaire en mode création. Si cette boite n'apparaît pas, cliquer sur "Affichage" dans le menu, et sélectionner "Boite à outils".
    La mise en forme d'un formulaire, avec ses très nombreuses possibilités, fera l'objet d'une annexe (décembre 2002). Nous reviendrons plus loin sur certains usages particuliers de la boite à outils. Voici ce que devient la figure précédente après un léger lifting :  
Le formulaire des communes relooké
4 - Le perfectionnement du formulaire
                  Pour modifier les propriétés d'un formulaire, il faut ouvrir sa feuille de propriétés de la manière suivante :          
   
            sélectionner le formulaire ;
  cliquer sur l'icône "Modifier" ;
  cliquer sur l'icône "Propriétés" ou double-cliquer sur le carré noir qui se trouve en haut et à gauche de la fenêtre du formulaire ;
  sélectionner l'onglet "Données", qui donne accès à diverses propriétés du formulaire.
 
    Dans le formulaire tel qu'il est,  nous pouvons non seulement saisir de nouvelles données, mais aussi modifier ou supprimer des données existantes. Cette possibilité peut être fort dangereuse, et nous pouvons la supprimer en basculant la propriété "Modif autorisée" de "Oui" à "Non". En revenant en mode formulaire, nous constatons que désormais, les données enregistrées (par fermeture du formulaire) ne peuvent plus être modifiées. Cette interdiction est très gênante en cas d'erreur de saisie, mais elle ne s'étend pas à la table sous-jacente.  
    Nous pouvons aller plus loin, et cacher complètement les enregistrements déjà saisis. Les enregistrements nouvellement saisis seront cachés à leur tour dès que nous refermerons le formulaire. Pour ce faire, nous basculons la propriété "Entrée données" de "Oui" à "Non". En revenant en mode formulaire, nous constatons qu'aucune donnée ne s'affiche. Nous pouvons, par contre, saisir de nouvelles données.  
    Nous pouvons aussi faire en sorte que le formulaire ne permette pas la modification des données, c'est à dire qu'il serve uniquement de dispositif de visualisation. Pour ce faire, nous basculons la propriété "Ajout autorisé" de "Oui" à "Non", puis nous revenons au mode formulaire. Nous pouvons ainsi donner à un utilisateur la possibilité de consulter la base, mais sans pouvoir en modifier le contenu.  
    Recréons le formulaire des communes en incluant le champ "code_commune". Nous constatons que nous pouvons introduire le curseur dans ce champ, mais que nous ne pouvons pas le modifier. Le type de données est NuméroAuto, et seul le SGBD peut écrire dans ce champ. Dans le formulaire, cette propriété est héritée de la table sous-jacente. Pour ne pas agacer la personne qui utilise le formulaire, nous pouvons faire en sorte que le curseur ne passe plus dans le champ "code_commune". Plusieurs solutions s'offrent à nous.  
    Pour modifier les propriétés d'un contrôle ou d'une étiquette, nous pouvons faire apparaître la feuille de données comme ci-dessus, et sélectionner l'objet dans la liste déroulante qui se trouve tout en haut. Nous pouvons aussi sélectionner l'objet en mode création , effectuer un clic droit, et choisir "Propriétés".  
Sélectionnons l'onglet "Autres", et basculons la propriété "Arrêt tabulation" de "Oui" à "Non". Quand nous revenons au mode formulaire, nous constatons que le curseur ne peut plus être placé dans le champ "code_commune", bien que la valeur de ce dernier continue à s'afficher.
    Nous pouvons aussi sélectionner l'onglet "Donnée", et basculer la propriété "Activé" de "Oui" à "Non" (la propriété "Verouillé" étant sur "Non"). Quand nous revenons au mode formulaire, nous constatons que le contrôle "code_commune" et son étiquette sont grisés, comme lorsqu'une fonction n'est pas disponible dans un menu. De plus, le curseur ne pénètre plus dans le champ. La figure suivante illustre cette situation :  
Contrôle désactivé dans un formulaire
Basculer la propriété "Verrouillé" à "Oui" (la propriété "Activé" étant sur "Oui") a pour conséquence d'empêcher la modification du contenu du champ, sans en modifier l'aspect et sans empêcher le curseur d'y pénétrer. Cela ne nous est d'aucune utilité dans le cas présent, puisque le champ "code_commune" hérite déjà de cette propriété de par son type de données NuméroAuto.
Pour consulter la suite, qui traite des formulaires basés sur deux tables, cliquez sur la flèche droite ci-dessous.
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