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é).

[TheLeadingEdge]

Bonjour,

Je pense que ta relation circulaire provient de ce que tu occultes 1 partie du contexte dans ton modèle.
Pourquoi ''question'' et ''reponse'' sont en relation ?
La relation entre ''question'' et ''bonne réponse'' est naturelle, mais il n'y a aucune raison de relier ''question'' et ''réponse''.
Si on fait apparaitre 1 questionnaire ça pourrait donner qquechose comme ça :




A +

[fabszn]

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



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é).

Hello,

Désolé de répondre un peu tardivement, je n'avais pas accès à internet ce week-end.

Premièrement, merci pour votre aide!

Effectivement, j'avais mal lu... oui il n'y a pas deux tables supplémentaires.

Je vais regarder cette solution.
J'aurais aimé avoir votre avis sur la solution que j'ai proposée dans mon message précédent celui là.

Je vous remercie par avance (une nouvelle fois) pour votre aide!

[fabszn]

Bonjour,

Je pense que ta relation circulaire provient de ce que tu occultes 1 partie du contexte dans ton modèle.
Pourquoi ''question'' et ''reponse'' sont en relation ?
La relation entre ''question'' et ''bonne réponse'' est naturelle, mais il n'y a aucune raison de relier ''question'' et ''réponse''.
Si on fait apparaitre 1 questionnaire ça pourrait donner qquechose comme ça :




A +

Hello,

Merci pour ta réponse.

J'ai l'impression que ce que tu proposes se rapproche de la solution que j'ai proposée dans mon post :

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 :

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 :

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

Qu'en penses tu?

Merci d'avance pour ton aide!

[Nanci]

Le problème est en effet interessant....
Commençons par un MCD


Vérifions qu'il prend en compte l'énoncé.
- Une Question comporte de 1àn Réponses; une Réponse n'appartenant qu'à une Question (on identifie la réponse en relatif à la question, c'est plus proche de la réalité. réponse 1, réponse 2, réponse 3 à la Question 5)
- Une Question a une seule bonne Réponse. Le 0,1 coté réponse est tout a fait normal; toute les réponses ne sont pas bonnes; quant une réponse est bonne, elle ne l'est que pour une question.
Le 0,1 coté Question se justifie ainsi. Une Question n'a au plus qu'une seule réponse. Par contre, si l'on met un 1 mini, on se crée un "verrou mortel". En effet, on exige qu'à la création de la Question, on connaisse déjà la bonne réponse. Pour desserrer cette contrainte, il suffit de mettre 0 mini.
- Un Utilisateur donne une Réponse à une Question. Une belle ternaire avec 0,n sur toutes les pattes ! Un utilisateur peut répondre à n questions; une question peut avoir n utilisateurs qui y réponde; une réponse peut être donnée par n utilisateur. [désolé pour TheLeadingEdge]
- Par contre, une belle contrainte d'intégrité fonctionnelle (CIF pour les branchés...): Un utilisateur ne donne qu'une seule réponse à une Question (Util x Quest --> Rep)
- Enfin, les réponses faites aux questions par l'utilisateur sont nécessairement les réponses possibles à la question (trivial, mais il faut le dire....).

Ceci étant, on obtient le modèle relationnel suivant

n° bonne réponse dans Question est facultatif. La contrainte référentielle n'est pas obligatoire et ne sera donc vérifiée que lorsque la valeur de n° bonne réponse sera renseignée.

[fabszn]

Hello,

Merci Nanci pour ta réponse.

Je suis arrivé à peu près au même modéle relationnel que toi.
sauf que j'ai mis dans la table réponse un champ indiquant si la réponse est bonne ou pas.
La table question ne contient que un identifiant et un libelle.

Ci joint le modèle. qu'en penses tu?

Merci d'avance pour votre aide!

[fsmrel]

Bonjour,

La suite du feuilleton...

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
7
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
3
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 ?
Qu'en pensez vous?

Cela peut effectivement s’appeler une table de liens, à ceci près que ce qualificatif ne fait pas partie du vocabulaire du Modèle relationnel. Mais c’est parlant, donc utilisons cette expression qui peut aider à mieux percevoir la nature des choses. L’expression « table associative » n'est pas mal non plus.

Attention, quand vous codez

(1) T_REPONSE -----> 0,1 T_QUESTION_REPONSE

et sachant par ailleurs que l’on a

(2) T_QUESTION_REPONSE --> 1,1 T_REPONSE

vous exprimez une injection de T_REPONSE dans T_QUESTION_REPONSE, c’est-à-dire qu’il existe la dépendance fonctionnelle (Pardon pour ce qui suit, qui relève de la théorie, mais un peu de théorie ne fait pas de mal car cela permet de conforter et d'aller plus loin...) :

(3) REPONSE_ID --> {REPONSE_ID, QUESTION_ID}

et en vertu de la règle de décomposition inférée des 3 premiers axiomes d’Armstrong :

(4) REPONSE_ID --> REPONSE_ID /* dépendance triviale */
(5) REPONSE_ID --> QUESTION_ID

autrement dit, quand vous définissez la clé primaire de QUESTION_REPONSE :

constraint PK1 primary key (QUESTION_ID, REPONSE_ID),
la clé n’est pas minimale, QUESTION_ID doit en être expulsée et il faut coder (c’est imparable) :

constraint PK1 primary key (REPONSE_ID)

Du reste, si l’on y regarde de près, sans même en passer par l’axiomatique, le couple {QUESTION_ID, REPONSE_ID} signifie qu’à une réponse on peut associer plusieurs questions (en contradiction avec la cardinalité 0,1...)

Même si cela n’est intuitif au départ, on en conclut que la table REPONSE peut être absorbée par la table QESTION_REPONSE, avec toutes ses propriétés, auquel cas elle disparaît du modèle :

Create table QUESTION_REPONSE (
QUESTION_ID INTEGER not null,
REPONSE_ID INTEGER not null,
ISBONNEREPONSE BOOLEAN not null,
REPONSE_Att1 ... not null, ... REPONSE_Attn ... not null,______/* propriétés (absorbées) de REPONSE */
Constraint PK1 Primary Key (REPONSE_ID)
);
alter table BONNE_REPONSE
add constraint FK3 foreign key (QUESTION_ID)
references QUESTION (QUESTION_ID)
on delete cascade;

Et comme une réponse n’a pas d’existence autonome, puisqu’elle est au fond une propriété multivaluée d’une question, j’utiliserais personnellement l’identification relative, en numérotant chaque réponse relativement à sa question :

QUESTION_REPONSE (QUESTION_ID, REPONSE_ID, ISBONNEREPONSE, REPONSE_Att1, ..., REPONSE_Attn)
_______________________q1__________1____________faux___________a111_______________a11n
_______________________q1__________2____________vrai__._________a121_______________a12n
_______________________q1__________3____________faux___________a131_______________a13n
_______________________q2__________1____________vrai___.________a211_______________a21n
_______________________q2__________2____________faux___________a221_______________a22n

et l’on doit en conséquence recoder la clé primaire :

Create table QUESTION_REPONSE (...Constraint PK1 Primary Key (QUESTION_ID, REPONSE_ID)

Je propose donc la mise en œuvre de seulement deux tables : QUESTION et QUESTION_REPONSE, en vous laissant le choix du type d’identification : absolu (REPONSE_ID) ou relative (QUESTION_ID, REPONSE_ID) qui a ma préférence, quand une table comporte des dizaines de millions de lignes et que la rapidité d’exécution des requêtes est en jeu. La mise en œuvre de la table REPONSE pour sa part ne se justifie plus, puisqu’absorbée par QUESTION_REPONSE.

Votre sentiment ?
__

[fsmrel]

Mon message précédent. il y a un petit copier/coller erroné :

au lieu de

____"alter table BONNE_REPONSE"

lire

____"alter table QUESTION_REPONSE"

Sorry,

Fsmrel

[TheLeadingEdge]

[désolé pour TheLeadingEdge]

Surtout pas !! Avoir la correction de son MCD par 1 des précurseurs de la méthode c'est la classe (en tt cas c'est comme ça que je le prend)

- Un Utilisateur donne une Réponse à une Question. Une belle ternaire avec 0,n sur toutes les pattes ! Un utilisateur peut répondre à n questions; une question peut avoir n utilisateurs qui y réponde; une réponse peut être donnée par n utilisateur. [désolé pour TheLeadingEdge]

Du coup j'en profite pour solliciter votre avis :
- Cardinalités 1,n (et pas 0,n) entre participant et questionnaire et question et questionnaire :
Mon prof considérait qu'avoir 0 ds 1 cardinalité impliquait que certaines instances de l'entité considérée ne participeraient jamais à aucune relation.
Ca me paraissait (et ça me parait tjours d'ailleurs) juste comme remarque, et je continue de l'appliquer.
Ds le modèle 1 question qui n'est jamais posée n'a guère d'utilité. D° pour participant qui ne répondrait jamais à aucune question.
- Pour 0,1 entre réponse et questionnaire j'ai peut-être un peu m...é. Je voulais dire qu'une réponse ne pouvait apparaître qu'1 fois ds 1 questionnaire, et pas qu'elle ne pouvait apparaitre que ds 1 questionnaire.
2nd point : J'ai materialisé par 1 contrainte <<I>> l'obligation qu'un bonne réponse fasse partie de la relation. Vs ne l'avez pas fait. Pouvez-vs me dire mon erreur ?

Merci du tps que prendrez pour me répondre

[fsmrel]

A l'attention de TheLeadingEdge

Cardinalités 1,n (et pas 0,n) entre participant et questionnaire et question et questionnaire :
Mon prof considérait qu'avoir 0 ds 1 cardinalité impliquait que certaines instances de l'entité considérée ne participeraient jamais à aucune relation.

Je pense qu’il est vraisemblable que ce n’était pas ce que voulait dire votre professeur (posez-lui la question à nouveau...)
Prenons l'exemple des fournisseurs et des factures : on peut admettre que la relation entre Fournisseur et Facture soit 0,n car ça ne sera pas éternel (espérons-le pour le fournisseur, s'il ne veut pas finir sur la paille). Maintenant, si vous préférez une cardinalité 1,n vous ne pourrez insérer un fournisseur dans la base de données qu’à la seule condition que vous le fassiez à l’occasion de la saisie de sa première facture. De la même façon, si vous supprimez les factures d’un fournisseur, vous serez obligé de le supprimer lui aussi. Pour les fournisseurs passe encore, en revanche pour les clients, les commerciaux de votre entreprise ne vont pas apprécier de voir disparaître de précieuses informations (notamment pour les relances)...
En revanche, il paraît légitime d’exiger que certaines relations aient une cardinalité 1,n : cas par exemple de la relation entre facture et ligne de facture.

[fabszn]

Hello,

Merci à tous pour votre aide!!!

Elle aurat été pour moi d'un grand secour et m'aura permis d'apprendre de nouvelles choses!

Visiblement la discussion c'est ouverte à d'autres questions!!

Je coche le sujet comme résolu.. mais celui ci reste ouvert!

Bonne fin de journée

Et encore merci!!

[fsmrel]

Observations concernant le MLD du 23/10/2006 à 15h42.

1) Le chemin référentiel Répond à la question --> Question se déduit du chemin référentiel Répond à la question --> Réponse --> Question : il doit donc disparaître (une réponse utilisateur détermine une réponse, cette réponse détermine une question, donc la réponse utilisateur détermine cette question). Je suppose que cela à un impact sur le MCD.

2) Pour mémoire, avec un SGBDR comme DB2 for z/OS l’intégrité référentielle peut être mise en œuvre, mais seulement avec une action référentielle de type Restrict (ou No action) :

Table Question :
Constraint FK1 Foreign Key (No_Question, No_Bonne_Reponse) References Reponse (No_Question, No_ Reponse) On Delete Restrict;

Table Réponse :
Constraint FK2 Foreign Key (No_Question) References Question (No_Question) On Delete Restrict;

En effet, si on utilise une seule fois l’option Cascade, DB2 détectera un cycle et refusera de mettre en œuvre les contraintes.

L’option Set null de DB2 n’est pas possible ici puisqu’à chaque fois des attributs des clés primaires sont impliqués.

3) A noter que pour supprimer une question, on doit dans l’ordre :

a) commencer par forcer à NULL l’attribut No_Bonne_Reponse (table Question)
b) supprimer la question dans la table Réponse
c) supprimer ma question dans la table Question

4) Les SGBDR utilisant SQL ne devraient pas connaître de problème. En revanche ceux qui utilisent le langage D [1] ne peuvent pas utiliser le MLD proposé : D interdit en effet l’emploi des valeurs nulles (cf. [2] page 586 : “3VL undermine the foundation of the relational model”).

Références

[1] C.J. Date, Hugh Darwen. Foundation for Future Database Systems, The Third Manifesto, Second edition (Addison-Wesley Longman, 2000)
[2] C.J. Date. An Introduction to Database Systems, 8th edition. Pearson: Addison-Wesley (international edition), 2004.

[Nanci]

Juste une réponse rapide à TheLeadingEdge, et à tous, sur les cardinalités

- Cardinalités 1,n (et pas 0,n) entre participant et questionnaire et question et questionnaire :
Mon prof considérait qu'avoir 0 ds 1 cardinalité impliquait que certaines instances de l'entité considérée ne participeraient jamais à aucune relation.
Ca me paraissait (et ça me parait tjours d'ailleurs) juste comme remarque, et je continue de l'appliquer.

La cardinalité 0 mini ne veut pas dire que certaines instances l'entité ne participeront jamais, mais que l'on considère qu'il est possible (état considéré comme normal à un moment donné dans le SI) que certaines instances ne participe pas à la relation. C'est exactement ce qu'illustre fsmrel.
Dans le cas présent, on peut discuter pour savoir si tout utilisateur répond obligatoirement (dès sa création) à un questionnaire.

Ds le modèle 1 question qui n'est jamais posée n'a guère d'utilité

C'est une une illustration parfaite de ma remarque ci-dessus.
Un questionnaire a obligatoirement 1 à n réponses
Par contre, au moment de sa création, et jusqu'à ce qu'un utilisateur veuille bien répondre à la question, Question et Réponse existent sans avoir de lien avec Utilisateur: donc cardinalité mini = 0 sur les deux pattes !

2nd point : J'ai materialisé par 1 contrainte <<I>> l'obligation qu'un bonne réponse fasse partie de la relation. Vs ne l'avez pas fait. Pouvez-vs me dire mon erreur ?

C'est un oubli de ma part