Bonjour,
Je dois scinder une table contenant plus de 300 champs
en plusieurs tables - relation un à un à chaque fois - les donnees
concernent la meme entite (type questionnaire)
Je ne sais pas comment m'organiser !!!
Pour l'instant j'ai cree un table principale avec une relation (un à un)
avec une table nommée "index". Cette table reference toutes les autres
tables (environs une dizaine). Pour les autres tables, il y a une
relation un à un entre leur clé primaire et la cle etrangere contenu
dans la table "index".
Je ne sais pas si cela est autoriser et correct
Et surtout s'il n'y a pas une solution plus simple ou une procedure deja
validee.
J'ai regardé à peu pres partout sur les forums, le net, la litterature
et il n'y a pas grand chose sur l'organisations des tables lorsque l'on
a une base de donnees de type questionnaire ( c'est à dire beaucoup de
données avec presque pas de relations 1 à n ou n à n).
Dans le cas d'un questionnaire toutes les données concernant un personne
pourrait etre contenu dans une seule table. Mais cela devient vite
problematique si on veut un minimum de controles et de souplesse lors de
la saisie.Et surtout si l'on a + de 200 questions par exemple.
Merci de votre aide si vous avez des reponses ou si vous pouvez
m'orienter...
A bientot
Trevda
Bonjour,
Je dois scinder une table contenant plus de 300 champs
en plusieurs tables - relation un à un à chaque fois - les donnees
concernent la meme entite (type questionnaire)
Je ne sais pas comment m'organiser !!!
Pour l'instant j'ai cree un table principale avec une relation (un à un)
avec une table nommée "index". Cette table reference toutes les autres
tables (environs une dizaine). Pour les autres tables, il y a une
relation un à un entre leur clé primaire et la cle etrangere contenu
dans la table "index".
Je ne sais pas si cela est autoriser et correct
Et surtout s'il n'y a pas une solution plus simple ou une procedure deja
validee.
J'ai regardé à peu pres partout sur les forums, le net, la litterature
et il n'y a pas grand chose sur l'organisations des tables lorsque l'on
a une base de donnees de type questionnaire ( c'est à dire beaucoup de
données avec presque pas de relations 1 à n ou n à n).
Dans le cas d'un questionnaire toutes les données concernant un personne
pourrait etre contenu dans une seule table. Mais cela devient vite
problematique si on veut un minimum de controles et de souplesse lors de
la saisie.Et surtout si l'on a + de 200 questions par exemple.
Merci de votre aide si vous avez des reponses ou si vous pouvez
m'orienter...
A bientot
Trevda
Bonjour,
Je dois scinder une table contenant plus de 300 champs
en plusieurs tables - relation un à un à chaque fois - les donnees
concernent la meme entite (type questionnaire)
Je ne sais pas comment m'organiser !!!
Pour l'instant j'ai cree un table principale avec une relation (un à un)
avec une table nommée "index". Cette table reference toutes les autres
tables (environs une dizaine). Pour les autres tables, il y a une
relation un à un entre leur clé primaire et la cle etrangere contenu
dans la table "index".
Je ne sais pas si cela est autoriser et correct
Et surtout s'il n'y a pas une solution plus simple ou une procedure deja
validee.
J'ai regardé à peu pres partout sur les forums, le net, la litterature
et il n'y a pas grand chose sur l'organisations des tables lorsque l'on
a une base de donnees de type questionnaire ( c'est à dire beaucoup de
données avec presque pas de relations 1 à n ou n à n).
Dans le cas d'un questionnaire toutes les données concernant un personne
pourrait etre contenu dans une seule table. Mais cela devient vite
problematique si on veut un minimum de controles et de souplesse lors de
la saisie.Et surtout si l'on a + de 200 questions par exemple.
Merci de votre aide si vous avez des reponses ou si vous pouvez
m'orienter...
A bientot
Trevda
Bonjour Trevda!
300 champs pour plus de 200 questions... Il me semble que vous essayez
de mettre un champ par question, ce qui va vous poser des problemes
encore plus embetant que ceux que vous avez dans le futur. Si une
question est ajoutee au questionnaire, allez-vous modifier la
structure de votre base?
Il est evident que les questions sont des objets, et que toutes les
questions devraient etre stockees comme enregistrements de la table
tblQuestions, et non pas comme champs d'une quelconque autre table.
A mon avis, la table tblQuestions devrait avoir quelques champs, du
genre questID, questTexte, questNumero, questResume...
Une table Questionnaires peut permettre d'organiser les questions dans
un questionnaire, ce qui permet d'utiliser la meme base pour plusieur
questionnaires.
Il faut aussi une table pour stoquer les reponses aux questions,
tblRep, avec des champs du genre: repID, repQuestID, repPersID,
repReponse.
J'espere que ca vous donne des idees...
Bonjour Trevda!
300 champs pour plus de 200 questions... Il me semble que vous essayez
de mettre un champ par question, ce qui va vous poser des problemes
encore plus embetant que ceux que vous avez dans le futur. Si une
question est ajoutee au questionnaire, allez-vous modifier la
structure de votre base?
Il est evident que les questions sont des objets, et que toutes les
questions devraient etre stockees comme enregistrements de la table
tblQuestions, et non pas comme champs d'une quelconque autre table.
A mon avis, la table tblQuestions devrait avoir quelques champs, du
genre questID, questTexte, questNumero, questResume...
Une table Questionnaires peut permettre d'organiser les questions dans
un questionnaire, ce qui permet d'utiliser la meme base pour plusieur
questionnaires.
Il faut aussi une table pour stoquer les reponses aux questions,
tblRep, avec des champs du genre: repID, repQuestID, repPersID,
repReponse.
J'espere que ca vous donne des idees...
Bonjour Trevda!
300 champs pour plus de 200 questions... Il me semble que vous essayez
de mettre un champ par question, ce qui va vous poser des problemes
encore plus embetant que ceux que vous avez dans le futur. Si une
question est ajoutee au questionnaire, allez-vous modifier la
structure de votre base?
Il est evident que les questions sont des objets, et que toutes les
questions devraient etre stockees comme enregistrements de la table
tblQuestions, et non pas comme champs d'une quelconque autre table.
A mon avis, la table tblQuestions devrait avoir quelques champs, du
genre questID, questTexte, questNumero, questResume...
Une table Questionnaires peut permettre d'organiser les questions dans
un questionnaire, ce qui permet d'utiliser la meme base pour plusieur
questionnaires.
Il faut aussi une table pour stoquer les reponses aux questions,
tblRep, avec des champs du genre: repID, repQuestID, repPersID,
repReponse.
J'espere que ca vous donne des idees...
Bonjour Daniel,
Merci pour votre reponse
J'apporte precision
En fait : pour l'instant
Chaque questionnaire contient par exemple 300 questions (distribuer sur
plusieurs tables)
les questions correspondent à mes colonnes et sont typees en fonction du
format de reponses (champ texte, numerique, liste...)
ex: question : quel age avez-vous ? -> reponse : numerique
date de naissance ? -> reponse : Date
region ou vous habitez ? -> reponse : liste non modifiable
cela permet un meilleur controle du format pour les reponses.
chaque enregistrement pour chaque table est rattache à une personne par
le biais d'un index
ex table questA : Id_questA(cle primaire) quest1 quest2 quest3
table index : Id_Pers Id_questA Id_questB
j'ai essayer votre methode, mais dans ce cas je dois faire plusieurs
table reponse en fonction du format de reponse.
Sinon je dois faire une batterie de test pour verifier le format des
reponses, les convertir pour les mettres dans la "tblRep" et refaire le
chemin inverse pour eviter les conflits de type (cher à access) si je
veux reafficher mes données( dans le cas de modification) dans un format
determiné dans mon formulaire
D'autres part les reponses doivent resté dans un format particulier (
dates, numerique, texte...) pour faciliter l'etude statistiques qui sera
effectuee par la suite.
Le rajout de questions n'est pas autoriser dans mon cas.
Je suis un peu perdu....
C'est vrai que votre solution serait la plus souple en terme d'evolution
mais assez complexe et tres long à mettre en oeuvre.
Je ne vois pas comment gerer les problemes de format... et
Trevda
Bonjour Daniel,
Merci pour votre reponse
J'apporte precision
En fait : pour l'instant
Chaque questionnaire contient par exemple 300 questions (distribuer sur
plusieurs tables)
les questions correspondent à mes colonnes et sont typees en fonction du
format de reponses (champ texte, numerique, liste...)
ex: question : quel age avez-vous ? -> reponse : numerique
date de naissance ? -> reponse : Date
region ou vous habitez ? -> reponse : liste non modifiable
cela permet un meilleur controle du format pour les reponses.
chaque enregistrement pour chaque table est rattache à une personne par
le biais d'un index
ex table questA : Id_questA(cle primaire) quest1 quest2 quest3
table index : Id_Pers Id_questA Id_questB
j'ai essayer votre methode, mais dans ce cas je dois faire plusieurs
table reponse en fonction du format de reponse.
Sinon je dois faire une batterie de test pour verifier le format des
reponses, les convertir pour les mettres dans la "tblRep" et refaire le
chemin inverse pour eviter les conflits de type (cher à access) si je
veux reafficher mes données( dans le cas de modification) dans un format
determiné dans mon formulaire
D'autres part les reponses doivent resté dans un format particulier (
dates, numerique, texte...) pour faciliter l'etude statistiques qui sera
effectuee par la suite.
Le rajout de questions n'est pas autoriser dans mon cas.
Je suis un peu perdu....
C'est vrai que votre solution serait la plus souple en terme d'evolution
mais assez complexe et tres long à mettre en oeuvre.
Je ne vois pas comment gerer les problemes de format... et
Trevda
Bonjour Daniel,
Merci pour votre reponse
J'apporte precision
En fait : pour l'instant
Chaque questionnaire contient par exemple 300 questions (distribuer sur
plusieurs tables)
les questions correspondent à mes colonnes et sont typees en fonction du
format de reponses (champ texte, numerique, liste...)
ex: question : quel age avez-vous ? -> reponse : numerique
date de naissance ? -> reponse : Date
region ou vous habitez ? -> reponse : liste non modifiable
cela permet un meilleur controle du format pour les reponses.
chaque enregistrement pour chaque table est rattache à une personne par
le biais d'un index
ex table questA : Id_questA(cle primaire) quest1 quest2 quest3
table index : Id_Pers Id_questA Id_questB
j'ai essayer votre methode, mais dans ce cas je dois faire plusieurs
table reponse en fonction du format de reponse.
Sinon je dois faire une batterie de test pour verifier le format des
reponses, les convertir pour les mettres dans la "tblRep" et refaire le
chemin inverse pour eviter les conflits de type (cher à access) si je
veux reafficher mes données( dans le cas de modification) dans un format
determiné dans mon formulaire
D'autres part les reponses doivent resté dans un format particulier (
dates, numerique, texte...) pour faciliter l'etude statistiques qui sera
effectuee par la suite.
Le rajout de questions n'est pas autoriser dans mon cas.
Je suis un peu perdu....
C'est vrai que votre solution serait la plus souple en terme d'evolution
mais assez complexe et tres long à mettre en oeuvre.
Je ne vois pas comment gerer les problemes de format... et
Trevda
Re-bonjour Trevda!
Une remarque d'ordre general: On n'a jamais le temps de faire le
boulot comme il faut, mais on est toujours pret a le refaire quand on
s'appercoit que ca ne marche pas...
Si j'insiste sur une modelisation correcte, c'est qu'a chaque fois que
j'ai vu des systemes qui ne s'y soumettaient pas, il y a eu des
problemes.
Il est tout a fait possible d'ajouter des colonnes a la table de
definition des questions qui donnent, par exemple, le type de reponse
attendue, ses extremes (minimum, maximum), regle de validation et
ainsi de suite. Ces information peuvent etre utilisees pour mettre en
page le formulaire de reponses, ce qui evite de faire le travail de
validation pour chaque reponse differente.
Quand a la presentation des resultats, j'expere bien que vous avez
l'intention d'utiliser quelque chose d'autre qu'Access: comment allez
vous rassembler 300 champs dans une requete pour presenter les
resultats?
Combien de personnes vont repondre au questionnaire?
Qui sont les personnes qui vont entrer les reponses dans la base?
Faut-il prevoir une utilisation multi-utilisateur? Une interface par
le web ne serait-elle pas plus conviviale?
Bonne continuation...
Re-bonjour Trevda!
Une remarque d'ordre general: On n'a jamais le temps de faire le
boulot comme il faut, mais on est toujours pret a le refaire quand on
s'appercoit que ca ne marche pas...
Si j'insiste sur une modelisation correcte, c'est qu'a chaque fois que
j'ai vu des systemes qui ne s'y soumettaient pas, il y a eu des
problemes.
Il est tout a fait possible d'ajouter des colonnes a la table de
definition des questions qui donnent, par exemple, le type de reponse
attendue, ses extremes (minimum, maximum), regle de validation et
ainsi de suite. Ces information peuvent etre utilisees pour mettre en
page le formulaire de reponses, ce qui evite de faire le travail de
validation pour chaque reponse differente.
Quand a la presentation des resultats, j'expere bien que vous avez
l'intention d'utiliser quelque chose d'autre qu'Access: comment allez
vous rassembler 300 champs dans une requete pour presenter les
resultats?
Combien de personnes vont repondre au questionnaire?
Qui sont les personnes qui vont entrer les reponses dans la base?
Faut-il prevoir une utilisation multi-utilisateur? Une interface par
le web ne serait-elle pas plus conviviale?
Bonne continuation...
Re-bonjour Trevda!
Une remarque d'ordre general: On n'a jamais le temps de faire le
boulot comme il faut, mais on est toujours pret a le refaire quand on
s'appercoit que ca ne marche pas...
Si j'insiste sur une modelisation correcte, c'est qu'a chaque fois que
j'ai vu des systemes qui ne s'y soumettaient pas, il y a eu des
problemes.
Il est tout a fait possible d'ajouter des colonnes a la table de
definition des questions qui donnent, par exemple, le type de reponse
attendue, ses extremes (minimum, maximum), regle de validation et
ainsi de suite. Ces information peuvent etre utilisees pour mettre en
page le formulaire de reponses, ce qui evite de faire le travail de
validation pour chaque reponse differente.
Quand a la presentation des resultats, j'expere bien que vous avez
l'intention d'utiliser quelque chose d'autre qu'Access: comment allez
vous rassembler 300 champs dans une requete pour presenter les
resultats?
Combien de personnes vont repondre au questionnaire?
Qui sont les personnes qui vont entrer les reponses dans la base?
Faut-il prevoir une utilisation multi-utilisateur? Une interface par
le web ne serait-elle pas plus conviviale?
Bonne continuation...
