Discussion :

[damien77]

Bonjour j'ai un problème d'analyse et j'aimerais savoir quelle est la meilleur solution.
Je m'explique :
- J'ai une question. une question peut avoir plusieurs réponse
- Pour une question, une personne peut donner une réponse.
Laquelle des deux méthode est la plus sur ?

merci


PS : J'ai mis aucun attribut pour ne pas encombré le MCD pour le moment

[fsmrel]

Bonsoir,

Apparemment une réponse n’est pas propre à une personne, elle peut être commune à plusieurs d’entre elles.

Dans ces conditions, si l’on part du principe qu’une question posée par une personne précède la réponse (unique) à cette question, la table Choix (dérivée de l’entité-type correspondante) doit avoir l’allure suivante (clé primaire soulignée) :

Choix (PersonneId, QuestionId, RéponseId)

Pour remonter au niveau MCD, je propose donc de faire de Choix une entité-type associative, identifiée relativement à Personne et à Question.

MCD correspondant (PowerAMC) :

[damien77]

Ne doit pas ton faire une association entre Reponse et question aussi ?
car une reponse correspond à 1 et une seul question..

[fsmrel]

Bonsoir,

une reponse correspond à 1 et une seul question

La remarque est intéressante, car si une réponse détermine une question, alors la table Choix que j’ai proposée respecte la 3e forme normale, mais pas la BCNF.

Choix (PersonneId, QuestionId, RéponseId)

En effet, la dépendance fonctionnelle RéponseId -> QuestionId a pour déterminant RéponseId qui n’est pas clé candidate de la table Choix.

On peut alors projeter Choix selon deux tables :

PR (PersonneId, RéponseId)
RQ (RéponseId, QuestionId)

Mais on perd une règle de gestion, à savoir que pour une personne et une question il y a au plus une réponse, ce que vous rappelez dans votre premier schéma par une CIF exprimant la contrainte d’unicité :

Personne X Question -> Réponse

Attention, je ne suis pas un champion de Merise/2, aussi je ne garantis pas formellement le paragraphe qui suit.

Concernant la dépendance d’inclusion, elle garantirait qu’une réponse à une question est une réponse donnée par au moins une personne (exact ?), mais il s’ensuivrait un cycle (fâcheux) au niveau tabulaire, et contrairement à la CIF, cette dépendance d’inclusion ne garantit pas l’unicité recherchée, car on pourrait avoir les couples :

<p1, r1> et <p1, r2> d’une part,
<r1, q1> et <r2, q1> d’autre part,

signifiant que p1 fournit deux réponses r1 et r2 à la question q1.

A mon sens, le second schéma n’est donc pas complet.

En tout état de cause, l’essentiel est qu’au niveau tabulaire, les contraintes soient garanties.
On a donc l’alternative :

1) Conserver la table Choix que j’ai proposée, sans la décomposer, mais en introduisant une contrainte garantissant la DF :

RéponseId -> QuestionId

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Create Assertion Assert01 Check
    Not Exists 
     (
       Select X.RéponseId
       From   (Select Distinct RéponseId, QuestionId
               From Choix) As X
       Group By X.RéponseId
       Having Count(*) > 1
     ) ;

2) Effectuer la projection de la table Choix selon PR et RQ, mais cette fois-ci avec 2 contraintes à programmer, dont l’une introduirait un cycle.

Dans tout cela, les contraintes sont assurées par des assertions, à l’aide l’instruction Create Assertion (Standard SQL), instruction malheureusement inconnue des SGBDR : il ne reste alors plus que les triggers et autres palliatifs pour réaliser ces contraintes.