Discussion :

[SynApps]

Bonjour à tous,

J'ai créé une base de données qui devra inclure des types de questionnaire, qui eux, possèdent plusieurs questions. Ces questions possèdent elles des sous-questions qui possèdent des choix de réponses. Par ailleurs, On doit pouvoir sortir le nom et le prénom de l'élève qui à rempli ce questionnaire. La date de naissance de l'élève, ainsi que son sexe, sont là uniquement pour éviter des conflits du genre, deux élèves qui ont le même prénom ou bien, un élève et une élève qui portent le même prénom et nom de famille (Camille peut être masculin comme féminin).

J'ai créé mon MCD avec leurs relations. Je pense qu'il est correct, mais je souhaiterais avoir un avis extérieur concernant une partie du MCD, à savoir entre les entité Question, ChoixReponse et SousQuestion. Ci-dessous une image de mon MCD.


la relation entre Question et SousQuestion se nomme "Contenir". On admet qu'une question contient plusieurs sous-questions et une sous-question peut-être contenue dans plusieurs questions.

Ensuite, l'autre relation lie entre elles l'entité "Question", "SousQuestion" et "ChoixReponse". Je l'ai nommée "Reponse" avec comme attribut "Repondu". Pour chaque question dont le choix de réponse est défini, on a la réponse souhaitée. Et il en sera de même pour une sous-question.

Toutes les cardinalités maximales sont à "n". Ce qui implique deux table à créer en passant au modèle logique de données (MLD).

La relation "Contenir" devrait donc se transformer en table que je nommerais "QuestionsSousQuestion" et on y ajouterait les clés primaires de chaque table d'origine. pour la relation "Reponse", elle se transforme ainsi en table qui comportera les trois clé primaires des table citées plus haut, ainsi que l'attribut "Repondu".

J'ai supprimé dans mon MLD la relation "Contenir", qui semble superflue à cause de la table "Reponse" qui contient déjà les clés de "Question" et "SousQuestion". voici l'image de mon MLD:


Comme dit au début de mon post, je pense avoir respecté les étapes de conception et de normalisation. Cependant, je souhaite un avis extérieur sur mon travail. Peut-être qu'il y a des erreurs et dans ce cas, je retravaillerai mon MCD.


Merci d'avance à tous


P.S. J'ai utilisé Visio 2007 pour créer mon MCD et MLD

[fsmrel]

Bonsoir SynApps,

J'ai supprimé dans mon MLD la relation "Contenir", qui semble superflue à cause de la table "Reponse" qui contient déjà les clés de "Question" et "SousQuestion".

Pas de problème pour qu'une table phagocyte l'autre, à condition que vous considériez qu’au sens de la théorie relationnelle on vérifie que chaque tuple {ID_Question, ID_SousQuestion} de la table CONTENIR soit égal à la projection d'un tuple de la table REPONSE sur les attributs ID_Question et ID_SousQuestion :

CONTENIR = REPONSE {ID_Question, ID_SousQuestion}

Où REPONSE {ID_Question, ID_SousQuestion} représente la projection de REPONSE sur les attributs ID_Question et ID_SousQuestion.

Pour chaque question dont le choix de réponse est défini, on a la réponse souhaitée. Et il en sera de même pour une sous-question.

Selon votre MLD, pour chaque paire {question, sous-question}, on a un ensemble de réponses. Pour chaque question, l’ensemble des réponses est l’union (au sens de la théorie des ensembles) des réponses aux sous-questions associées à la question.

Est-ce bien ainsi que vous voyez les choses ? Sinon il y a un malaise avec vos modèles.

Une sous-question peut-être contenue dans plusieurs questions.

L’expression « peut être » n’est pas en phase avec votre MCD, car selon celui-ci, une sous-question est contenue dans au moins une question.


Le triplet {ID_Question, ID_SousQuestion, ID_ChoixReponse} est clé candidate pour la table REPONSE, vous pourriez faire l’économie de l’attribut ID_Reponse.

La date de naissance de l'élève, ainsi que son sexe, sont là uniquement pour éviter des conflits du genre.

Pourquoi pas. Cela dit, comme vous parlez de tables et de clés primaires, c’est que la base de données sera SQL : si le SGBD que vous utilisez est normalement constitué (par exemple, si ça n'est pas MySQL), vous pourrez faire l’économie de la table SEXE, en dotant la table ELEVE d’une contrainte de table :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CREATE TABLE ELEVE
(
     ...
     CONSTRAINT ELEVE_SEXE_CHCK CHECK (Sexe IN (1, 2))
     ...
) ;

Concernant la légende que vous avez fournie pour le MCD, vous utilisez le terme « clé primaire », or ce concept ressortit à SQL, il est à remplacer par celui d’« identifiant ».

Concernant la légende associée au MLD, vous utilisez le terme « clé secondaire » qui est connoté fichier ou SGBD pré-relationnel, il est à remplacer par celui de « clé alternative » (faisant l'objet d'une contrainte UNIQUE au stade SQL).

Même connotation en ce qui concerne le terme « champ » qui est à remplacer par celui d'« attribut » (ou de « colonne quand vous vous placez dans un contexte SQL).

[SynApps]

Merci beaucoup pour votre réponse, il me manquait en effet quelques points à éclairssir...

Cela dit, cette base de données je dois la dévellopper dans ACCESS pour les besoin d'un projet d'école. En ce qui concerne ce questionnaire à remplir par les élèves, il est composé de 4 pages (seulement les 2 premières sont nécéssaires pour la réalisation du projet).

Selon votre MLD, pour chaque paire {question, sous-question}, on a un ensemble de réponses. Pour chaque question, l’ensemble des réponses est l’union (au sens de la théorie des ensembles) des réponses aux sous-questions associées à la question.

Est-ce bien ainsi que vous voyez les choses ? Sinon il y a un malaise avec vos modèles.

Oui, c'est vrai pour le premier questionnaire. On ne peut choisir qu'une réponse par paire de Question-SousQuestion. Je vais essayer de détailler un peu plus:

La première page est composée de questions, de sous questions et de choix de réponses. Ce qui implique que les données font directement référence aux 3 table que j'ai créées pour. Voici comment se présente le premier questionnaire:


Ensuite pour le 2ème questionnaire, les données dépendent uniquement de la table Question et de la table ChoixReponse. On notera qu'en dehors des choix de réponses possible, il y a aussi des questions où il est demandé d'y insérer du texte. Ce qui pour moi, est aussi un choix de réponse et donc va s'inscrire dans la table. Voici une image du deuxième questionnaire:


Donc, est-ce que j'ai eu raison de supprimer la relation CONTENIR de mon MCD au moment de passer au MLD ? vu que les clés primaires des table Question et SousQuestion seront inscrites dans la table Reponse qui possèdera aussi la clé de la table ChoixReponse...

L’expression « peut être » n’est pas en phase avec votre MCD, car selon celui-ci, une sous-question est contenue dans au moins une question.


Le triplet {ID_Question, ID_SousQuestion, ID_ChoixReponse} est clé candidate pour la table REPONSE, vous pourriez faire l’économie de l’attribut ID_Reponse.

C'est ce que je pensais aussi. Je me disais au départ, que le champ "Repondu" dépendait des 3 clés en ce qui concerne le 1er questionnaire et de 2 clés (Question et ChoixReponse) pour le 2ème questionnaire. C'est pour ça, que l'ajout de ID_Reponse m'avait paru utile. Mon raisonnement est-il correct ?

[fsmrel]

Bonsoir SynApps,


Je suppose que ce que vous modélisez a pour objet de définir un catalogue des types de réponse : néant, débutant, avancé, expert, oui, non, < 10, intuitivement, etc., c'est-à-dire que dans ce contexte, les réponses effectives des élèves ne sont pas à prendre en compte. C’est bien cela ?

Quoi qu’il en soit, je constate que ce que vous nommez « Premier questionnaire » se décline en thèmes indépendants :

Systèmes d’exploitation, langages de programmation, utilisation de logiciels, paradigmes (procédural/OO), réseaux, SGBD, périphériques de stockage.

Mais pourquoi catégorisez-vous ces thèmes en questions et sous-questions pour ensuite en faire un tricot de réponses, c'est-à-dire établir une relation de dépendance entre ces catégories, alors que visiblement il n’y a que des thèmes indépendants ? Vous donnez l’exemple des systèmes d’exploitation et des langages : d’expérience, je dirai que le niveau des langages (du moins ceux que vous proposez) n’est pas lié à un système d’exploitation. En tant qu’élève répondant au questionnaire, voici quelles pourraient être les réponses de l’élève Volfoni :




Où voit-on dans cette image des relations entre langages et systèmes ?

Quelques remarques en relation avec ce questionnaire :

La compétence en COBOL de l’élève Volfoni ne peut évidemment pas varier d’un système à l’autre, ça n’aurait pas de sens. Pourtant, si j’interprète correctement votre modèle, un système d’exploitation ferait l’objet d’une question tandis qu’un langage ferait l’objet d’une sous-question, et la réponse de Volfoni dépendrait à la fois du système et du langage.

De toute façon, vu le document soumis à l'élève Volfoni, quand vous en arriverez au stade de la prise en compte de ses réponses, vous ne pourrez pas inférer qu'il aura utilisé COBOL en relation avec tel ou tel système.

Si l’on se base sur le document que vous présentez, on pencherait donc pour un MCD où il n’y aurait que des questions et des réponses, mais pas de sous-questions, tandis votre propre MCD n’est manifestement pas en phase.

Par ailleurs, il faudra changer de MCD quand il s’agira de prendre en compte les réponses des élèves pour en tirer des données, qu’elles soient personnalisées ou agrégées pour l'ensemble des élèves (en notant au passage que, tant qu’on en est au stade des réponses-types, donc sans prise en compte des réponses des élèves, la partie « modules I-CH » est hors sujet).

Je me disais au départ, que le champ "Repondu" dépendait des 3 clés en ce qui concerne le 1er questionnaire et de 2 clés (Question et ChoixReponse) pour le 2ème questionnaire. C'est pour ça, que l'ajout de ID_Reponse m'avait paru utile. Mon raisonnement est-il correct ?

Indépendamment des observations que j'ai faites ci-dessus, quand l’attribut Repondu dépend de chacune des 3 entités-types QUESTION, SOUS-QUESTION, CHOIX_REPONSE, il est porté par l’association établie entre ces trois entités-types. Quand il ne dépend que des deux entités-types QUESTION, CHOIX_REPONSE, il doit être porté par une autre association, elle-même établie entre ces deux entités-types : en Merise une patte d'association n'est jamais optionnelle, c’est ainsi qu’on modélise selon les règles de l’art.