L’une des grandes règles – pour ne pas dire la principale règle – du développement de bases de données relationnelles est d’éviter systématiquement toute possibilité de double saisie. Ce qu’occasionne nécessairement un fichier plat, c’est-à-dire sans table ni lien entre les données. Ainsi, dans un fichier regroupant par exemple des salariés, nous devons répéter autant de fois que nécessaire la raison sociale de l’entreprise dans laquelle ils travaillent ainsi que l’adresse professionnelle qui y correspond.

Apparaît alors le relationnel, et avec lui la nécessité de modéliser les données (d’en prévoir la circulation), dès que l’on crée une table Société et une table Salarié et un lien entre elles deux, de telle sorte que la société ne soit saisie qu’une seule fois et soit néanmoins liée à tous les salariés qui y travaillent.

Cette règle de base, on la conçoit donc parfaitement pour tout ce qui est données gérées par votre développement FileMaker. Cela peut être des produits que vous avez en stock et que vous vendez : ces produits ne sont saisis qu’une seule fois, même si vous les vendez plusieurs fois 😉 Et je peux multiplier à l’envie les exemples…

Lorsqu’on parle de « gestion de données », on est le plus souvent dans la perspective d’une activité commerciale ou associative où il faut saisir, importer, transformer, partager des données : des timbres pour un club philatéliste, des clients, des produits en vente, des patients pour un cabinet médical ou paramédical, etc. Ces données sont alors le coeur de votre activité, votre trésor. Mais les données se limitent-elles à cela ?

Dans votre base de données, circulent en parallèle à ces données pour lesquelles vous avez construit votre base d’autres données… Celles-ci sont relatives soit à la base elle-même, soit à vous-même… Elles en sont comme le coffret contenant et protégeant votre trésor…

Je m’explique…

Lorsque vous écrivez un courrier, un devis, une facture, le corps de ces documents récolte ces précieuses données pour lesquelles votre base a été conçue : le message que vous saisissez à l’adresse du client ou prospect, le ou les produits ou services que vous lui vendez… Mais dans l’en-tête et le pied de page, il y a des informations identitaires et légales qui permettent à votre correspondant de vous connaître et qui posent éventuellement un cadre dans votre correspondance (date limite de règlement, etc.).

Si vous possédez plusieurs modèles de courriers et/ou de devis/factures, vous pouvez recopier « à la main » toutes ces informations. On se retrouve alors dans un fonctionnement du type fichier plat : les données sont répétées et si une modification doit être apportée dans votre adresse par exemple, il faut mettre à jour manuellement tous les modèles utilisant cette adresse…

Vous sentez bien ici l’absurdité de la situation !

De manière encore plus subtile, si vos modèles sont bien conçus, c’est-à-dire, si l’utilisateur y retrouve à chaque fois les mêmes boutons ou quasiment, placés aux mêmes endroits, il y a de fortes chances pour que là aussi, on trouve des données qui se répètent, même si ces données n’ont rien à voir avec celles qu’est censée gérer votre base…

Plus encore, ces données relatives à votre identité ou au fonctionnement de votre base peuvent être calculées et par calcul, s’adapter au contexte où elles doivent apparaître…

C’est donc à ces données bien particulières que je souhaite m’attaquer durant quelques articles, vous invitant par là à porter votre attention sur ces aspects pas si secondaires de vos bases de données 😉

Alors, êtes-vous prêts à me suivre dans cette nouvelle aventure ?

Marie-Charlotte Potton

Article suivant

Tags: Données, gestion de données