Empiler des tables (ou fusionner des tables) pour en obtenir une seule

Demandes d'aide
1

Bonjour à tous.
Je fait face à une difficulté que je n’arrive pas à surmonter, pour l’instant.
J’hérite de données qui sont organisées de la manière suivante :

  • chaque table donne les réponses données à une enquête pour l’année N, avec une colonne par question. Les labels de colonnes sont communs entre les tables, même si les colonnes (i.e. les questions) n’apparaissent pas forcément dans le même ordre.
  • chaque table contient une colonne ID qui donne une valeur d’ID pour chaque participant (un même participant peut être présent sur une ou plusieurs tables) et une colonne ANNEE qui donne l’année.

L’objectif étant, évidemment, d’analyser les réponses à travers les ans : par exemple, analyser l’évolution des réponses de l’ID A sur les trois dernières années.

J’ai préparé un petit exemple reproductiible : https://grist.numerique.gouv.fr/o/docs/cdLG3hBbsJjc/Untitled-document?utm_id=share-doc

Je vois plusieurs stratégies.

  • La stratégie optimale du point de vue du traitement des données, est de combiner les tables (empiler les lignes, en respectant l’ordre peut-être changeant des colonnes, donc sans faire de copié-collé). Une fois cela fait, il sera facile d’aller chercher des séries à travers les années.
    [Je pourrais combiner les tables sur mon logiciel de traitement de données favoris, puis charger le jeu de données global dans Grist, mais j’aimerais que d’autres utilisateurs puisse réaliser toute la procédure sous Grist.]

  • J’imagine des stratégies « à défaut » avec une table contenant toutes les combinaisons d’années et d’ID : combinaisons qui devraient être dynamiques, et pas « à la main » (=>si je rajoute une table contenant une année supplémentaire, les combinaisons s’enrichissent automatiquement).
    Puis aller chercher, via une formule, pour chaque ligne (i.e. pour chaque combinaison d’année et d’ID) la valeur de la variable qui m’intéresse.
    Mais cela nous ramène à un problème précédemment évoqué et à une limite de l’outil je pense : Générer une séquence de dates dans une nouvelle table

La stratégie d’empilement de tables est-elle possible dans Grist ?
A défaut, est-ce possible d’avoir une table contenant dans ses deux premières colonnes toutes les combinaisons possibles d’ID et d’années, màj automatiquement à partir des données?

Merci par avance pour vos retours et toutes vos pistes de solutions! :slight_smile:

Bonne journée,

Elie

2

Piste intéressante :
l’import des données annuelles successivement dans une même table pourrait constituer une solution, mais les vraies données contiennent de très nombreuses colonnes et j’ai peur que la correspondance entre les noms de colonnes ne soit imparfaite (elle sera de toute façon très complexe à surveiller).
Sans compter que les tables semblent volumineuses -pour Grist- et que l’import rame et est très complexe…
Edit : effectivement, ça ne marche pas, il y a trop de colonne et Grist n’arrive pas à gérer la « cartographie de colonne »…

3

Que ce soit la solution 1 ou la solution 2 il doit y avoir le même problème de volumes de données, non ?

La deuxième solution me semble complexe à mettre en place.
Et il faut voir la récurrence du besoin. S’il s’agit de mettre à jour une table de cumul une fois par an, il n’est probablement pas nécessaire de passer du temps à construire un système complexe.

Pour la problématique de correspondance des colonnes, elle s’imposera dans les deux solutions de toute façon si on n’est pas capables de repérer automatiquement (ou facilement) la correspondance des colonnes. Difficile, dans la deuxième solution, d’indiquer à Grist où aller chercher les informations si les colonnes n’ont jamais le même nom.
Pour avoir des données cumulées il vaut mieux penser en amont (quand c’est possible) à avoir une structure stable.
Sinon, il faut retraiter manuellement. Par exemple en faisant une extraction sous Excel et en modifiant les noms de colonnes, ou en faisant tout le mapping à la main lors de l’import.

4

Merci pour le retour.
Effectivement pour l’instant je compile les tables avec R en amont…C’est frustrant dans la mesure où le jeu de données a vocation à être alimenté par des livraisons annuelles de données, et va être amené à évoluer.