Comment aborder les bases de données

Des tables, des requêtes, des formulaires et des états

Là où vous ne connaissez, habituellement, qu’une feuille de calcul de tableur, une base de données se construit de manière modulaire avec :

• des tables, qui contiennent l’information. Il est important de comprendre qu’il en faut plusieurs, pour permettre de lier une information à plusieurs autres : Mme Michu est la mère de Kévin Michu et de Beverly Michu. On aura donc plusieurs enfants pour une seule maman, pas l’inverse (les cas de polygamie sont envisageables, mais ils réclament un peu d’organisation). On crée donc une table des enfants, et une table des mamans, pour ne pas devoir recopier les coordonnées de Mme Michu deux fois, une fois dans la fiche de Kévin, une fois dans la fiche de sa soeur (avec le temps gâché et les risques d’erreurs que cela comporte)

Les tables contiennent l’information brute, c’est un endroit où l’on interviendra pas dans l’exploitation normale d’une BD. On n’écrit pas directement dedans, source d’erreurs, mais via les formulaires qui encadrent l’entrée des données.

• des requêtes, qui sont en fait le coeur du système. Je pense pouvoir résumer en disant que la requête en visualisation ressemble beaucoup à notre feuille de calcul du tableur qu’on faisait avant, avec éventuellement les sélections et les tris qu’on pouvait souhaiter faire (mais sans mise en forme).

Contrairement aux élèves, les requêtes sont vraiment au centre du système. Ce sont elles qui font les calculs à partir des données brutes : elles contiennent donc d’autres informations, mais que des choses reconstructibles d’après le reste.

• des formulaires, qui sont des aides à la saisie de l’information : au lieu de tout saisir, colonne après colonne, dans l’interminable ligne d’une feuille de calcul, on se construit un formulaire clair, aéré et coloré, dans lequel on peut faire apparaître des résultats de calcul, des listes dans lesquelles on va chercher une information déjà saisie ailleurs ; on peut aussi remplir la base à l’aide d’un formulaire "QCM".

Un formulaire doit être rattaché à une requête, pas directement aux tables : en effet, les tables sont stupides, alors que les requêtes sont intelligentes. Les requêtes assurent les liens logiques entre les tables, et un formulaire permet souvent d’alimenter plusieurs tables en parallèle, facilement et efficacement.

• des états, qui, exploitation graphique d’une requête, vous permettront d’exprimer les informations intéressantes de la base de données à l’extérieur. On peut avoir des états imprimés, sous forme d’extractions utilisables ailleurs, mais aussi sous forme de courriels ou de pages web toutes faites, tout est possible à qui sait faire !

Ainsi, en traitant des données dans un tableur, on se posait constamment la question de la tête que cela peut avoir à l’impression. On s’en fiche au stade des tables et même de la requête, car l’état aura exactement la tête qu’on lui donnera : courrier personnel comme lorsqu’on fait des fusions avec le traitement de texte, mais aussi des tableaux, des listes, des statistiques avec des graphiques... Pour ceux qui connaissent Alise Arc-en-self, par exemple, en modifiant le courrier-type d’une facture, vous avez déjà retouché un état de base de données. Là , vous fabriquerez tout ce que vous voulez de toutes pièces.

L’ergonomie générale du truc

Elle laisse franchement à désirer, comme je le disais en exergue, on n’aborde pas la BD en novice comme on l’a tous plus ou moins fait avec le traitement de texte voire le tableur, en tâtonnant et en obtenant d’emblée un résultat, même imparfait.

D’une part, comme il est nécessaire de concevoir la structure des tables, on est obligé d’avoir réfléchi posément à ses besoins préalablement. Pas de psychose non plus, à notre niveau il n’est pas complètement vrai que l’on ne peut plus modifier les tables une fois qu’on a commencé à travailler. Mais il reste vrai que certains mauvais choix peuvent coûter cher.

Ensuite, avant d’avoir un bout de résultat, il faut savoir créer des tables, des requêtes, des formulaires et des états. Si l’on s’y met sans aide préalable, on se retrouve face à une équation à quatre inconnues, en quelque sorte, alors la chance d’arriver à quelque chose tout seul du premier coup est assez faible, en tout cas pour un lapin rouge d’intelligence moyenne.

Cela dit, je dois préciser que certains outils sont moins pénibles que d’autres. Dans un lointain passé, j’ai tâté des BD avec Paradox puis avec FileMaker Pro, c’était assez facile à attaquer. Mais, évolution du marché informatique et pratiques de l’EN aidant, à l’heure présente c’est MS (r) Access (r) ou le moteur dBase d’OpenOffice.org. Et ces deux derniers ne sont pas faits pour les candides. Ca ne les rend pas mauvais, juste moins sympa.

Le mode création

Avec le traitement de texte (tel qu’on le rencontre depuis 15 ans) et le tableur, on voit c’qu’on voit, et c’est bien assez. Mais quand on fabrique une base, on est constamment en train de naviguer entre le mode création de sa table/requête/formulaire/état et sa visualisation. Là encore, ce n’est pas intuitif : les deux sont importants, l’un ne va pas sans l’autre. Mais c’est justement parce que l’on a accès au concept en direct, que en fin de compte l’information sera traitée efficacement.

Attention : syntaxe barbare

On arrive assez rapidement à comprendre, dans le tableur, comment faire des calculs simples voire un peu plus pointus, en réfléchissant un peu. Dans Access et OOoBase, c’est parfois seulement un peu différent : pour des calculs simples en tâtonnant on y arrive.

Si l’on veut des trucs comme des statistiques ou des conditions logiques, on en arrive souvent à devoir affronter un monde barbare, avec l’utilisation du langage SQL, des macros ou du VisualBasic pour obtenir ce que l’on désire.

Un certain nombre d’assistants existent pour créer des fonctions de base, mais dès par exemple qu’il faut les combiner entre elles, il faudra avoir le courage de cogner dans le code en direct. Ou en semi-direct, comme moi : je demande à deux assistants de me faire deux trucs distincts, je copie le code sorti par l’un des deux et je l’ajoute au résultat du second : ma deuxième fonction me fait désormais les deux tâches que je voulais voir faites d’un seul clic. C’est pas super-productif au moment de la construction de l’outil, mais ce qu’il faut avoir en vue, c’est le gain de productivité à l’exploitation, l’investissement de départ est vite oublié tant on est efficace avec de bons outils.

Bref, comme avec tout bon logiciel, vous avez toujours plusieurs manières d’obtenir un résultat équivalent. Avec l’expérience, vous vous forgerez des habitudes et des goûts en la matière, et après les premières réussites, vous ne vous laisserez plus impressionner. D’ici-là, copions sans toujours comprendre des formules retrouvées dans diverses ressources d’aide, la maîtrise viendra en temps.

Mais mes collaborateurs ne seront jamais capables d’utiliser ça !

Bien au contraire : une fois l’outil créé, il sera extrêmement plus simple, rapide et efficace à utiliser au quotidien, quelle que soit la complexité de l’information manipulée.

Une bonne base de données, c’est un bon formulaire de saisie, et des états préparés au poil. Vos collègues n’utiliseront que ces deux ressources, sans rien savoir des tables et de leur structure modulaire, ni même des requêtes. Mais ils auront le plaisir de pouvoir rentrer des infos dans la bécane de la manière aussi simplifiée et ergonomique que possible, avec des risques d’erreur fortement limités ; ils seront enchantés de pouvoir imprimer à tous les coups leurs informations dans des tableaux/courriers (...) propres et nets, sans s’inquiéter de la mise en page ou de quoi que cela soit d’autre.

Vos bonnes résolutions

Vous avez résolu de vous fabriquer des outils en BD avec Access ou OOoBase ? C’est chouette, mais ce genre de bonnes résolutions est difficile à tenir, car quand on débute, on perd vite pied...

Pour vous soutenir dans l’effort, un truc formidable que vous n’osiez pas espérer : envoyez votre boulot à l’IZ, même s’il n’est pas terminé ou pas encore testé en production. Vous gagnerez un regard extérieur sur votre boulot, pour peut-être le corriger, et votre travail étant publié, parfaitement anonymisé comme il se doit, sur le site, vous gagnerez l’estime des collègues qui pourront bénéficier de vos efforts.

C’est pas une belle perspective, tout ça ?

Un essai de bibliographie par Ndoyi

Pas évident d’orienter le novice sur un bouquin qui règle le problème. Il y a les digests qui ne font que du pas à pas, sans expliquer l’esprit (j’ai consulté ACCESS 97 Collection "formations rapides" chez DUNOD - c’est maintenant basé sur la version 2003). Il y a les bibles : ACCESS au quotidien, 800 pages, ouvrage de référence Microsoft. Le volume fait peur mais finalement, c’est le plus
accessible.

J’ai bossé VBA pour ACCESS sur la collection "pour les nuls", l’esprit est adapté à l’exercice (dédramatiser l’outil).

Et puis il y a les forums : celui de Microsoft a fermé l’an dernier. Les MVP
ont les leurs, moins fréquentés mais les hôtes sont très serviables.
Ex : http://www.3stone.be/access/index.php