Je suis chargé de mission au ministère de la culture et je commence la prise en main de Grist pour tenter d’en faire un outil de suivi de nos contrats économiques passés entre les DRAC, les régions, et le Centre national du livre pour le soutien aux entreprises du livre.
J’ai commencé avec les données 2024 transmises par nos partenaires afin de voir si Grist pouvait répondre à mes besoins. Je pense que la logique de base de données s’applique parfaitement à ces enjeux.
Cela étant, le fonctionnement des contrats de filière livre est le suivant : les 3 partenaires réunis en comité décide par exemple d’aider une librairie, la région va par exemple donner 2000 €, la DRAC 1000 € et le CNL 1000€. Sur une autre librairie, les sommes peuvent être différentes, et parfois un des trois partenaires peut s’abstenir, au cas par cas.
Afin de bien identifier ces situations, j’ai fait le choix de créer une ligne par aide par partenaire. Soit parfois 3 lignes pour la même librairie. C’est fonctionnel pour retrouver ensuite les totaux par partenaire, mais cela a tendance à fausser le nombre de librairies aidées (on retrouve 3 lignes de la même librairie alors qu’il s’agit d’une seule aide, répartie entre trois partenaires). Cela pose aussi des problèmes si j’associe un objectif de l’aide (reprise de commerce, travaux etc.) qui vont apparaitre trois fois alors qu’il s’agit d’un même projet.
Pensez-vous qu’il pourrait être utile de faire une seule ligne par librairie aidée, mais de pouvoir y ventiler correctement la répartition financière entre partenaires ?
En gros, vaut-il mieux traiter comme enregistrement chaque montant apporté ou chaque bénéficiaire ? Et dans ce dernier cas, comment lier un type de financeur à un montant pour bien suivre la traçabilité des financements ?
Cela pose aussi des problèmes si j’associe un objectif de l’aide (reprise de commerce, travaux etc.) qui vont apparaitre trois fois alors qu’il s’agit d’un même projet.
Il vous manque probablement une table « Projet » ou « Contrat », dans laquelle vous stockez le nom du projet, l’objet de l’aide, la maison aidée et que vous référencez ensuite dans votre table d’aides accordées
Bonjour et merci pour votre réponse, et pour cette confirmation.
Effectivement, une table projet parait une bonne chose pour y mettre dans chaque enregistrement des références multiples : reprise, création, travaux etc.
Deux choses cependant :
nous ne donnons jamais de nom aux projets, le nom du commerce ou de l’établissement suffit généralement. Or il est ici extrait d’une autre table (une base de donnée de librairies) en colonne de référence. Je ne peux donc pas m’en resservir comme référence dans une autre table.
en créant deux tables, je ne pourrai plus vraiment utiliser un seul formulaire pour faire remplir les types de projet et les montants par des tiers externes.
est-ce qu’une référence bi-directionnelle pourrait m’aider en mode many to one ? puisqu’il y a de manière caractéristique plusieurs aides pour un seul projet.
nous ne donnons jamais de nom aux projets, le nom du commerce ou de l’établissement suffit généralement. Or il est ici extrait d’une autre table (une base de donnée de librairies) en colonne de référence. Je ne peux donc pas m’en resservir comme référence dans une autre table.
Je vous conseille de faire une formule pour nommer de façon explicite vos projets, en combinant l’année + la librairie (vous pouvez ajouter aussi l’objectif de l’aide mais j’ai l’impression que ces deux champs suffisent pour créer une clé unique) : ce qui donnerait (à adapter en nommant bien les champs) " - ".join(filter(None, [$annee.annee, $maison_aidee.nom, $librairie_aidee.nom))
Attention : si l’un de ces champs n’est pas de type texte (mais date ou autre), il faudra écrire str($annee.annee)
en créant deux tables, je ne pourrai plus vraiment utiliser un seul formulaire pour faire remplir les types de projet et les montants par des tiers externes.
Merci beaucoup, c’est très utile. Les clés sont effectivement uniques mais elles ne fusionnent pas lorsqu’il y a trois lignes de financement par projet… Cela me fait donc autant de clés de référence et les données des projets se dispersent.
Mais peut-être que je ne mets pas les références dans la bonne table.
J’ai créé deux tables, Projets et Aides, en prenant quelques libertés avec les types de colonnes (mais ça ne change pas le fond). L’objectif est de ne jamais répéter une info (principe DRY pour Don’t repeat yourself) : si la Région est toujours la même pour un projet donné alors on en fait un attribut du projet et pas de l’aide (sinon il faudrait le répéter à chaque aide du même projet), etc. Mais on se débrouille pour afficher quand même les infos portées par les projets dans la table des aides, grâce aux champs rapportés.
Ensuite, vous pouvez faire toutes les tables de synthèse que vous voulez pour afficher les sommes par projet, par bénéficiaire, par financeur, par année et par financeur, etc.
N.B. : c’est pas commode du tout de gérer les bénéficiaires sur deux colonnes selon s’ils sont une librairie ou une maison d’édition. Je recommande de faire une seule colonne Bénéficiaire de type Référence pointant vers une table Bénéficiaires comprenant un Choix unique qui vaudra « Maison » ou « Librairie ». J’espère que c’est clair
Effectivement ce principe de « ne pas se répéter » n’était pas explicite pour moi. Il fallait mieu définir où est-ce qu’il vaut mieux définir une valeur, et où est ce qu’il est préférable de la faire se répeter avec une formule.
En ce qui concerne les bénéficiaires, je gère pour le moment sur plusieurs colonnes car elles sont reliées à des bases nationales respectivement de librairies et de maisons d’édition. Pour faire une colonne unique bénéficiaire, il me faudrait donc fusionner ces bases, et rajouter dans une colonne si chaque enregistrement correspond à une librairie ou à une maison d’édition…
Enfin, une question générale, dans l’ensemble pensez-vous qu’il est préférable d’utiliser comme vous l’avez fait des choix uniques (par exemple pour sélectionner une région, ou un type de bénéficiaire etc.) ou de créer une table à part qui les regroupe (par exemple une table avec une colonne qui a toutes les régions françaises) et de les relier dans les autres tables par une référence ?
Il y a deux règles assez simples que je me fixe pour répondre à cette question :
une référence s’impose dès lors que vous devez gérer des attributs sur l’objet : par exemple, si chaque Région doit être associée à un identifiant unique, un exécutif local, une liste de villes… créez une table dédiée pour stocker les régions
si vous n’avez pas besoin d’attributs, alors un choix unique est préférable car : plus simple à gérer dans vos formules, mise en forme possible, etc. SAUF si ces choix uniques sont utilisés à plusieurs endroits dans le document et doivent être mis à jour régulièrement, auquel cas une table dédiée et un système de références permet d’en faire plus facilement une source de vérité.
Je me permets de revenir sur le document que vous aviez proposé. Vous y écriviez :
« Ensuite, vous pouvez faire toutes les tables de synthèse que vous voulez pour afficher les sommes par projet, par bénéficiaire, par financeur, par année et par financeur, etc. »
Cela, j’y arrive assez bien. Mais comment pourrions-nous faire une table de synthèse par objet de l’aide (reprise, travaux, animation etc.) qui regroupe les montants accordés ? C’est sans doute l’affaire d’une formule bien rédigée mais je n’y arrive pas malgré l’assistant AI. En effet, il y a des objets dans la table « projets » et des montants dans la tables « aides ». Or, il faudrait regrouper les X montants d’aides pour chaque projet, puis regrouper par objet.
Très utile pour avoir des masses financières par type d’action !
C’est tout simple : vous savez que vous allez faire une table de synthèse sur la table Aides, puisque c’est celle qui liste toutes les aides avec leur montant. Il faut donc ajouter un champ rapporté « Objet de l’aide » dans cette table :
