Jump to content
David13

Traitement statistique de données issues de rubriques à cases à cocher

Recommended Posts

Bonjour, 

Chercheur en anthropologie biologique j'ai mis au point une base de données permettant de recueillir le maximum d'informations pathologiques sur un squelette en fonction du secteur ou de caractères anatomiques précis. Pour chaque caractère plusieurs atteintes pathologiques peuvent être présentes et, ayant beaucoup de critères, j'ai opté pour des rubriques de cases à cocher dans un soucis de rapidité afin de pouvoir sélectionner tous les éléments présents en quelques clics.

A terme, il me faudra exploiter de manière statistique ces données en passant à l'échelle de la série de squelettes complètes mais je ne sais pas si cela sera possible compte tenu du fait que lors de l'export chaque rubrique sera susceptible de contenir plusieurs données textuelles. Ma question est donc la suivante : est-il possible d'exploiter indépendamment et de façon statistique les données issues de rubriques à choix multiples ? En d'autre termes, me sera-t-il possible de gérer les différentes valeurs présentes dans une même rubrique avec des logiciels comme "R" voire Exel (je n'en suis pas encore là mais préfère m'assurer que cela sera possible) ou faut-il observer la règle du "une info, une case" (une info, une rubrique) ? Dans l'absolu convertir les case à cocher en rubrique ne pose pas de problème (sauf temporel) mais cela ferait passer leur nombre d'environ 2000 à au moins 20000 ce qui engendrera une augmentation significative d'informations à saisir.

Auriez-vous des réponses, conseils ou suggestions ?

En vous remerciant

 

David

Share this post


Link to post
Share on other sites

Bonjour,

il y a une heure, David13 a dit :

Ma question est donc la suivante : est-il possible d'exploiter indépendamment et de façon statistique les données issues de rubriques à choix multiples ? En d'autre termes, me sera-t-il possible de gérer les différentes valeurs présentes dans une même rubrique avec des logiciels comme "R" voire Exel (je n'en suis pas encore là mais préfère m'assurer que cela sera possible)

Non

il y a une heure, David13 a dit :

faut-il observer la règle du "une info, une case" (une info, une rubrique) ?

Non, c'est une valeur dans un champ d'un enregistrement d'une table. Si on a donc 20 valeurs à cocher, cela constituera 20 enregistrements d'une table, potentiellement stockées dans la même colonne de cette table, ou dans des colonnes distinctes selon qu'on veut gérer différents formats de données ( nombres, dates, texte, etc )

D'une manière générale, il est toujours essentiel avant d'ajouter un champ dans une table de savoir comment on va en extraire les données. Un système de case à cocher ne comporte aucun intérêt et est même assez dangereux dans la mesure où les valeurs qui sont stockées sont issues d'une source qui est liée à l'interface de saisie ( par la liste définie dans le style de contrôle du modèle ). On peut déconnecter cette "source" ou en changer les valeurs sans que le contenu du champ ne soit impacté, et donc se retrouver avec des valeurs saisies qui n'ont plus l'intégrité requise.

Même si on peut importer des données Json dans R, et donc disposer alors d'une gestion par propriétés  ex : genre:M, Age:15-25, Taille:150-165cm - , le plus simple est tout de même de disposer d'une table dans laquelle chacune de ces propriétés pourra être extraite individuellement ou collectivement, quitte à reconstituer alors l'objet Json en question.

La question à se poser est de savoir si au final on aura besoin de disposer des données "non cochées", c'est à dire si les données seront analysées sur la base des critères possibles ou seulement ceux existants. Concrètement, l'analyse aura-telle besoin de restituer le résultat d'une série de valeurs homogènement structurées : ex : pour un individu de 17 ans, attends-ton un résultat du type "-15ans:0, 15-25:1, 26-35:0, 31-50:0, 51-75:0, +75:0" ou "age :15-25"

Share this post


Link to post
Share on other sites

Bonsoir, 

Merci pour votre réponse. Pour répondre à votre question, non les données "non cochées" ne sont pas prises en considération dans le traitement ; l'idée finale et de pouvoir quantifier à l'échelle d'une série d'individus tous les types d'atteintes pouvant être rencontrées au niveau d'un caractère osseux en particulier, de l'os dans sa globalité, du membre (etc.) en fonction de l'âge, du sexe... 

Si j'ai bien compris il est donc préférable d'avoir une rubrique par lésion en rapport avec un caractère osseux et "regrouper" les différentes informations ayant traits à un individu par la suite ? Encore une fois, cela ne pose pas de problème en soi mais ayant 3577 rubriques à choix multiples l'enregistrement va multiplier les saisies pour renseigner la présence ou l'absence de chacun d'entre eux ; cela va être sportif !   

 

Share this post


Link to post
Share on other sites

J'ajouterais que :
Une rubrique saisie au travers des cases à cocher contient au final les valeurs cochées séparées par un caractère spécial (0x0B).

A l'export, on aura donc "A•C•E•B" par exemple (le "•" représente le 0x0B ou 0x0B00). A noter que la liste est constituée à mesure et donc la position des valeurs reflète l'ordre dans lequel on a coché/décochés les cases.

Je doute fort que "R" sache interpréter ça directement. Excel lui, utilise le caractère "0x0D" (ou 0x0D00) mais à l'intérieur de guillemets.
Après il est toujours possible de faire une "moulinette"qui mets en forme les données.

Pour rejoindre ce que dit Ugo (sans aller jusqu'au "dangereux"), l'utilisation des cases à cocher est "délicate" :unsure:

 

Share this post


Link to post
Share on other sites

Bonsoir,

Il y a 5 heures, David13 a dit :

Bonsoir, 

Encore une fois, cela ne pose pas de problème en soi mais ayant 3577 rubriques à choix multiples l'enregistrement va multiplier les saisies pour renseigner la présence ou l'absence de chacun d'entre eux ; cela va être sportif !   

 

J'ai du mal à voir le schéma exact mais je doute que ce soit si complexe. Voici un petit exemple

 

 

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

properties.fmp12

Share this post


Link to post
Share on other sites

Bonjour, 

Le modèle que vous proposez est très intéressant et pourrait parfaitement convenir. Je ne suis pas sûr en revanche d'être en mesure de mettre en place et d'appliquer un système comme celui-ci car je ne maîtrise pas assez Filemaker ; c'est le problème de la recherche quand des spécialistes dans un domaine très particuliers doivent s'improviser "informaticiens".

Vos réponses m'ont toutefois été d'une grande aide et vont me permettre d'avancer ; je vous en remercie.

Cordialement.

David 

Share this post


Link to post
Share on other sites

Bonjour,

Ce n'est en effet qu'une modélisation, bien souvent ce type d'exercice est de toutes façons peu exploitable et il ne s'agissait pas de répondre précisément au besoin mais d'expliciter la structure "n enregistrements d'une table vs n rubriques d'un enregistrement"

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...