Discussion :

[fabszn]

Hello,

Je ne suis pas sur de moi à 100%, j'aimerai avoir l'avis d'expert en la matière.

Voila le contexte (très simple).

Ce modèle concerne un jeux qui contient une serie de questions.
Chaque question contient 1,n réponse (dont une bonne). chaque réponse est rattachée à 1,1 question.
J'ai une entité utilisateur. Chaque utilisateur peut répondre une seule fois à chaque question.

Mon problème se situe au niveau des tables question et reponse.
Dans ma table question, j'ai une clef étrangère ( clef primaire de la table réponse). Cette foreign Key represente la bonne réponse.

Et dans ma table reponse, j'ai une clef etrangere (clef etrangere de la table
question). Cette foreign key represente la question à laquelle est rattachée la reponse.

Est ce que selon vous cela releve d"une bonne conception?

La contraite est que je dois enlever les contraintes d"intégrité pour alimenter mes deux tables.

Je pourrais passer par une table intermédiaire qui associrai la clef de la question et la clef de la reponse. par contre je n'aurais pas la notion de bonne réponse.


Je vous remercie par avance pour votre aide!

[fsmrel]

Vous avez donc deux entités types : Question et Réponse. Les règles sont les suivantes :

(R1) A une question correspond 1 à N réponses.
(R2) Une réponse peut être bonne ou mauvaise.
(R3) Plusieurs réponses peuvent être mauvaises.
(R4) Une seule réponse peut être bonne.

Pour garantir la règle R4, vous avez pensé établir un lien inverse entre les deux entités, de telle sorte qu’une question détermine la bonne réponse, c'est-à-dire que ce lien inverse matérialise une bijection.

Le serpent se mord la queue. Comme vous le soulignez, il y a un problème avec l’intégrité référentielle : pour créer une réponse, il faut d’abord créer une question, mais du fait du cycle il faut au préalable créer la bonne réponse. C’est l’œuf et la poule, on ne s’en sort pas, sauf à débrancher l’intégrité référentielle le temps que l’on effectue les opérations.

Au niveau de la Théorie relationnelle, la solution existe, grâce à la règle suivante : un ensemble d’instructions (en l’occurrence un INSERT dans la table Question suivi d’un INSERT dans la table Réponse) peuvent constituer un paquet tel que les contrôles ne soient déclenchés qu’une fois exécutée la dernière instruction du paquet.
Mais, vous utilisez un SGBD relationnel qui selon toute vraisemblance ne propose pas ce raffinement, donc il faut chercher une variante de modèle.

Je pourrais passer par une table intermédiaire qui associerait la clef de la question et la clef de la réponse. Par contre je n'aurais pas la notion de bonne réponse.

Vous pouvez utiliser cette table intermédiaire. Appelons-la BONNE_REPONSE. Vous pouvez alors produire un jeu de Create Table ressemblant à ceci :

create table QUESTION (
QUESTION_ID INTEGER not null,
QUESTION_TRUC INTEGER not null,
constraint PK1 primary key (QUESTION_ID)
);
create table REPONSE (
REPONSE_ID INTEGER not null,
QUESTION_ID INTEGER not null,
REPONSE_MACHIN INTEGER not null,
constraint PK2 primary key (REPONSE_ID)
);
create table BONNE_REPONSE (
QUESTION_ID INTEGER not null,
REPONSE_ID INTEGER not null,
constraint PK3 primary key (QUESTION_ID)
constraint UK1 Unique (REPONSE_ID)
);

alter table REPONSE
add constraint FK2 foreign key (QUESTION_ID)
references QUESTION (QUESTION_ID)
on delete cascade;

alter table BONNE_REPONSE
add constraint FK3 foreign key (QUESTION_ID)
references QUESTION (QUESTION_ID)
on delete cascade;

alter table BONNE_REPONSE
add constraint FK1 foreign key (REPONSE_ID)
references REPONSE (REPONSE_ID)
on delete cascade;

Vous observerez que pour savoir quelle est la bonne réponse à une question donnée, il suffit d’interroger le contenu de la table BONNE_REPONSE. En outre vous garantissez la règle R4 (Une seule réponse peut être bonne) grâce à la contrainte portée par cette table : constraint UK1 Unique (REPONSE_ID).

Maintenant, au nom du rasoir d'Ockham, on peut se poser la question de l’intérêt d’avoir une relation entre REPONSE et BONNE_REPONSE : Renommons REPONSE en MAUVAISE_REPONSE, supprimons la relation et bien sûr n’insérons dans MAUVAISE_REPONSE que les mauvaises réponses (tout en intégrant dans BONNE_REPONSE les colonnes figurant dans feue REPONSE et nécessaires, telles que REPONSE_MACHIN)...

CREATE TABLE QUESTION (
QUESTION_ID INTEGER NOT NULL,
QUESTION_TRUC INTEGER NOT NULL,
CONSTRAINT PK1 PRIMARY KEY (QUESTION_ID)
);
CREATE TABLE MAUVAISE REPONSE (
REPONSE_ID INTEGER NOT NULL,
QUESTION_ID INTEGER NOT NULL,
REPONSE_MACHIN INTEGER NOT NULL,
CONSTRAINT PK2 PRIMARY KEY (REPONSE_ID)
);
CREATE TABLE BONNE_REPONSE (
QUESTION_ID INTEGER NOT NULL,
REPONSE_MACHIN INTEGER NOT NULL,
CONSTRAINT PK3 PRIMARY KEY (QUESTION_ID)
);

ALTER TABLE MAUVAISE_REPONSE
ADD CONSTRAINT FK2 FOREIGN KEY (QUESTION_ID)
REFERENCES QUESTION (QUESTION_ID)
ON DELETE CASCADE;

ALTER TABLE BONNE_REPONSE
ADD CONSTRAINT FK3 FOREIGN KEY (QUESTION_ID)
REFERENCES QUESTION (QUESTION_ID)
ON DELETE CASCADE;

En tout état de cause, cette 2e solution me paraît plus saine. Il en existe d'autres, mais en première approche, ça pourrait déjà être pas mal.

Si l’on souhaite disposer d’une table REPONSE unique, contenant toutes les réponses, il suffit de créer à cet effet une vue d’union des deux tables BONNE_REPONSE et MAUVAISE REPONSE.

A vous de jouer.

Fsmrel

[fabszn]

Hello,

Merci beaucoup pour cette réponse aussi complète!!

Je travaille sous DB2 UDB. je ne suis pas expert en base de données.

La solution concernant la creation d'un paquet permettant l'ajout des nuplets dans les deux tables et le déclenchement des controles ensuites pourraient être une solution, mais dans mon cas c'est une application que je dois mettre en place sur un intranet.

Etant donné le nombre restraint de table et de contrainte sur le modèle je pourrais avoir deux scripts 1 de suppression des contraintes et un de créations. (ca pourrait être une solution aussi).
Mais quoi qu'il arrive la situation actuelle de mon modèle de données (ie mes clefs 'réciproques') relève d'une erreur de conception? vous êtes d'accord?

J'avoue que la création de deux tables supplémentaires m'ennuie un peu.Cela me donne l'impression d'avoir une information redondante (entre les deux tables BONNE et MAUVAISE REPONSE).

Je pourrais conserver ma table réponse (qui me permettrait d'avoir des informations sur les réponses) et créer une table QUESTION_REPONSE :

Code :

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

1
2
3
4
5
6
create table QUESTION_REPONSE (
QUESTION_ID INTEGER not null,
REPONSE_ID INTEGER not null,
ISBONNEREPONSE BOOLEAN not null,
constraint PK1 primary key (QUESTION_ID,REPONSE_ID)
);

Cette table me permettrait de faire l'association entre les questions et les reponses et, par l'intermediaire, du champ ISBONNEREPONSE de pouvoir déterminer si la reponse sélectionnée est la bonne ou non.
Les cardinalitées seraient :

Code :

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

1
2
T_QUESTION ----->0,n T_QUESTION_REPONSE
T_REPONSE   ----->0,1 T_QUESTION_REPONSE

Si je ne me trompe pas, cela s'appelle une table de lien ?.

Dans ce cas de figure, je supprimerai les identifiants ID_QUESTION de la table réponse et ID_REPONSE de la table question.

Qu'en pensez vous?

Merci encore (et d'avance) pour votre aide

[Le Pharaon]

Bonjour
Je n'ai lu que le premier post et je propose le MCD ci-joint.

[fsmrel]

J'avoue que la création de deux tables supplémentaires m'ennuie un peu.Cela me donne l'impression d'avoir une information redondante (entre les deux tables BONNE et MAUVAISE REPONSE).

Je n'ai pas proposé pas d'ajouter deux tables, mais une seule (BONNEREPONSE) et de renommer REPONSE en MAUVAISEREPONSE. Vous aurez noté que la table BONNEREPONSE a pour identifiant celui de QUESTION et que n'y figure pas celui de REPONSE (voir aussi le JPG attaché s'il n'a pas disparu en cours de route).

Maintenant, vous avez aussi la possibilité de rapatrier BONNEREPONSE dans QUESTION et en conséquence de ne conserver que deux tables : QUESTION et MAUVAISEREPONSE (voir le JPG attaché).

[fsmrel]

Je recommence, car la pièce jointe s'est perdue...

J'avoue que la création de deux tables supplémentaires m'ennuie un peu.Cela me donne l'impression d'avoir une information redondante (entre les deux tables BONNE et MAUVAISE REPONSE).

Je n'ai pas proposé pas d'ajouter deux tables, mais une seule (BONNEREPONSE) et de renommer REPONSE en MAUVAISEREPONSE. Vous aurez noté que la table BONNEREPONSE a pour identifiant celui de QUESTION et que n'y figure pas celui de REPONSE (voir aussi le JPG attaché s'il n'a pas disparu en cours de route).

Maintenant, vous avez aussi la possibilité de rapatrier BONNEREPONSE dans QUESTION et en conséquence de ne conserver que deux tables : QUESTION et MAUVAISEREPONSE (voir le JPG attaché).