Bonjour la communauté,

Je n'ai pas l'habitude de demander de l'aide, a part pour les quelques cours que je suis.

Hélas aujourd'hui je bloque pour un problème de logique.

J'ai donc un petit site en local sur lequel des étudiants se connecteront et répondront à un qcm. qui voudront 1-0 ou -1 (bonne réponse, "ne sais pas", se trompe).

Des professeurs verront eux quels étudiants à répondu en dernier au qcm ainsi que son résultat final.

 Le qcm doit être  pensé de manière à pouvoir rajouter des questions facilement.

Je pensais créer dans un premier temps une table questions et une table réponses. Mais comme chaque réponses possibles sera différente par questions(assez typés) je ne vois pas de raison de les séparer, elles ne seront pas réutilisées. Donc plus simple pour rajouter des questions non?

J'avais comme idée de table:

Qu'en pensez-vous? 

J'ai toujours du mal a faire une organisation correcte.. 

Si vous avez des idées d'améliorations je suis tout ouïe..

ps: seconde solution:

-
Edité par Jodé 8 août 2017 à 20:24:31

La solution 2 est mieux (si j'ai bien compris) dans la mesure où elle sépare les réponses des étudiants de la bonne réponse.

Par contre, essaie de changer le nom des tables "reponse" et "reponses" car cela peut provoquer un manque de compréhension.

Très bien, changer les noms, effectivement!

Mais sinon elle est logique, rien a améliorer ?

Bonjour,

Il nous manque plusieurs informations pour répondre, vu que tu es directement passé par un modèle logique (MLD) il est difficile de t'aider en fait ...

Lorsque l'on conçoit une base de données, il est très utile de faire un modèle conceptuel (MCD) avec entités et relations.

Si l'on reprend l'analyse entité/relation, tu as des questions et des réponses possibles. Tu as aussi des utilisateurs et des questionnaires.

Cela fait 4 entités donc 4 tables. Je crée l'entité questionnaire pour regrouper les réponses d'un utilisateur, et éventuellement imaginer qu'un même utilisateur puisse répondre à plusieurs questionnaires ...

Côté attributs "remarquables" dans ces entités, chaque réponse possible a un score (1 = juste ou -1 = faux).

Côté relations, il faudrait confirmer les cardinalités :

• Une question a plusieurs réponses possibles, et une réponse correspond à une (ou plusieurs ?) question.
• Un utilisateur peut répondre à un (ou plusieurs ?) questionnaire, et un questionnaire correspond à un utilisateur.
• Un questionnaire contient plusieurs questions, et une question est dans plusieurs questionnaire. Relation n,n = table de relation.

Avec ces cardinalités (à valider), ton modèle logique serait donc en 5 tables :

• utilisateur ( id [pk], pseudo, mdp, fonction )
• question ( id [pk], libelle )
• reponse_possible ( id [pk], id_question [pk], libelle, score )
• questionnaire ( id [pk], id_utilisateur [fk], date_creation, etc. )
• questionnaire_question ( id_questionnaire [pk][fk], id_question [pk][fk], id_reponse [fk], date_reponse, etc. )

Je ne mettrais pas de table pour stocker les scores finaux, le calcul est assez simple, c'est la somme des scores des questions. Si un utilisateur ne répond pas à une question, tu laisses NULL dans id_reponse, ce qui entraînera un score nul ...

Benzouye a écrit:

Bonjour,

faire un modèle conceptuel (MCD) avec entités et relations.

Si l'on reprend l'analyse entité/relation, tu as des questions et des réponses possibles. Tu as aussi des utilisateurs et des questionnaires.

Côté attributs "remarquables" dans ces entités, chaque réponse possible a un score (1 = juste ou -1 = faux).

• Une question a plusieurs réponses possibles, et une réponse correspond à une (ou plusieurs ?) question.
• Un utilisateur peut répondre à un (ou plusieurs ?) questionnaire, et un questionnaire correspond à un utilisateur.
• Un questionnaire contient plusieurs questions, et une question est dans plusieurs questionnaire. Relation n,n = table de relation.

Avec ces cardinalités (à valider), ton modèle logique serait donc en 5 tables :

• utilisateur ( id [pk], pseudo, mdp, fonction )
• question ( id [pk], libelle )
• reponse_possible ( id [pk], id_question [pk], libelle, score )
• questionnaire ( id [pk], id_utilisateur [fk], date_creation, etc. )
• questionnaire_question ( id_questionnaire [pk][fk], id_question [pk][fk], id_reponse [fk], date_reponse, etc. )

Je ne mettrais pas de table pour stocker les scores finaux, le calcul est assez simple, c'est la somme des scores des questions. Si un utilisateur ne répond pas à une question, tu laisses NULL dans id_reponse, ce qui entraînera un score nul ...

Bonjour, 

Merci de cette réponse complète.

Effectivement je n'aurais pas du zapper le modèle conceptuel, je vais me "forcer" de le faire à chaque fois pour me simplifier la vision.

Alors voyons un peu tout ça, le code ça va (enfin le php et moi on commence seuelement, mais le mysql ça va), mais la réflexion de l'architecture n'est pas mon fort..

 - Une question à plusieurs réponses possible (qcm) mais une réponse a une seule question (voire deux, c'est un questionnaire avec des questions      du style: "Sous Debian, la commande permettant tel action est : " un peu dans le genre des lpi si certains connaissent).

- Les utilisateurs (élèves) réponde à un questionnaire (On peut être amené à en rajouter, mais la on en a q'un) et le questionnaire est accessible a       tous les élèves. Un seul questionnaire et le code php prends au hasard les questions.

 - Un questionnaire contient bien plusieurs questions, et comme il faut que la base de donnée doit être évolutive, effectivement on peut penser à         question dans plusieurs questionnaire, par exemple dans le php je pourrais avoir un questionnaire plus orienté réseau que code ou os..

Les consignes reçues sont succinctes et j'essaye de prévoir au mieux possible.

par exemple ma table

Je vois qu'il suffit de ne pas stocker la bonne réponse, mais uniquement de lui donner un score, c'est plus ingénieux je n'y pensais pas.

• utilisateur ( id [pk], pseudo, mdp, fonction )
• question ( id [pk], libelle )
• reponse_possible ( id [pk], id_question [pk], libelle, score )
• questionnaire ( id [pk], id_utilisateur [fk], date_creation, etc. )
• questionnaire_question ( id_questionnaire [pk][fk], id_question [pk][fk], id_reponse [fk], date_reponse, etc. )

Par exemple la table questionnaire contient une fk vers id_utilisateur, pourquoi? est-ce cette table qui contiendra les questions que l'utilisateur aura choisi?

questionnaire_question sera la table qui contiendra donc les questions si je comprends bien?

Si par exemple chaque questionnaire dispose de ses propres questions, le schéma changerait-il?

Encore une fois, je suis désole si mes questions sembles idiotes, mais la logique d'architecture ne m'est pas encore acquise.

Jodé a écrit:

la table questionnaire contient une fk vers id_utilisateur, pourquoi? est-ce cette table qui contiendra les questions que l'utilisateur aura choisi?

Benzouye a écrit:

Je crée l'entité questionnaire pour regrouper les réponses d'un utilisateur, et éventuellement imaginer qu'un même utilisateur puisse répondre à plusieurs questionnaires ...

Chaque fois qu'un utilisateur va faire un QCM tu vas créer un enregistrement dans la table questionnaire, c'est le "dossier" qui dit "Tel date, tel utilisateur a fait un QCM". Ensuite ton programme (ici PHP, mais ce pourrait être directement MySQL à l'aide d'un TRIGGER) va "sélectionner" les questions à poser à l'utilisateur, et pour chaque question tu vas donc créer un enregistrement dans la table questionnaire_question, qui dit "tel questionnaire contient telles questions".

D'accord je vois son utilité, et du coup je pourrais rajouter dans ce "dossier" les questions que l'étudiant a reçu ainsi que son correctif ?

Car je viens de recevoir des consignes plus précise:

"

oLorsqu'un élève se connecte il aura accès au QCM.

oIl devra choisir parmi les différentes propositions, plus un « je ne sais pas ».

oUn bouton « terminé » permettra d'enregistrer les réponses de l'étudiant dans la DB.

oLorsqu'un élève a terminé l'évaluation et se reconnecte avec son login, son correctif lui sera affiché.

oLorsqu'un professeur se connecte, il aura accès à une page lui indiquant

Les élèves ayant clôturé l’examen (avec leurs résultats)

Les étudiants n'ayant pas encore commencé

Les étudiants en train de passer l'évaluation.

Si un étudiant ayant terminé l'évaluation est sélectionné, les détails de son évaluation seront affichés.

oLes résultats seront calculés en +1 / 0 / -,5 en fonction des réponses.

oL’étudiant peut choisir parmi plusieurs questionnaires (pour des matières différentes p.ex.)

oA chaque session, le questionnaire du QCM concerné est généré de manière aléatoire :

Sélection de 50 % des questions parmi le pool de questions du QCM.

Ordre des questions aléatoire.

Ordre des propositions de réponses aux questions aléatoire (avec le « je ne sais pas » en dernière proposition à chaque fois).

"

Jodé a écrit:

C'est toujours ainsi, on réfléchit à un truc, et tout se modifie

Aucun changement par rapport à ce que je t'ai proposé, sauf peut-être ajouter une colonne "état" au questionnaire permettant de déterminer si un questionnaire est terminé ou non (0 = en cours et 1 = terminé par exemple) ... Par contre on voit bien ici qu'un étudiant ne fera le QCM qu'une seule fois ...

De ton côté, il faut bien que tu distingues les fonctionnalités portées par la BDD et les règles de gestion portées par le programme (ici PHP).

Jodé a écrit:

cette consigne "Si un étudiant ayant terminé l'évaluation est sélectionné, les détails de son évaluation seront affichés." & "Lorsqu'un élève a terminé l'évaluation et se reconnecte avec son login, son correctif lui sera affiché." m'oblige bien a stocker les choix des étudiants, après il me suffit de recalculé avec le php

Oui, et c'est bien le cas avec le modèle proposé. Je vais expliquer un peu plus en détail ...

Tu crées au préalable :

• deux enregistrements dans la table utilisateur (un étudiant et un prof)
• autant de questions que tu le souhaites dans la table question
• au moins deux ou trois réponses par question dans la table reponse_possible chacune avec son score et au moins un score = 1 par question

Lorsque l'utilisateur "étudiant" se connecte à ton application :

• si aucun questionnaire n'existe déjà pour lui dans la BDD, tu lui affiches un bouton "Démarrer le QCM"
• si un questionnaire existe et n'est pas terminé, tu lui affiches un bouton "Reprendre le questionnaire"
• si un questionnaire existe et est terminé, tu lui affiches ses résultats

Au clic sur le bouton "Démarrer le QCM", ton programme crée un enregistrement dans la table questionnaire avec l'id de l'étudiant (et la date par exemple), puis le programme sélectionnes aléatoirement une moitié des questions possibles et insères dans la table questionnaire_question leur id avec celui du questionnaire créé.

Tu peux alors afficher à l'étudiant la liste des questions associées à son questionnaire, ainsi que la liste des réponses possibles pour chacune avec un système de bouton radio s'appuyant sur l'id des réponses et un bouton radio "Je ne sais pas" en plus.

Sur cet écran tu peux afficher un bouton "Enregistrer mes réponses" et un bouton "Terminer le questionnaire". Sur le premier tu enregistres les réponses dans la table questionnaire_question, sur le deuxième tu enregistres les réponses questionnaire_question et change l'état du questionnaire et afficher les résultats directement.

Si un utilisateur "prof" se connecte, tu peux afficher la liste des questionnaire selon leur état et afficher le détail d'un questionnaire terminé choisi.

Tout ce que j'ai écris en gras dans ce message correspond à une requête SQL

En espérant t'avoir éclairé.

-
Edité par Benzouye 9 août 2017 à 17:57:09

Tu m'as sacrément bien aidé la :o 

Surtout les indications pour les requêtes ssl et donc le php..

Je vais mettre ça sous forme logique et je poste ça, pour d'autres potentiels personnes dans mon cas, ainsi que pour vérifier

Bon j'édite bien tard, car je n'y arrivais pas avec Chrome..

donc:

Me voila de retour pour ceux que ça peut aider voici le schéma logique et l'explication reçue:

On est d'accord sur la forme logique de la DB?

Cependant j'ai encore une question (je m'en excuse), si par exemple je souhaite créer des questionnaires par thèmes, par exemple questionnaire axé réseau, et un second axé système, quelle solution? Si je ne m'abuse il n'y a aucun tri dans la table Question, à moins que je ne crée un table thème par exemple? ou il est trop tard et je devrais dormir car je dis encore des âneries?

D'habitude on me fournit un schéma logique et je ne m'occupe que de la création des db et requêtes, ici je ne suis pas du tout dans mon élément.

-
Edité par Jodé 10 août 2017 à 10:58:27

J'ai edité mon psote pour le plan logique. 

Je suis en train de ne pas m'amuser du tout avec le php

edit: en codant je me rends compte que j'ai encore du mal comprendre, car en ajoutant les id_questions dans Questionnaire_question, j'ai bien plusieurs enregistrements mais comme j'utilise l'id_questionnaire_question en primary key j'ai un id different a chaque question.. Je dois rajouter une table pour ça ou j'ai rien compris.. Car la ça devient problématique

-
Edité par Jodé 11 août 2017 à 0:29:29

Jodé a écrit:

j'utilise l'id_questionnaire_question en primary key j'ai un id different a chaque question.. Je dois rajouter une table pour ça ou j'ai rien compris.. Car la ça devient problématique

Tu remarqueras que dans ma proposition, la clé primaire de la table questionnaire_question est composée sur deux colonnes, il n'y a pas d'id auto incrémenté. C'est le couple question/questionnaire qui compose la clé primaire (pas deux fois la même question pour le même questionnaire).

Je te conseille un peu de lecture sur la conception des bdd (cf. lien dans ma signature)

Jodé a écrit:

si par exemple je souhaite créer des questionnaires par thèmes, par exemple questionnaire axé réseau, et un second axé système, quelle solution? Si je ne m'abuse il n'y a aucun tri dans la table Question, à moins que je ne crée un table thème par exemple? ou il est trop tard et je devrais dormir car je dis encore des âneries?

D'habitude on me fournit un schéma logique et je ne m'occupe que de la création des db et requêtes

Je te propose d'utiliser jMerise pour formaliser ton MCD et générer ton MLD.

Pour ta question, tu peux créer une entité thème. Et comme relation :

Un thème est lié à plusieurs questions, et une question est liée à un (ou plusieurs ? à valider) thème.

Un questionnaire est lié à un thème, et un thème est lié à plusieurs questionnaires.

Ton MCD serait :

Après, côté PHP il va falloir proposer les thèmes à l'étudiant, et potentiellement autoriser l'ouverture de plusieurs questionnaires en même temps ...

-
Edité par Benzouye 11 août 2017 à 9:22:14

Je viens d'imprimer ce "cours" qui me semble très utile pour la conception, et le garder de cote comme un pense-bête pour ce genre d'occasion..

Je ne n'avais plus en tête que les clés primaires pouvaient être une composition. Il faut dire que je suis dans une approche très autodidacte et que je n'avais pas ou peu rencontré ce genre de chose..

Pourrais-tu malgré tout me donner les variables contenues dans Questionnaire_question stp? (je veux vraiment ne plus me méprendre..) Du coup la création de la clé primaire ressemblerait a quoi? Comme un index ou constraint ou je précise primary key pour en faire une liaison?

Jodé a écrit:

Pourrais-tu malgré tout me donner les variables contenues dans Questionnaire_question stp?

En utilisant jMerise, tu crées ton MCD, et jMerise génère automatiquement le MLD associé ainsi que le SQL :

CREATE TABLE utilisateur(
        id_utilisateur int (11) Auto_increment  NOT NULL ,
        pseudo         Varchar (25) NOT NULL ,
        password       Varchar (25) ,
        fonction       Bool NOT NULL ,
        PRIMARY KEY (id_utilisateur )
)ENGINE=InnoDB;

CREATE TABLE theme(
        id_theme int (11) Auto_increment  NOT NULL ,
        nom      Varchar (25) NOT NULL ,
        PRIMARY KEY (id_theme )
)ENGINE=InnoDB;

CREATE TABLE question(
        id_question int (11) Auto_increment  NOT NULL ,
        libelle     Text NOT NULL ,
        id_theme    Int NOT NULL ,
        PRIMARY KEY (id_question ),
		CONSTRAINT FK_question_id_theme
			FOREIGN KEY (id_theme)
			REFERENCES theme(id_theme)
)ENGINE=InnoDB;

CREATE TABLE questionnaire(
        id_questionnaire int (11) Auto_increment  NOT NULL ,
        date_creation    Datetime NOT NULL ,
        date_maj         Datetime NOT NULL ,
        etat             Bool NOT NULL ,
        id_utilisateur   Int NOT NULL ,
        id_theme         Int NOT NULL ,
        PRIMARY KEY (id_questionnaire ),
		CONSTRAINT FK_questionnaire_id_utilisateur
			FOREIGN KEY (id_utilisateur)
			REFERENCES utilisateur(id_utilisateur),
		CONSTRAINT FK_questionnaire_id_theme
			FOREIGN KEY (id_theme)
			REFERENCES theme(id_theme)
)ENGINE=InnoDB;

CREATE TABLE reponse(
        id_reponse  int (11) Auto_increment  NOT NULL ,
        libelle     Text NOT NULL ,
        score       Int NOT NULL ,
        id_question Int NOT NULL ,
        PRIMARY KEY (id_reponse ),
		CONSTRAINT FK_reponse_id_question
			FOREIGN KEY (id_question)
			REFERENCES question(id_question)
)ENGINE=InnoDB;

CREATE TABLE questionnaire_question(
        id_question      Int NOT NULL ,
        id_reponse       Int NOT NULL ,
        id_questionnaire Int NOT NULL ,
        PRIMARY KEY (id_question, id_questionnaire ),
		CONSTRAINT FK_questionnaire_question_id_question
			FOREIGN KEY (id_question)
			REFERENCES question(id_question),
		CONSTRAINT FK_questionnaire_question_id_reponse
			FOREIGN KEY (id_reponse)
			REFERENCES reponse(id_reponse),
		CONSTRAINT FK_questionnaire_question_id_questionnaire
			FOREIGN KEY (id_questionnaire)
			REFERENCES questionnaire(id_questionnaire)
)ENGINE=InnoDB;

Woaw c'est puissant comme outil :o 

Décidément beaucoup de chose ne m'ont pas été apprise sur les quelques mois ou l'on me donnait cours sur le sql..

J'ai mis a jour mes tables, sauf pour la partie thème que je ne ferais que si je m'en sors en php ^^..

Je laisse le sujet ouvert, mon projet n'étant pas fini.

Pour l'instant je fais à l'ancienne avec mariadb sur une debian avec apache2