• Aucun résultat trouvé

[PDF] Base de données relationnelle Access concepts de base - Cours Access

N/A
N/A
Protected

Academic year: 2021

Partager "[PDF] Base de données relationnelle Access concepts de base - Cours Access"

Copied!
44
0
0

Texte intégral

(1)ENSEIGNEMENT DE PROMOTION SOCIALE. —————————————————————— Cours d'informatique. GESTIONNAIRE DE BASE DE DONNÉES —————————————————————— Deuxième partie Développer une application. H. Schyns Mars 2005.

(2) Application Access. Sommaire. Sommaire. 1.. INTRODUCTION. 2.. ENONCÉ DU PROBLÈME. 3.. 2.1.. En général. 2.2.. Notre problème. ANALYSE ENTITÉS-RELATIONS 3.1.. Facturier d’entrée. 3.1.1. Factures et fournisseurs 3.1.2. La facture 3.1.3. Le suivi des paiements 3.1.4. Les remises 3.1.5. La TVA. 4.. 5.. 6.. 3.2.. Le modèle global. 3.3.. Facturier de sortie. HIÉRARCHIE DES TABLES 4.1.. Définition. 4.2.. Utilité de la hiérarchie. 4.3.. Etablir la hiérarchie du modèle. 4.4.. Emploi d'une liste de choix déroulante. 4.5.. Emploi d'un sous-formulaire. 4.6.. En résumé.... QUELQUES ASTUCES DE CONCEPTION 5.1.. Des champs bien pratiques. 5.2.. Un enregistrement incontournable. 5.3.. Les listes de choix. 5.4.. Clés multiples et hiérarchie. LA CHAÎNE CLIENTS - CODES POSTAUX - PAYS 6.1.. Les Tables et Relations. 6.1.1. Créer la table Pays 6.1.2. Créer la table CodesPostaux 6.1.3. Créer la relation Pays - CodesPostaux 6.1.4. Créer la table Clients ou Fournisseurs 6.1.5. Créer la relation Clients / Fournisseurs - CodesPostaux. 6.2.. Les formulaires. 6.2.1. Le formulaire des Pays 6.2.2. Remplir la table Pays 6.2.3. Le formulaire des Codes Postaux 6.2.4. La liste de choix déroulante "Pays" H. Schyns. S.1.

(3) Application Access. Sommaire. 6.2.5. Remplir la table CodesPostaux 6.2.6. Le formulaire des Clients ou des Fournisseurs 6.2.7. La liste de choix "Pays" 6.2.8. La liste de choix "CodesPostaux" 6.2.9. Synchroniser les listes 6.2.10. Remplir la table Clients / Fournisseurs. H. Schyns. S.2.

(4) Application Access. 1.. 1 - Introduction. Introduction L'apprentissage d'un environnement de programmation est beaucoup plus aisé quand on part d’un cas concret. Nous allons donc appliquer les notions d'entitésrelations, de définition d'interface et de programmation objet et événementielle au développement d’une application professionnelle. L'exemple choisi est la gestion du facturier de sortie ou du facturier d'entrée d'une société commerciale. Cette gestion inclut le suivi des paiements et les tâches d'administration de la TVA. Dans un premier temps, nous réaliserons une analyse détaillée des données afin d'établir un modèle entités-relations robuste. Nous verrons ainsi que les structures des deux facturiers sont très similaires. Ensuite, nous implémenterons les tables et les formulaires dans Access. L'étape suivante sera la création d'une interface simple mais ergonomique fait de formulaires, de sous-formulaires et de listes déroulantes. Ceci impliquera la rédaction de nombreuses requêtes : requêtes de sélection, de mise à jour, de regroupement, etc. Enfin, grâce à des modules VBA, nous reprendrons le contrôle de toutes les opérations gérées avec plus ou moins de bonheur par Access. L'objectif de cette étape sera la réalisation d'une application complètement sécurisée destinée à un utilisateur non averti. Pour cette étape, nous nous analyserons en profondeur tous les aspects relatifs à la gestion d’une table. Il ne s’agit pas d’un simple exercice de style. En effet, nous avons montré que les traitements à appliquer aux diverses tables d'un projet sont similaires : il s’agit toujours d’implémenter un CRUD. Dès lors, les formulaires qui gèrent des tables distinctes ne diffèrent guère que par la zone d'affichage des informations. Il doit donc être possible de définir une liste type de routines événementielles applicables à tout formulaire moyennant quelques changements de noms de variables. Nous en profiterons pour utiliser quelques astuces telles que l'emploi de boutons transparents, masquage et affichage d'objets en fonction du contexte, etc.. H. Schyns. 1.1.

(5) Application Access. 2.. 2 - Enoncé du problème. Enoncé du problème 2.1.. En général. Avant de se lancer dans la conception d'une base de données, il est nécessaire de bien s'informer auprès du client. Ce qu'il ne faut jamais faire : -. -. -. -. Croire qu'on connaît le métier du client. Même si le client possède l'un de ces petits commerces "simples" qui animent une ville de taille moyenne (tels qu'un service de location de vidéos, un atelier d'entretien d'automobiles, un restaurant), le cas à traiter présentera toujours des problèmes spécifiques. Pour les connaître, il n'y a pas d'autre moyen que de passer du temps avec le futur utilisateur et regarder comment il travaille. Imaginer la manière dont les choses se passent. Chacun a ses propres méthodes d'organisation du travail. La solution que le développeur utiliserait s'il était à la place du client n'est pas nécessairement celle que le client à choisi. Pour la connaître, il n'y a pas d'autre moyen que de passer du temps avec le client et lui poser la question. Appliquer une solution livresque. Ce point rejoint les points précédents. La solution livresque est une bonne base de travail mais ce n'est pas l'Evangile. Il est permis de l'adapter aux besoins réels du client. Et pour connaître les besoins réels, il n'y a pas d'autre moyen que de passer du temps avec le client et discuter avec lui. Faire des hypothèses. S'il est permis de faire des hypothèses pour avancer dans le travail, il faut cependant toujours les valider avec le client avant de les implémenter dans le programme. On peut imaginer qu'on paie les fournisseurs par virement; est-ce vrai ? On peut imaginer que les livraisons se font en un seul lot; est-ce vrai ?. Ce qu'il faut toujours faire : - discuter avec le client, - valider toutes les hypothèses et tout le travail déjà fait, - lui poser cent fois la question : "est-ce toujours ainsi que ça se passe ?", "N'y at-il jamais d'exceptions ?". Il vous répondra sans doute : "Non, mais c'est rare". Désolé pour vous, concepteur. Même si le cas ne se produit qu'une fois au bout d'une lune vous devez en tenir compte dans le modèle et la réalisation.. 2.2.. Notre problème. N'ayant pas de problème spécifique à régler, nous sommes bien obligés d'imaginer un cas factice. Même si l'énoncé est succinct, il ne nous sera pas interdit de nous poser les bonnes questions au bon moment. La société Tubimax s.a. est spécialisée dans le chauffage et l'isolation de maisons particulières et d'installations industrielles. Le magasin vend aussi bien des chaudières complètes que des pièces détachées telles que robinets, vannes et tuyaux divers. L'atelier réalise des montages selon les plans fournis par les industries clientes et les techniciens effectuent les installations tant chez les clients privés que sur les sites industriels. La société s'approvisionne en pièce auprès de divers grossistes. Elle dispose bien entendu d'un secrétariat bien informatisé qui s'occupe de tous les aspects H. Schyns. 2.1.

(6) Application Access. 2 - Enoncé du problème. administratifs. Celui-ci s'approvisionne en matériel de bureau auprès d'autres fournisseurs et détaillants. Jusqu'à présent, le traitement des factures s'effectuait manuellement et de manière manuscrite. Ce qui pose un gros problème de recopie lorsqu'il s'agit de rédiger les déclarations trimestrielles à la TVA.. H. Schyns. 2.2.

(7) Application Access. 3.. 3 - Analyse Entités-Relations. Analyse Entités-Relations 3.1.. Facturier d’entrée. 3.1.1. Factures et fournisseurs L’objectif du facturier d’entrée est de faciliter le classement et le suivi des factures reçues des différents fournisseurs. Il semble donc logique de commencer l’analyse en créant les entités Fournisseurs et Factures. La relation qui existe entre elles s’énonce (1) : Chaque fournisseur émet une ou plusieurs factures. Chaque facture est émise par un seul fournisseur.. Fournisseurs. émet. Factures. fig. 3.1 Base du modèle : la relation Factures-Fournisseurs. L'entité Fournisseurs regroupe tout ce qui est nécessaire à l’identification du fournisseur : le nom, l’adresse, etc. Dans Access, les entités sont représentées par les tables. N’oublions pas qu’il s’agit aussi de faire le traitement TVA des factures émises par ce fournisseur (2). Ce traitement dépend du pays dans lequel réside le fournisseur. Dès lors, pour éviter toute ambiguïté sur la manière d’encoder le nom d’un pays, nous aurons besoin d'une liste de pays, donc d'une entité ou d'une table Pays. Dans le même ordre d’idées nous créons une liste des Codes postaux (3). Evidemment, la listes des codes postaux (et des villes correspondantes) dépend du pays considéré selon la relation : Chaque pays héberge un ou plusieurs codes postaux. Chaque code postal est hébergé par un seul pays. De leur côté, les codes postaux servent à localiser le fournisseur selon la relation : Chaque code postal localise un ou plusieurs fournisseurs. Chaque fournisseur est localisé par un seul code postal. 1 2 3. Première question à poser au client : est-ce toujours vrai ? Ou bien certains fournisseurs se regroupent-ils auprès d'un bureau de factoring ? Si oui, comment est-ce que ça se passe ? Le traitement est-il le même pour toutes les factures et pour tous les fournisseurs ? Il est facile de se procurer de telles listes sur Internet. Il suffit généralement de visiter le site de "La Poste" de chacun des pays concernés.. H. Schyns. 3.1.

(8) Application Access. 3 - Analyse Entités-Relations. Ceci nous amène au schéma suivant :. Fournisseurs. localise. Codes Postaux. Pays. héberge. émet. Factures. fig. 3.2 Etendre le modèle aux codes postaux. 3.1.2. La facture Outre l'en-tête, la facture reprend la liste des articles achetés et des services fournis, avec leur prix, le taux de TVA appliqué, etc. En bas de page, la facture affiche les montants dus : montant hors TVA, montant de la TVA, montant TVA comprise. Lorsqu'on parle de liste d'articles achetés, on admet ipso facto l'existence d'une table (ou entité) qui reprend l'ensemble des lignes qui figurent sur la facture (1) : Chaque facture liste une ou plusieurs lignes de facturation. Chaque ligne de facturation est listée sur une seule facture. Suivant que la ligne de facturation reprend un article (p.ex.: un robinet), un service (p.ex.: pose d'un robinet), un bien d'investissement (p.ex.: une chaudière à gaz), le traitement TVA sera différent. En fait, la TVA classe les échanges commerciaux dans quatre catégories : les biens, les services, les marchandises et les investissements. Tous les items mentionnés sur une facture n'appartiennent pas nécessairement à la même catégorie TVA; de même tous ne se voient pas appliquer le même taux. Nous aurons donc besoin d'une table des Catégories de TVA selon la relation : Chaque ligne est incluse dans une seule catégorie de TVA. Chaque catégorie de TVA inclut une ou plusieurs lignes. Fournisseurs. localise. Codes Postaux. héberge. Pays. liste. Lignes Facturation. regroupe. Categorie TVA. émet. Factures. fig. 3.3 Développer la facture. 1. La comptabilisation et le taux et le traitement TVA sont-ils identiques pour toutes les lignes ?. H. Schyns. 3.2.

(9) Application Access. 3 - Analyse Entités-Relations. 3.1.3. Le suivi des paiements Passons maintenant au suivi de la facturation. Les factures reçues doivent être payées. Dans notre système de suivi, nous voulons garder une trace des paiements effectués. Nous aurons donc une table dans laquelle nous listerons les différents paiements. Quelle est sa relation avec les autres tables déjà crées ? Il est vraisemblable que nous serons amenés à payer des acomptes ou à payer une facture en plusieurs fois : Chaque facture est acquitée par un ou plusieurs paiements. Chaque paiement acquitte une seule facture. La seconde phrase n'est pas nécessairement vraie. Il se peut que, jusqu'à présent, nous puissions utiliser un seul paiement pour acquitter plusieurs petites factures du même fournisseur. Si c'est le cas, nous nous trouvons devant une relation "plusieurs-plusieurs" qui exigera la création d'une table pivot intermédiaire. Rien de bien difficile à gérer mais, en accord avec le client, nous pouvons nous simplifier la vie : pour simplifier le problème nous posons un choix de gestion (1) : nous décidons que désormais, un paiement ne pourra acquitter qu'une seule facture. Tant qu'à gérer les paiements, prenons note aussi du compte financier qui les a effectués (banque X, banque Y, caisse, carte de crédit, etc.) et du moyen de paiement utilisé (chèque, virement, versement, espèces, etc.). Chaque compte financier effectue un ou plusieurs paiements. Chaque paiement est effectué par un seul compte financier. Chaque mode de paiement effectue un ou plusieurs paiements. Chaque paiement est effectué par un seul mode de paiement. Continuons dans la même voie. Toutes les factures ne sont pas exigibles en même temps. Certains fournisseurs offrent des conditions de paiement plus larges, d'autres sont plus exigeants. Les factures portent des mentions du type : -. payable 30 jours fin de mois payable comptant payable 30 jours date de facture. Si nous voulons qu'Access établisse un échéancier des paiements, il faut absolument que nous traduisions ces formules classiques en règles de calcul. Nous verrons plus loin comment faire. En attendant, prévoyons une table des conditions de paiement. Chaque facture affiche une seule condition de paiement. Chaque condition est affichée une ou plusieurs factures. Notre modèle a encore gagné quatre tables !. 1. D'habitude on fait en sorte que le programme s'adapte aux habitude humaines. Le choix de gestion se pose quand on demande à l'humain de changer ses habitudes afin de s'adapter au programme et simplifier un traitement. Il faut avoir de bonnes raisons pour cela même si les habitudes humaines sont généralement anti-productives.. H. Schyns. 3.3.

(10) Application Access. 3 - Analyse Entités-Relations. Fournisseurs. localise. Codes Postaux. héberge. Pays. liste. Lignes Facturation. regroupe. Categorie TVA. reçoit. Comptes financiers. émet. Conditions paiement. Factures paie. acquitte. Modes Paiement. effectue. Paiements. fig. 3.4 Introduire le suivi des paiements. 3.1.4. Les remises Que se passe-t-il si le fournisseur accorde une Remise sur le total de facture comme c'est le cas en période de soldes ? Chaque facture accorde une ou plusieurs remises. Chaque remise est accordée par une seule facture.. Remises. accorde. Factures. fig. 3.5 Gérer les remises. 3.1.5. La TVA Périodiquement, l'utilisateur doit renvoyer une déclaration de TVA qui reprend l'ensemble des factures reçues et émises pendant la période considérée. L'utilisateur y inscrit les différents montants (total hors TVA, montant de la TVA, ...) ventilés par catégorie (Biens, services, ...). Autant laisser Access faire les regroupements et les calculs mais il faut qu'Access sache quelles factures ont déjà été reprises sur une déclaration et quelles sont celles à traiter. Chaque déclaration reprend une ou plusieurs factures. Chaque facture est reprise sur une seule déclaration.. Factures. reprend. Déclarations TVA. fig. 3.6 Gérer les déclarations à la TVA. H. Schyns. 3.4.

(11) Application Access. 3.2.. 3 - Analyse Entités-Relations. Le modèle global. Cette fois nous sommes au bout de nos peines… jusqu'à nouvel ordre.. Remises. Fournisseurs. Codes Postaux. héberge. Pays. liste. Lignes Facturation. regroupe. Categorie TVA. émet. liste. Conditions paiement. localise. Factures paie. reprend. acquitte. Modes Paiement. effectue. Paiements. reçoit. Comptes financiers. Déclarations TVA. fig. 3.7 Modèle du facturier d'entrée. 3.3.. Facturier de sortie. L’objectif du facturier de sortie est de faciliter le classement et le suivi des factures émises vers les différents clients.. Remises. Clients. liste. Conditions paiement. localise. Codes Postaux. héberge. Pays. liste. Lignes Facturation. facture. Produits. reçoit. Factures paie. reprend. acquitte. Paiements. Déclarations TVA. regroupe. reçoit. Comptes financiers. Categorie TVA. effectue. Modes Paiement. fig. 3.8 Modèle du facturier de sortie H. Schyns. 3.5.

(12) Application Access. 3 - Analyse Entités-Relations. En menant l'analyse comme ci-dessus, on s'aperçoit que les deux structures sont finalement très similaires. On voit surtout apparaître une table Produits qui était absente du modèle précédent. C'est elle qui se lie à la table Catégories de TVA. Les tables Déclarations de TVA et Modes de Paiement ont été déplacées pour faciliter la lecture du modèle mais les liens sont identiques à ce qu'ils sont dans le modèle du facturier d'entrée. Dans la suite du projet, nous développerons principalement le facturier de sortie car il est un peu plus complexe - et donc un peu plus intéressant - que le facturier d'entrée.. H. Schyns. 3.6.

(13) Application Access. 4.. 4 - Hiérarchie des tables. Hiérarchie des tables 4.1.. Définition. Les règles d'intégrité référentielles expriment dans quelle mesure une entité peut exister indépendamment d'une autre ou, au contraire, si l'existence de l'une dépend de l'autre. Cette règle est définie dans la relation entre les deux entités. perceptible par l'emploi des mots "chaque" et "toujours".. Clients. reçoit. Elle est rendue. Factures. fig. 4.1 L'intégrité référentielle. Chaque client reçoit toujours (?) une ou plusieurs factures. Chaque facture est toujours (?) reçue par un seul client. Le "toujours" de la première phrase n'est pas nécessairement vrai : il peut exister des clients qui n'ont jamais reçu de factures. Ce sont par exemple les prospects ou simplement des clients pour lesquels la facture n'a pas été établie (1). La création d'un enregistrement Client n'impose pas la création ni l'existence d'un enregistrement Facture (car il est permis d'avoir des Clients sans Factures). Par contre, le "toujours" de la seconde phrase est vrai : on n'établit une facture que si on connaît le client auquel elle doit être adressée. Donc, la création d'un enregistrement dans la table Factures exige la création ou l'existence de Client auquel la facture est adressée (car le "toujours" de la règle interdit l'existence d'une facture sans client). Ceci définit la hiérarchie de saisie des informations : les renseignements sur les Clients doivent précéder l'établissement de la Facture. Dès lors, on dira que la table Clients est située plus haut dans la hiérarchie que la table Factures.. Clients I. reçoit. Factures II. fig. 4.2 Les niveaux hiérarchiques. Une table située du côté un (1) d'une relation est toujours prioritaire et située plus haut dans la hiérarchie que la table située du côté plusieurs (∞). Par convention, les niveaux sont numérotés I, II, III, IV,... Le chiffre I étant attribué au niveau le plus élevé (le plus prioritaire).. 1. Même s'il ne s'agit que d'un délai de quelques secondes entre le moment où on encode le client et celui où on encode sa facture ! Du point de vue de la BdD, pendant ce temps il existe un client sans facture.. H. Schyns. 4.1.

(14) Application Access. 4.2.. 4 - Hiérarchie des tables. Utilité de la hiérarchie. Etablir la hiérarchie du modèle est une tâche essentielle et pourtant souvent négligée. La hiérarchie définit : -. 4.3.. un plan de réalisation de la base de données : l'interface des entités prioritaires (formulaires) doit être réalisée avant l'interface des tables inférieures; l'ordre dans lequel on remplit les tables et dans lequel on procède aux tests de validation; l'impact de la destruction d'un enregistrement. Une destruction se propage en cascade dans toutes les tables liées qui sont situées plus bas dans la hiérarchie. quand il convient d'utiliser une liste de choix déroulante et quand il convient d'utiliser un sous-formulaire.. Etablir la hiérarchie du modèle. Par définition, les tables les plus prioritaires, celles de niveau I, sont du côté "1" de toutes les relations auxquelles elles participent. Dans nos deux modèles, facturier d'entrée et facturier de sortie, il y a six tables de niveau I. Elles sont marquées cidessous :. Remises. Clients. localise. Codes Postaux. héberge. Pays I. liste. Conditions paiement I. reçoit. Factures. liste. paie. reprend. acquitte. Paiements. Déclarations TVA I. Lignes Facturation. facture. Produits. regroupe. reçoit. Comptes financiers I. Categorie TVA I. effectue. Modes Paiement I. fig. 4.3 Les tables de niveau I. Notez que la table des Remises n'est pas une table de niveau I car elle se trouve du côté "n" de la relation. Supprimons par la pensée ces tables de niveau I ainsi que les relations auxquelles elles participent. Nous trouvons ainsi les tables de niveau II.. H. Schyns. 4.2.

(15) Application Access. 4 - Hiérarchie des tables. Remises. Clients. liste. localise. Codes Postaux II. liste. Lignes Facturation. reçoit. Factures. facture. Produits II. acquitte. Paiements. fig. 4.4 Les tables de niveau II. On recommence le processus autant de fois que nécessaire pour identifier le niveau de toutes les tables. Voici le résultat final :. Remises. Clients. V. III. liste. Conditions paiement I. localise. liste. paie. IV. Lignes Facturation V. facture. acquitte. Paiements. Déclarations TVA I. héberge. Pays I. reçoit. Factures. reprend. Codes Postaux II. V. Produits II. regroupe. reçoit. Comptes financiers I. Categorie TVA I. effectue. Modes Paiement I. fig. 4.5 Les niveaux hiérarchiques du modèle. A cause de l'intégrité référentielle, on ne peut encoder une information dans une table que si on a rempli les tables auxquelles elle est attachée et qui sont situées plus haut dans la hiérarchie.. H. Schyns. 4.3.

(16) Application Access. 4 - Hiérarchie des tables. Ainsi, avant de créer une facture, nous devons connaître : -. le client, les conditions de paiement, la déclaration de TVA.. Dès lors, le projet doit impérativement commencer par la mise au point de la gestion des clients, c'est à dire la définition des tables -. clients, codes postaux pays. Ensuite, avant de songer à remplir les lignes de cette facture, nous devrons créer et définir -. les catégories de TVA les produits. Enfin, la gestion des remises et des paiements ne se fera que quand tout le reste aura été mis au point. Nous avons donc défini le planning de réalisation.. 4.4.. Emploi d'une liste de choix déroulante. On emploie une liste de choix déroulante quand un formulaire attaché à une table a besoin d'informations provenant de tables situées plus haut dans la hiérarchie. Requête sur Conditions. recherche. Conditions paiement I. Clients. recherche. Requête sur Clients. III définit. reçoit. alimenter. alimenter. Factures IV encode. Liste déroulante Conditions. choix. encode. Formulaire Facture. choix. Liste déroulante Clients. fig. 4.6 Emploi de listes déroulante. Par exemple, l'encodage de la facture se fait par l'intermédiaire d'un formulaire Facture. Mais pour encoder un enregistrement dans la table facture, nous avons besoin (entre autres) du code d'identification du client et du code d'identification des conditions de paiement afin de satisfaire l'intégrité référentielle. Comme la table Clients est située plus haut dans la hiérarchie, l'introduction du code client se fera en sélectionnant le client ad hoc parmi les noms proposés dans une H. Schyns. 4.4.

(17) Application Access. 4 - Hiérarchie des tables. liste déroulante (1). La liste déroulante sera elle-même remplie grâce à une requête qui ira rechercher l'information valide dans la table des clients. Ainsi, nous serons toujours certains que le code client introduit dans la table des Factures a bien son équivalent dans la table des Clients. Il en va de même pour les Conditions de paiement : le choix s'effectue parmi une liste. La liste est elle-même alimentée par une requête qui interroge la table.. 4.5.. Emploi d'un sous-formulaire. On emploie un sous-formulaire quand un formulaire attaché à une table a besoin d'informations provenant de tables situées plus bas dans la hiérarchie. Sous Formulaire Liste Paiements. Formulaire Facture. lister. Sous Formulaire Liste Lignes Fact.. lister. afficher. Factures. alimenter. alimenter. IV. acquitte. Requête sur Paiements. recherche. Paiements V. liste. Lignes Facturation V. recherche. Requête sur Lignes Fact.. fig. 4.7 Emploi de sous-formulaires. Par exemple, l'affichage et l'encodage des détails (lignes) de facture pourrait se faire à partir d'un formulaire Lignes de Facturation. Il en va de même pour les Paiements et les Ristournes. Mais il est plus pratique de procéder à cet encodage à partir du formulaire Factures. Comme les tables Lignes de Facturation, Paiements et Ristournes sont situées plus bas que la table Factures dans la hiérarchie, on utilisera des sous-formulaires. Autrement dit, le formulaire des factures comprendra un sous-formulaire pour l'affichage des lignes de détail de facturation; un autre pour l'affichage des ristournes et un troisième pour l'affichage des paiements. Ces sous-formulaires peuvent se trouver sur des onglets différents. Dès que la facture désirée est affichée dans le formulaire Factures, son code d'identification est accessible. A partir de ce code, nous pouvons facilement retrouver toutes les lignes et tous les paiements qui s'y rapportent. De même, dans le cas de l'encodage, il sera aisé de reproduire ce code dans les sous-formulaires Lignes de Facturation ou Paiements ainsi, nous serons toujours certains que les lignes que nous introduirons dans les sous-formulaires seront bien liées au code de la facture affichée.. 1. Access (français) utilise le vocable "Zone de liste modifiable". Dans la suite du texte nous parlerons toujours de "Liste déroulante". Le terme technique anglais est "Combo box".. H. Schyns. 4.5.

(18) Application Access. 4.6.. 4 - Hiérarchie des tables. En résumé.... Compte tenu de ce qui a été dit plus haut, les tables de niveau I sont toutes destinées à alimenter des listes déroulantes. Dans un premier temps, les formulaires attachés à ces tables seront aussi simples que possibles. Les formulaires des tables de niveau II devront inclure une ou plusieurs listes déroulantes afin de récupérer les données des tables liées de niveau I. Les formulaires des tables de niveau III devront inclure une ou plusieurs listes déroulantes afin de récupérer les données des tables liées de niveau II et de niveau I. Et ainsi de suite. Dans un deuxième temps, nous procéderons en sens inverse (si nécessaire). Les formulaires des tables de niveau III devront inclure un ou plusieurs sousformulaires afin d'afficher les données des tables liées de niveau V et de niveau IV. Les formulaires des tables de niveau II devront inclure un ou plusieurs sousformulaires afin d'afficher les données des tables liées de niveau III et en-dessous. Les formulaires des tables de niveau I devront éventuellement inclure une ou plusieurs sous-formulaires afin d'afficher les données des tables liées de niveau II et en-dessous.. H. Schyns. 4.6.

(19) Application Access. 5.. 5 - Quelques astuces de conception. Quelques astuces de conception 5.1.. Des champs bien pratiques. Les tables comprennent un certain nombre de champs dans lesquels l'information sera conservée. En plus des champs prévus par l'analyse, il est vivement recommandé d'ajouter systématiquement trois champs supplémentaires : Remarques EstMarque EstDetruit. T120 Texte libre O/N Oui, si l'enregistrement est marqué pour une sélection ultérieure O/N Oui, si l'enregistrement est détruit "logiquement". Le champ Remarques permet de stocker de l'information de manière temporaire et provisoire. On distingue surtout deux situations dans lesquelles ce champ est utile : -. -. L'utilisateur doit impérativement et immédiatement stocker une information et aucun champ n'a été prévu à cet effet. Ce peut être l'adresse d'un site web, une numéro de fax, une annotation sur un client mauvais payeur, etc. Plutôt que d"écrire l'information n'importe où autant utiliser le champ Remarques (1). C'est encore mieux si l'utilisateur a ensuite le réflexe d'avertir le concepteur. Celui-ci s'empressera d'ajouter des champs "SiteWeb", "NumeroFax" et "RatingClient" à la table, de reclasser l'information et d'adapter les formulaires en conséquence. Ceci lui sera d'autant plus facile si l'utilisateur a pris la précaution de préfixer l'information du champ Remarques : "SiteWeb: www.abcdef.com" ou "NumeroFax: 02/345.67.89". Une requête doit créer un clé ou un abréviation à partir des autres informations de l'enregistrement et ensuite regrouper les informations selon la clé ainsi générée. Le champ Remarques permet d'opérer en deux étapes.. Le champ EstMarque est réservé au concepteur de la base de données. Il intervient quand il faut marquer manuellement des enregistrements à traiter. Il se révèle aussi utile quand une sélection résulte de l'union ou de l'intersection de plusieurs requêtes successives. Une autre utilisation est la réalisation de "listes à cocher", problème aussi connu sous le nom de "problème de la pizza" :. Pizzas. Ligne de recette. Ingrédients. fig. 5.1 Le problème de la Pizza. Une pizza contient plusieurs ingrédients et chaque ingrédient intervient dans plusieurs pizzas. Pour résoudre la relation "plusieurs-plusieurs", il faut une table pivot. En principe, l'utilisateur encode sa recette ligne par ligne dans cette table. Il est cependant plus ergonomique de lui présenter la liste des ingrédients afin qu'il coche ceux qui sont nécessaires. L'information ainsi cochée est ensuite transférée dans la table centrale. Nous aurons l'occasion de revenir sur cette technique. Le champ EstDetruit permet de considérer un enregistrement comme supprimé sans pour autant le retirer de la base de données. A cause des règles d'intégrité. 1. On a déjà vu des bases de données dans lesquelles l'utilisateur a noté le numéro de fax dans le champ "adresse e-mail" sous prétexte que "c'était le seul endroit libre du formulaire". Pas grave en soi si ce n'est que pour un autre client le champ "adresse e-mail" contenait une date de fin d'abonnement. Et ainsi de suite. Comment est-il alors possible de tirer une liste de e-mailing correcte ?. H. Schyns. 5.1.

(20) Application Access. 5 - Quelques astuces de conception. référentielle, la suppression d'un enregistrement dans une table provoque la suppression de tous les enregitrement qui lui sont liés dans les tables situées plus bas dans la hiérarchie. Par exemple; l'effacement accidentel d'un pays dans la table Pays (niveau I) entraîne l'effacement de tous les codes postaux de ce pays (niveau II), suivi de l'effacement de tous les clients (niveau III) qui utilisaient ces codes postaux, suivi de l'effacement de toutes les factures (niveau IV) émises vers ces clients; suivi de l'effacement de toutes les détais de facturation (niveau V), de toutes les traces de paiement (niveau V) et de toutes les ristournes (Niveau V) de ces factures ! On voit d'ici la catastrophe. Le problème est le même quand on veut supprimer un ancien client alors que ses factures doivent être conservées pour des raisons légales. Evidemment, pour éviter de problème, on pourrait lever l'intégrité référentielle. Dans ce cas, après peu de temps, la base de données se retrouve remplie d'enregistrements orphelins inaccessibles, une autre plaie. Le problème est élégamment résolu par le champ EstDetruit. Cocher sur un éventuel bouton Supprimer ne fait rien d'autre que mettre la valeur "Vrai" dans ce champ sans pour autant supprimer l'enregistrement. Le contenu de la base de données reste intact. Il est ensuite très facile de faire des requêtes qui ne sélectionnent que les enregistrements qui ne sont pas détruits. Il est aussi très facile de "ressusciter" un client ou de défaire un effacement accidentel en remettant le champ EstDetruit à la valeur "Faux". Et, en fin de compte, il suffit de quelques requêtes pour purger physiquement la base de données des enregistrements marqués "détruits".. 5.2.. Un enregistrement incontournable. Toutes les tables doivent contenir un premier enregistrement dont le libellé est <Inconnu> ou <Néant>. Pourquoi ?. Remises. Clients. V. III. liste. Conditions paiement I. Factures paie. IV. reprend. Déclarations TVA I. reçoit. liste. Lignes Facturation V. acquitte. Paiements V. fig. 5.2 Le problème posé par la déclaration à la TVA. Reprenons un instant le modèle de données et examinons les tables liées directement à la Facture.. H. Schyns. 5.2.

(21) Application Access. 5 - Quelques astuces de conception. Les liens vers Lignes de facturation, Remises et Paiements ne posent pas de problème car étant situées en-dessous de Factures dans la hiérarchies, elles seront remplies après. Par contre, on s'aperçoit qu'il faut choisir une Déclaration TVA avant de créer la facture. Or la déclaration à la TVA n'est remplie qu'à la fin de la période donc, au moment où l'utilisateur encode la facture, la prochaine déclaration n'est pas encore définie. L'utilisateur ne peut évidemment pas attacher sa facture à une déclaration antérieure. Dès lors, les règles d'intégrité référentielles n'étant pas respectées, il est impossible de créer la facture. Pour contourner le problème, on crée un enregistrement <Néant> dans la table des Déclarations et c'est à cet enregistrement qu'on attache la nouvelle facture. Il sera facile par la suite de retrouver toutes les factures qui n'ont pas encore été déclarées quand on en sera à remplir la prochaine déclaration de TVA. Le même problème est susceptible de se poser à tous les niveaux : - un nouveau client au téléphone passe commande et raccroche avant que l'hotesse ait eu le temps de demander son code postal, - un nouveau produit arrive mais il faut l'avis du contrôleur pour définir dans quelle catégorie de TVA on doit le classer, - un client signale qu'il a effectué le paiement mais il omet de dire par quelle banque. Bref, la valeur <Inconnu> permet d'utiliser l'intégrité référentielle sans provoquer pour autant des blocages lors de l'utilisation de la base de données. Idéalement l'enregistrement <Inconnu> devrait posséder un code "0", ce qui facilitera les recherches. Ecrire le mot entre chevrons ( < > ) n'est pas anodin : il permet de placer le mot en tête dans les listes qui sont classées par ordre alphabétique (1).. 5.3.. Les listes de choix. Depuis la version 97, Access permet d'inclure dans les tables des champs qui sont des listes de choix.. fig. 5.3 Le problème posé par les listes de choix. 1. On obtient le même effet avec les parenthèses ( ) , les tirets - - ou le dollar $.. H. Schyns. 5.3.

(22) Application Access. 5 - Quelques astuces de conception. Cette pratique est absolument à proscrire. et ce pour plusieurs raisons tant philosophiques que pratiques : -. -. -. -. 5.4.. la liste de choix est en réalité une table ou une requête masquée. Il est largement préférable de placer les éléments de la liste de choix dans une table distincte ou dans une requête distincte. créer la structure d'une table est un acte du concepteur, remplir une table est le travail de l'utilisateur. Si la liste de choix n'a pas été correctement remplie, l'utilisateur sera obligé d'intervenir au niveau de l'objet table et non au niveau du contenu alors qu'il s'agit typiquement d'un problème de contenu. cette approche mélange l'analyse de la structure des données et l'analyse de leur présentation. C'est précisément le contraire d'une approche cartésienne. Structure et présentation sont deux choses indépendantes qui peuvent être réalisées par deux équipes distinctes. la solution n'est absolument pas portable dans un autre système gestion de base de données voire dans une autre version d'Access. si la liste de choix est définie par une requête, celle-ci est complètement invisible aux outils de diagnostic et d'analyse. Access a parfois du mal à gérer des requêtes complexes dans lesquelles interviennent des tables qui intègrent des listes de choix.. Clés multiples et hiérarchie. Dans les projets, les structures hiérarchiques sont fréquentes et sont souvent rapidement et mal modélisées. Prenons l'exemple d'un employé d'une société structurée en Divisions, Départements et Services. On crée donc rapidement une table des Divisions, une table des Départements et une table des Services. Pour définir l'affectation de l'employé, on doit l'attacher à chacune de ces trois tables. Une analyse (trop) rapide fournit une solution semblable à celle proposée ci-dessous : IdDivision. IdDepartement. Division. Département. emploie. emploie. Employé. IdService. Service. emploie. IdDivision IdDepartement IdService IdEmploye. fig. 5.4 Mauvaise analyse d'une structure. La solution est incorrecte car elle permet d'affecter indépendamment les trois niveaux de structure. Dans la réalité, chaque Division compte un certain nombre de Départements qui, eux-mêmes, abritent un certain nombre de Services. Le modèle suivant est déjà plus correct mais il contient néanmoins une source d'erreur :. H. Schyns. 5.4.

(23) Application Access. 5 - Quelques astuces de conception IdDivision IdDepartement. IdDivision. Division. abrite. Département. emploie. IdDepartement IdService. abrite. Service. emploie. emploie. Employé. IdDivision IdDepartement IdService IdEmploye. fig. 5.5 Meilleur mais toujours incorrect. -. -. en attachant l'employé à un Département, on l'attache fixe ipso facto à une Division précise à cause de la liaison n:1 entre ces deux tables. Donc le lien direct Employé-Division est redondant et source d'erreur; le même raisonnement s'applique au choix du Service. Le choix du Service impose le Département, lequel impose la Division.. Les liens directs Employé-Division et Employé-Département sont donc redondants. Il semble que les clés IdDivision et IdDepartement ne soient pas nécessaires dans la table des employés. Cependant, lors de l'encodage, il est plus ergonomique de sélectionner d'abord la Division puis un Département de cette Division puis un Service de ce Département. Comment sortir de ce problème ? La solution consiste à créer des clés primaires multiples : -. -. -. la Division étant la table la plus haute dans la hiérarchie, sa clé primaire est une clé simple (IdDivision); le Département a son propre identifiant (IdDepartement) et inclut la clé IdDivision en tant que clé importée. L'astuce consiste à unir ces deux clés afin d'en faire la clé primaire de la table Département. le Service a son propre identifiant (IdService) et inclut la clé double IdDivision+IdDepartement en tant que clé importée. A nouveau, ces deux clés (trois champs) sont combinées afin d'en faire la clé primaire de la table Service. l'Employé a son propre identifiant (IdEmploye) en tant que clé primaire et inclut la clé triple IdDivision+IdDepartement+IdService en tant que clé importée.. Division. IdDivision. abrite. Département. IdDivision IdDepartement. abrite. Service. emploie. IdDivision IdDepartement IdService. Employé. IdDivision IdDepartement IdService IdEmploye. fig. 5.6 Modèle correct, grâce aux clés et liens multiples. Dans cette situation, la table Employé est bien liée uniquement à la table Service mais on garde néanmoins une possibilité d'accès à chacune des composantes de la structure. Lors de l'encodage, il sera impossible d'introduire une incohérence lors des choix de la division, du département et du service. Un exemple de ce type sera développé dans l'application.. H. Schyns. 5.5.

(24) Application Access. 5 - Quelques astuces de conception. L'implémentation des clés multiples dans Access a été définie dans un autre document. Nous ne reviendrons pas sur ce point. Voici comment les liaisons multiples apparaissent dans le modèle des relations :. fig. 5.7 Implémentation dans Access. Dans certains cas, le nombre de niveaux hiérarchiques devient trop important, ou la logique d'intégration des niveaux devient trop complexe (1). Propager les clés de table en table devient lourd, complexe et inefficace. IdNiveau2. IdNiveau1. Niveau 2. Niveau 1. IdNiveau3. Niveau 3. Combinaisons admises. ... Niveau k .... Niveau N. IdNiveauk. IdNiveauN. Client. IdNiveau1 IdCombinaison IdNiveau2 IdClient IdNiveau3 : IdNiveauk : IdNiveauN IdCombinaison. fig. 5.8 Utilisation d'une table des combinaisons admises. Une solution élégante consiste à passer par une table des combinaisons admises. Cette table ne peut être remplie et modifiée que par une personne autorisée. A chaque combinaison correspond une clé simple et c'est cette clé simple qui est reprise par la table dépendante (ici, la table Client). Cette solution est particulièrement pratique quand il s'agit de structurer des directives administratives telles que des conditions d'octroi de bourses ou de primes. Le cas idéal est celui dans lequel le nombre de critères est élevé mais le nombre de combinaisons admises est restreint.. 1. Une agence de voyage propose des destinations à la mer ou à la montagne, chaque destination dispose de plusieurs hotels. Les hotels proposent des chambres à 1, 2 ou 3 lits mais tous ne proposent pas les trois types de chanbres. Certains font des réductions aux enfants, d'autres non.... H. Schyns. 5.6.

(25) Application Access. 6.. 6 - La chaîne Clients - Codes Postaux - Pays. La chaîne Clients - Codes Postaux - Pays 6.1.. Les Tables et Relations. 6.1.1. Créer la table Pays Cette table nous permet de sélectionner le pays du client (ou du fournisseur) afin d’appliquer le traitement TVA approprié aux factures qu’il reçoit (ou qu’il émet). Comme toutes les tables de niveau I, cette table est destinée à alimenter une liste déroulante. Elle contient quatre champs : CodePaysIso Ñ CodePaysCourrier NomPays EstUE. T2 T3 T30 O/N. Code du pays en deux lettres, comme les sites Internet (ex.: BE) Code du pays comme sur enveloppes ou autos (ex. : B) Nom du pays (ex. : Belgique) Oui, si le pays appartient à l'Union Européenne (ex. : Oui). auxquels on ajoute les trois champs "bons à tout faire" décrits au point 5.1 : Remarques EstMarque EstDetruit. T120 Texte libre O/N Oui, si l'enregistrement est marqué pour une sélection ultérieure O/N Oui, si l'enregistrement est détruit "logiquement". 6.1.2. Créer la table CodesPostaux Cette table nous permet de sélectionner la ville et le code postal du client (ou du fournisseur) en fonction du pays où il réside. Elle nous garantit que le nom d'une ville sera toujours orthographié de la même manière, quel que soit l'utilisateur qui procède à l'encodage de l'information. En laissant l'encodage libre, nous risquerions de nous retrouver avec plusieurs graphies pour une même ville : p.ex. : Saint Georges, Saint-Georges, St Georges sans compter les innombrables variantes résultant d'une mauvaise orthographe ou d'une faute de frappe. Cette table est aussi destinée à alimenter une liste déroulante. Elle contient quatre champs :. Ñ CodePaysIso Ñ CodeVille. T7. Code de la ville, créé à partir du code postal (ex.: 4000A). CodePostal Ville. T2 T12 T40. Code du pays en deux lettres comme les sites internet (ex.: BE) Code postal pouvant contenir des lettres (ex. : 4000) Nom de la ville (ex. : Liège). auxquels on ajoute comme de coutume les trois champs "bons à tout faire". Cette table présente plusieurs particularités intéressantes. Le champ CodePostal ne peut pas servir de clé primaire. En effet, plusieurs villes peuvent avoir un même code postal : n'oublions pas que nous sommes en Belgique et que plusieurs communes ont un nom flamand et un nom français (p.ex.: 1000 Bruxelles et 1000 Brussel). Inversement, une même ville peut posséder plusieurs codes postaux (p.ex.: 4000 Liège et 4020 Liège). Pour contourner ce problème, nous créons le CodeVille en ajoutant une lettre derrière le code postal (p.ex.: 1000 Bruxelles = 1000A et 1000 Brussel = 1000B). H. Schyns. 6.1.

(26) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. Si les codes postaux belges et français ne sont formés que de chiffres, il n'en va pas de même des codes postaux néerlandais et britanniques. Le champ CodePostal est donc de type texte.. 6.1.3. Créer la relation Pays - CodesPostaux. fig. 6.1 Relation Pays-CodePostaux. Il peut être dangereux de cocher l'effacement en cascade. En effet, si nous supprimons un pays par mégarde, nous supprimerons d'office tous les codes postaux patiemment encodés ! Evidemment, si nous voulons effectivement effacer tous les codes postaux d'un pays, nous devrons le faire manuellement en utilisant une requête paramétrée. Autre remarque : on comprend bien que le champ CodePaysIso, qui est la clé primaire de la table Pays soit repris dans la table des codes postaux car il est du côté "un" de la relation : Mais pourquoi est-il repris dans la clé primaire de la table CodesPostaux ? Malgré toutes les précautions prises, il pourrait arriver que deux villes situées dans des pays différents possèdent le même code postal et le même code ville. C'est notamment le cas de 2320 Hoogstraten (BE) et 2320 Luxembourg (LU). Pour éviter tout problème, nous créons une clé primaire composite en associant le CodeVille et le CodePaysIso. Ce n'est pas la seule solution possible : on pourrait décider de créer un code ville de la forme PPCCCCCCD où : -. H. Schyns. PP représente les deux caractères du code Iso du pays, CCCCCC représente le code postal cadré à droite, devant lequel on ajoute des zéros pour remplir la zone de 6 caractères, D sert à discriminer deux codes postaux d'une même ville.. 6.2.

(27) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. Dans ce système, le CodeVille de 4000 Liège deviendrait BE004000A. Toutefois, la table des codes postaux nous ayant été fournie telle quelle, nous n'avons pas pris la peine de changer son organisation.. 6.1.4. Créer la table Clients ou Fournisseurs Le modèle fait apparaître une table Clients ou une table Fournisseurs selon qu'il s'agit du facturier de sortie ou du facturier d'entrée. En réalité, ces deux tables sont très semblables : il suffit de remplacer le mot Client par Fournisseur partout où il apparaît, y compris dans les codes. CodeClient Ñ CodeVille CodePaysIso NomSociete NomResponsable PrenomResponsable Adresse ExtensionCP estAssujetti NumeroTVA CompteBancaire CompteIBAN Telephone Fax GSM Email. T6 T7 T2 T30 T30 T30 T50 T3 O/N T20 T20 T20 T20 T20 T20 T20. Code du client, de la forme NNNPXX (ex.: DUPJ01) Code de la ville tel que repris dans la table des codes postaux Code du pays car code conjoint dans CodesPostaux Nom éventuel de la société cliente Nom du client ou de la personne responsable dans la société Prénom de la personne responsable Adresse de la société (Rue et Numéro uniquement) Extension du code postal Vrai si le client est assujetti à la TVA Numéro de TVA au format international Compte bancaire "local" Compte bancaire au format international Numéro de téléphone national ou international Numéro de fax national ou international Numéro de GSM national ou international Adresse e-mail au format x.y@z.com. auxquels on ajoute comme de coutume les trois champs "bons à tout faire". Attardons-nous quelques instants sur quelques caractéristiques. Dans la plupart des bases de données, le CodeClient est très un numéro automatique. Pourquoi est-ce différent ici ? Ici, le CodeClient est créé à partir des trois premières lettres du nom du client (NNN), de l'initiale de son prénom (P) et de deux chiffres (XX) qui servent de discriminant. Ainsi, le code de Jean Dupont sera DUPJ01. Le 01 signifie que Jean Dupont est la première personne rencontrée dont le code commence par DUPJ. Si nous rencontrons ensuite un nouveau client nommé Jacques Dupontel, nous lui attribuerons le code DUPJ02. Par contre, Pierre Duplo aurait le code DUPP01. En pratique, la création des codes est un peu plus compliquée qu'avec un numéro automatique mais il suffit de deux requêtes pour régler élégamment ce problème. L'avantage d'un code de ce type est qu'il est beaucoup plus lisible, plus facilement traçable qu'un code 100% numérique et qu'il évite des erreurs grossières : même si je ne dispose que du code du client sur une étiquette de livraison, je sais qu'un colis libellé DUPJ01 ne doit pas être livré à la cliente Thérèse Ponsable (qui aurait un code compris entre PONT01 et PONT99). Autre particularité, tous les numéros de TVA, Telephone, Fax, GSM, Banque,… sont de type texte. Pourquoi ? Pour permettre un encodage libre. Il est habituel d'ajouter des points et des barres obliques aux numéros de téléphone (p.ex.: 042/12.34.56) ou des tirets dans les numéros bancaires (p.ex.: 000-1234567-12). Il est certain que nous pourrions H. Schyns. 6.3.

(28) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. utiliser des masques de saisie pour tenir compte de cette particularité mais n'oublions pas que notre commerce a une vocation internationale. La structure des numéros de téléphone allemands ne correspond pas à la structure belge, un compte bancaire britannique ne s'écrit pas comme un compte belge et il en va de même pour un numéro de TVA français ou luxembourgeois. Sans compter qu'il est plus facile de retenir un numéro 042/301.302 que 042/30.13.02 Les masques de saisie sont à proscrire dans une application car ils sont source de blocages lors de l'encodage de l'information. A quoi correspond le champ ExtensionCP ? Les Pays-Bas (et d'autre pays) ont un système de code postaux très détaillé qui inclut non seulement une référence à la vile et au quartier mais aussi une référence à la rue (p.ex: 6218DF Maastricht) ! Il s'agit généralement des deux dernières lettres du code postal. Si nous n'y prenons garde, nous devrons encoder un nouveau code postal pour chaque client. Il est plus logique de garder le code postal proprement dit dans la table des codes postaux (p.ex: 6218 Maastricht) et l'extension dans la table du client (p.ex: DF).. 6.1.5. Créer la relation Clients / Fournisseurs - CodesPostaux CodeVille et CodePaysIso sont repris dans cette table car ils forment la clé primaire de la table CodesPostaux, laquelle est du côté "un" de la relation :. fig. 6.2 Relation double CodePostaux-Clients. Notons que, dans ce cas précis, il peut être dangereux de cocher l'effacement en cascade. En effet, si nous supprimons une ville par mégarde, nous supprimerons d'office tous les clients ou fournisseurs de cette ville ainsi que les factures qu'ils ont reçues ou émises !. H. Schyns. 6.4.

(29) Application Access. 6.2.. 6 - La chaîne Clients - Codes Postaux - Pays. Les formulaires. Notre première chaîne de tables est terminée. Nous pouvons à présent consacrer un peu de temps à la définition de son interface (1). L'objectif est triple : -. vérifier les aspects fonctionnels et l'ergonomie de l'application, donner au client une première preuve de notre travail, permettre au client de commencer l'encodage de ses informations.. 6.2.1. Le formulaire des Pays Comme il s'agit d'une table de niveau I, son interface sera très élémentaire. Le formulaire des Pays est créé à l'aide de l'ASSISTANT FORMULAIRE. Dans la liste de choix, on sélectionne la table Pays :. fig. 6.3 Assistant Formulaire pour la table Pays. fig. 6.4 Choix des champs 1. Un peu de temps mais pas trop : laissez le client s'exprimer sur l'organisation du formulaire. C'est lui qui va passer sa vie devant cet écran, pas vous. Contentez-vous de lui fournir un premier jet, simple et propre afin qu'il puisse tester le fonctionnement de l'application. Ensuite écoutez ses remarques concernant la taille des fontes et les couleurs… S'il ne se plaint que de ça, bravo : c'est que tout le reste marche !. H. Schyns. 6.5.

(30) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. Dans l'écran suivant, on fait apparaître l'ensemble des champs de la table dans le formulaire sauf, éventuellement, les champs estMarque , EstDetruit et Remarque : Puis on clique sur le bouton SUIVANT. Après avoir sélectionné le style COLONNE SIMPLE, on choisit un fond d'écran aussi sobre que possible. Les images de nuages, de mappemonde ou de crépuscule sont peut-être jolies mais elles donnent des formulaires difficilement lisibles et très fatigants pour les yeux. Restons simples préférons un fond pastel avec un texte bien contrasté comme dans les modèles COULEUR 1, COULEUR 2, STANDARD ou PRINTEMPS. Nous sauvons ensuite ce formulaire sous le nom FRMPAYS. Quand on l'ouvre, le formulaire ressemble à ceci :. fig. 6.5 Formulaire brut. Modifions ce formulaire et faisons apparaître une zone d'en-tête et une zone de pied avec la fonction Affichage/En-tête & pied de formulaire. Ajoutons un titre avec l'outil Etiquette et mettons ces zones en couleur grâce aux palettes de peinture.. fig. 6.6 Les boites à outils du formulaire. fig. 6.7 Formulaire PAYS plus présentable. H. Schyns. 6.6.

(31) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. Remplaçons ensuite les noms des champs inscrits dans toutes les étiquettes par un texte plus agréable (p.ex. CodePaysIso devient Code Pays Iso). Augmentons la tailles des polices de caractères pour les rendre plus lisibles. Le formulaire Pays prend déjà un aspect plus agréable et plus professionnel : Les propriétés de formatage du formulaire sont reprises ci-après.. fig. 6.8 Propriétés du formulaire frmPays. 6.2.2. Remplir la table Pays Après avoir défini la structure de la table et créé le formulaire, on encode immédiatement quelques enregistrements à l'aide du formulaire. Ceci permet de vérifier : -. le bon transfert d'informations entre le formulaire et la table, la navigation entre les enregistrements, Pays CodePaysIso 00 BE LU. CodePaysCourrier B L. NomPays <Inconnu> Belgique G. D. Luxembourg. EstUE Oui Oui. Notez l’enregistrement <Inconnu> décrit au point 5.2. Le record <Inconnu> permet d'utiliser l'intégrité référentielle sans provoquer de blocages lors de l'utilisation de la base de données.. 6.2.3. Le formulaire des Codes Postaux En procédant de la même manière que pour les pays, on réalise facilement un formulaire convenable pour la lecture et l'encodage des codes postaux :. H. Schyns. 6.7.

(32) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. fig. 6.9 Formulaire CODES POSTAUX de base. 6.2.4. La liste de choix déroulante "Pays" L'ennui de ce formulaire, c'est qu'il demande d'introduire le code ISO du pays. Rappelons-nous que ce code ISO est le champ qui sert à faire le lien entre la table Pays et la table CodesPostaux :. fig. 6.10 Propriétés du formulaire frmPays. Nous devons donc inscrire dans une table de niveau II une information provenant d'une table de niveau I. Ainsi qu'expliqué au point 4.4, nous pouvons simplifier la tâche de l'utilisateur en lui présentant une liste dans laquelle il choisira. L'insertion d'une liste déroulante passe par quatre étapes : -. construire la requête qui va rechercher l'information voulue, construire le contrôle "Liste déroulante" alimenter la liste déroulante avec les données de la requête, régler l'affichage de la liste.. fig. 6.11 Lancer l'assistant de requêtes H. Schyns. 6.8.

(33) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. Access permet d'intégrer la requête dans l'objet "liste déroulante". Cette pratique est à proscrire pour des raisons semblables à celles évoquées au point 5.3. En fin de compte, il est beaucoup plus pratique de créer un objet requête séparé. On crée facilement une requête en MODE CREATION. Une requête destinée à une liste déroulante doit toujours contenir : -. le ou les codes nécessaires en premières positions, un ou plusieurs champs présentant une information plus conviviale.. Dans le cas qui nous intéresse, la requête doit récupérer le CodePaysIso, en tant que clé, et le NomPays, en tant qu'information conviviale. La liste est triée par nom de pays mais il est inutile de lister les pays qui ont été détruits :. fig. 6.12 Construction de la requête. La requête contient l'expression SQL suivante : SELECT FROM WHERE ORDER BY. Pays.CodePaysIso, Pays.NomPays Pays Pays.estDetruit=False Pays.NomPays;. Cette requête est sauvée sous un nom explicite : R_PaysListeId. L'insertion de l'objet "Liste déroulante" dans le formulaire ne présente pas de difficulté particulière : -. H. Schyns. commencer par désactiver la baguette magique de la palette d'outils pour éviter d'être entraîné dans le dédale des assistants (fig. 6.6); cliquer une fois sur l'outil "Zone de liste modifiable" de manière à enfoncer le bouton; placer le curseur de la souris dans le formulaire, non pas contre le bord, mais à la verticale du côté gauche des zones d'encodage (pas des étiquettes); cliquer une fois. L'objet est placé, son positionnement exact sera réglé plus tard; cliquer droit afin de faire apparaître le panneau des propriétés.. 6.9.

(34) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. fig. 6.13 Insertion de la liste déroulante. Il s'agit maintenant d'alimenter l'objet avec les données de la requête construite plus haut. Dans le panneau des propriétés, on choisit l'onglet DONNEES (ang.: data) :. fig. 6.14 Attacher la requête à la liste déroulante. -. -. la liste déroulante gère le champ CodePaysIso de la table source (Source contrôle), la liste a pour source une Table/Requête (Origine source), la requête source se nomme R_PaysListeId (Contenu), la colonne liée est celle qui contient l'information que l'on doit mettre dans le champ CodePaysIso (Source contrôle). Dans notre requête, cette information est dans la première colonne (1), les données acceptables sont limitées à la liste proposée, ce qui signifie qu'il est impossible d'ajouter de nouveaux pays à partir du formulaire frmCodesPostaux. les autres propriétés gardent leurs valeurs par défaut.. Nous devons à présent soigner la présentation de la liste déroulante. panneau des propriétés, on choisit l'onglet FORMAT (ang.: Layout) :. H. Schyns. Dans le. 6.10.

(35) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. fig. 6.15 Définir l'affichage. -. -. la requête appelée contient deux colonnes : le Code et le Nom (Nbre colonnes), les en-têtes (Titres) des colonnes ne sont pas affichés, la première colonne, celle qui contient le CodePaysIso, ne doit pas être affichée. Sa largeur est mise à 0 cm. Par contre, on affiche la colonne qui contient le nom du pays et on fixe sa largeur à 3 cm (Largeur colonnes). Ces deux chiffres sont séparés par un point-virgule. on affiche 8 lignes de données (Lignes affichées), les autres propriétés gardent leurs valeurs par défaut.. On choisit l'onglet AUTRES (ang.: Others) pour changer le nom du contrôle. Le nom par défaut Modifiable8 est remplacé par FCodePaysIso. On en profite pour vérifier les noms de tous les contrôles du formulaire. Un contrôle porte le même nom que le champ auquel il est lié, précédé de la lettre F (FCodeVille, FCodePostal, FNomVille), ceci afin d'éviter les confusions qui pourraient surgir par la suite. Après avoir vérifié le comportement de la liste déroulante et fait un peu de ménage dans le formulaire, voici ce qu'on devrait avoir :. fig. 6.16 Formulaire CODES POSTAUX terminé. Normalement, lors de l'ouverture du formulaire, le curseur se positionne dans le premier champ. Il passe d'un champ au suivant chaque fois que l'on appuie sur la touche [TAB]. Or, partant du formulaire généré par l'assistant, nous avons ajouté, supprimé et déplacé des contrôles. Il se peut que la navigation ne se déroule plus dans le même sens. Pour remettre les choses dans l'ordre, on ouvre le formulaire en mode "modification" et on active le menu Affichage / Ordre de tabulation. Cette H. Schyns. 6.11.

(36) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. commande apparaît aussi dans le menu contextuel. La fenêtre qui s'ouvre affiche une liste de tous les contrôles d'encodage. Pour déplacer un contrôle mal placé dans la liste, il suffit de cliquer sur la case située à sa gauche et de le remonter (ou le descendre) dans la liste.. fig. 6.17 Définir l'ordre de tabulation. 6.2.5. Remplir la table CodesPostaux Après avoir défini le formulaire, on l'utilise pour encoder quelques enregistrements sans oublier de prévoir un <Inconnu> : CodesPostaux CodeVille 00000 4000A 5000A 1000A 57000A 75000A. CodePaysIso 00 BE BE LU FR FR. CodePostal 0000 4000 5000 1000 57000 75000. Ville <Inconnu> Liège Namur Luxembourg Metz Paris. 6.2.6. Le formulaire des Clients ou des Fournisseurs On utilise la même procédure que précédemment pour lancer les bases d'un formulaire convivial pour la lecture et l'encodage des clients. Ce formulaire est beaucoup plus important que les précédents et il va falloir sérieusement le remanier :. H. Schyns. 6.12.

(37) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. fig. 6.18 Le formulaire CLIENTS de base. Ce formulaire demande d'introduire le code ISO du pays et le code de la ville. Ces deux champs servent en effet à faire le lien avec la table CodesPostaux et la table Pays :. Nous résolvons ce problème comme dans le cas du formulaire des codes postaux : par la création de deux listes déroulantes.. 6.2.7. La liste de choix "Pays" La liste déroulante Pays est presque en tout point identique à celle utilisée dans le formulaire des CodesPostaux. La différence est qu'ici, il est inutile de lister les pays pour lesquels aucun code postal n'est disponible. En effet, dans le formulaire Clients, l'utilisateur doit désigner un pays et une ville de ce pays. S'il choisit un pays pour lequel aucun code postal n'est disponible il provoquera une erreur lors de la sauvegarde de l'enregistrement. Il y a deux solutions à ce problème : -. soit utiliser une requête de regroupement, soit utiliser une requête avec le mot-clé DISTINCTROW.. La dernière solution est moins coûteuse :. H. Schyns. 6.13.

(38) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. fig. 6.19 Requête qui ne liste que les pays avec codes postaux. Le mot-clé DISTINCTROW doit être ajouté manuellement en passant à l'affichage en mode SQL : SELECT DISTINCTROW Pays.CodePaysIso, Pays.NomPays FROM Pays INNER JOIN CodesPostaux ON Pays.CodePaysIso = CodesPostaux.CodePaysIso WHERE Pays.estDetruit=False ORDER BY Pays.NomPays; Cette requête est sauvée sous le nom R_PaysAvecCodeListeId. Nous insérons ensuite un objet "Liste déroulante" dans le formulaire Clients; nous y attachons la requête et nous réglons l'affichage, exactement comme décrit au point 6.2.4. Pour la suite du programme, il est très important de renommer l'objet. Dans l'onglet "Autres", au lieu de lui laisser un nom tel que Modifiable16, baptisons le FCodePaysISO.. 6.2.8. La liste de choix "CodesPostaux" Pour construire la liste déroulante des codes postaux, nous suivons la même logique que ci-dessus. Cette fois, la requête est basée sur la table des CodesPostaux et on affiche les champs CodeVille, CodePaysIso, Ville et CodePostal. Il est inutile de lister les villes qui sont marquées comme détruites. La liste est triée par nom de ville et par codes postaux car une même ville peut avoir plusieurs codes postaux : SELECT. CodesPostaux.CodeVille, CodesPostaux.CodePaysIso, CodesPostaux.Ville, CodesPostaux.CodePostal FROM CodesPostaux WHERE CodesPostaux.estDetruit=False ORDER BY CodesPostaux.Ville, CodesPostaux.CodePostal;. H. Schyns. 6.14.

(39) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. fig. 6.20 Requête liste les villes et leur code postal. La requête est sauvée sous le nom R_CodesPostauxListeId. Il nous faut maintenant insérer un objet "Liste déroulante" dans le formulaire et lui faire afficher la liste. La requête compte quatre colonnes et seules les troisième et quatrième colonnes (Ville et CodePostal) doivent être affichées quand la liste est déroulée. Par contre, quand la liste est repliée, seul subsiste le nom de la ville. Nous verrons plus loin comment récupérer le code postal. Les propriétés qu'il faut modifier dans l'objet sont les suivantes :. Source contrôle Contenu Colonne liée Limiter à liste Nbre colonnes Largeur colonnes Largeur liste Nom. Propriétés Données CodeVille R_CodesPostauxListeId 1 Oui Format 4 0cm; 0cm; 4cm; 2cm 6cm Autres FCodeVille. fig. 6.21 Liste déroulantes des pays et des codes postaux non synchronisées H. Schyns. 6.15.

(40) Application Access. 6 - La chaîne Clients - Codes Postaux - Pays. 6.2.9. Synchroniser les listes Actuellement, les deux listes déroulantes sont indépendantes. Rien n'empêche l'utilisateur de choisir un pays dans une liste et un code postal d'un autre pays dans l'autre liste ainsi qu'on le voit à la fig. 6.21. Il nous reste a faire en sorte que, lorsque l'utilisateur a choisi un pays dans la liste, seules les villes de ce pays sont affichées dans l'autre liste. Ceci implique deux modifications : -. transformer la requête de la liste des villes en une requête avec critère écrire une petite procédure VBA événementielle de synchronisation.. 6.2.9.1 Transformer la requête La requête R_CodesPostauxListeId ne doit afficher que les villes qui appartiennent au pays choisi dans la liste FCodePaysISO. Il faut donc expliquer à la requête qu'elle doit lire le critère dans le champ FCodePaysISO qui se trouve dans le formulaire frmClients. La clause WHERE de l'expression SQL est modifiée : SELECT. CodesPostaux.CodeVille, CodesPostaux.CodePaysIso, CodesPostaux.Ville, CodesPostaux.CodePostal FROM CodesPostaux WHERE (CodesPostaux.CodePaysIso = [Formulaires]![frmClients]![FCodePaysIso]) AND (CodesPostaux.estDetruit=False) ORDER BY CodesPostaux.Ville, CodesPostaux.CodePostal; L'expression de la clause WHERE est un peu particulière. Pour obtenir une syntaxe correcte, l'emploi du générateur d'expression est recommandé : -. ouvrir la requête CodesPostauxListeId en mode MODIFIER, positionner le curseur dans la case CRITERES située dans la colonne CodePaysISO, faire un clic droit et sélectionner l'option GENERER, utiliser la fenêtre pour rechercher le champ voulu, cliquer sur le bouton COLLER puis OK.. fig. 6.22 Utiliser le générateur d'expressions pour obtenir la syntaxe correcte. H. Schyns. 6.16.

Figure

fig. 3.4 Introduire le suivi des paiements
fig. 3.7 Modèle du facturier d'entrée
fig. 4.3 Les tables de niveau I
fig. 4.4 Les tables de niveau II
+7

Références

Documents relatifs

D'ailleurs les changements consonantiques que l'on peut remarquer dans la syllabe principale sont les mêmes que dans les monosyllabes (en particulier, muong s &gt; t )..

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des

L’éminente dignité de l’imitation, selon Quintilien, ou de l’« innutrition », pour reprendre le mot de Du Bellay, a un nom, c’est la voie royale du pastiche qui

Ainsi les mécanismes de déformation considérés comme prépondérants pour la mise en forme d’un empilement HiTape sont la flexion hors-plan, le cisaillement plan (à vérifier) et

Load-Aware Shedding (LAS) is based on a simple, yet effective, idea: if we assume to know the execution duration w(t) of each tuple t in the operator, then we can foresee queuing

First, in an attempt to characterize the criticity of joining a new channel for the playback delay, we measure and analyze the PPlive system [1] focusing on the so-called

Pour prendre un exemple totalement étranger au terrain de Laplantine, mais avec une valeur d’illustration très directe pour nous, là l’on pouvait se satisfaire d’un

Afin de tester l’hypothese d’un modele transactionnel dans lequel l’alexithymie et la depression auraient un effet mediateur entre les dimensions emotionnelles et les