Discussion :

[asasn]

Bonjour,

Voilà je suis actuellement sur la modélisation d'une base de données. Mais je me pose quelque petites questions que je vais vous soumettre.

Première problématique :

Dans mon modèle j'ai des utilisateur qui ont ou non un N+1. Imaginons ceci.

Pascal -> N+1 Paul -> N+1 Cédric -> N+1 Marc .

Donc dans cette table j'aurais des personnes qui auront des managers et d'autre non.

Comment j'enregistre cette donné ?

Dans ma première idée c'était d'avoir une relation récursive. Mais cela voudrais dire que chaque utilisateur a forcement un manager.


Deuxième problématique :

Quand un utilisateur réponds à un questionnaire il obtiens des compétences mais en fonction d'une activité et de N thème. Comment j'enregistre la compétence obtenu ?

Ceci sera plus parlant :




Un utilisateur obtiens une ou plusieurs compétences en fonction de l'activité et du thème. Il pourrait très bien avoir ceci :

Activite 1 -> Theme A => Competence AZ
Activite 1 -> Theme B => Competence AB
Activite 1 -> Theme C => Competence AC

Ou

Activite 2-> Theme A => Competence AD
Activite 2 -> Theme D => Competence Az
Activite 2 -> Theme E => Competence AC

Merci pour votre aide.

[escartefigue]

Donc dans cette table j'aurais des personnes qui auront des managers et d'autre non.

Comment j'enregistre cette donné ?

Dans ma première idée c'était d'avoir une relation récursive. Mais cela voudrais dire que chaque utilisateur a forcement un manager.

Ou plutôt, une relation reflexive
Non, une relation reflexive peut tout à fait avoir des cardinalités minimales à zéro, du coup, le chef comme le collaborateur sont facultatifs (tout le monde n'est pas forcément encadrant ni encadré)

Schématiquement

.............┌----- encadre ------┐
........0,n │..........................│
[PERSONNE]...................(encadrer)
....... 0,1.│..........................│
.............└- est encadré par --┘

Deuxième problématique :
Quand un utilisateur réponds à un questionnaire il obtiens des compétences mais en fonction d'une activité et de N thème. Comment j'enregistre la compétence obtenu ?

Il faut établir un barème avec des coefficients, un peu comme pour le baccalauréat.
Selon les compétences, les notes dans telle ou telle activité ou thème n'ont pas la même importance. Vous leur appliquez donc le coefficient lié à la compétence puis vous additionnez les résultats et si le total atteint le total requis, la compétence est acquise

[asasn]

Merci pour ta réponse escartefigue.

Je fais mon MCD et je te le soumets.

PS: Je viens de me rendre compte que j'ai mal exprimé la demande.

C'est plutôt un utilsateur pour une évaluation peut obtenir X compétence sur un couple activité et thème.

Ex :

Activite 1 => Theme A => Competence AA

Activite 2 => Theme A => Competence AB

On voit bien que le theme A ce retrouve dans deux activité et que j'ai mon utilisateur qui a deux compétence différente. Demain quand il va repasser un questionnaire sur une même ou une autre activité. Et que potentiellement le thème A ce retrouve encore dedans. Je prendrais la plus grosse compétence obtenu. Car oui je garde le lexique du donneur d'ordre mais une Compétence est simplement un niveau.

[asasn]

Bonjour,

Du coup j'ai fais ceci :



Mais je n'arrive pas à placer la table skill. Car l'utilisateur qui passe une évaluation sur un quiz obtiens des skills en fonction du couple activité et thème.

Une activité peux avoir 1 à 9 thème. Mais des thèmes peuvent se retrouver dans plusieurs activités. Ils faut donc que je puisse savoir le skill obtenu en fonction du couple activité et thème.

Autre chose. J'ai la table answer qui regroupe les réponses possible à une question avec la bonne réponse. Si elle doit coché ou non.

Comment j'enregistre les réponses de mon utilisateur.

Je séche là.

[asasn]

Bonjour,

Bon j'ai réussi pour moi la base de données devrait se faire ainsi :



J'aimerais bien qu'un "pro" regarde afin de me dire si il vois d'éventuelle erreur de conception.

Merci pour votre aide.

[escartefigue]

Bonjour,

Ma vue n'est plus ce qu'elle était et j'ai du mal à déchiffrer le contenu de chacune des tables.
Pour le confort de lecture et la compréhension, il est préférable de présenter le diagramme découpé en sous-ensembles fonctionnels (par exemple ce qui concerne les étudiants, les cours, les enseignants...)

Cela étant, un MLD brut de fonderie c'est un peu court pour valider, il manque les règles de gestion

[asasn]

Bonjour,

Ma vue n'est plus ce qu'elle était et j'ai du mal à déchiffrer le contenu de chacune des tables.
Pour le confort de lecture et la compréhension, il est préférable de présenter le diagramme découpé en sous-ensembles fonctionnels (par exemple ce qui concerne les étudiants, les cours, les enseignants...)

Cela étant, un MLD brut de fonderie c'est un peu court pour valider, il manque les règles de gestion

Bonjour,

Effectivement j'ai omis de mettre les règles de gestion.

Je vais énumérer les règles ou je peux avoir un doute.

1/ Un utilisateur passe une evaluation. Cette évaluation est sur une activité qui comporte plusieurs thèmes. Pour chaque thèmes mon utilisateur peux obtenir un skill différent.
Exemple:

Evaluation sur Activité A qui comporte le thème 1, le thème 2 et le 3. Pour l'activité A mon utilisateur obtiens le sill A sur le thème 1, le skill C sur le thème 2 et le skill E sur le thème 3.
Celui-ci pourrais éventuellement passer une évaluation sur une Activité C avec le thème 2 qui revient. Et obtenir un skill B cette fois.
Donc comment j'enregistre chaque skill de mon utilsateur par rapport au couple Activité et thème ?

Voilà qui permettra de comprendre ce que j'ai voulu faire et ci cela est bon pour cette partie.

Merci de votre aide.

[fsmrel]

Bonsoir,

un MLD brut de fonderie c'est un peu court pour valider, il manque les règles de gestion

Je confirme ! Un MLD (ou un MCD) est une conséquence des règles de gestion, mais dans la très grande majorité des cas les règles de gestion ne sont pas la conséquence du MLD.

asasn, examinons par exemple les tables USER et FRAME. Selon votre diagramme :

(RG1) Chaque utilisateur est au moins et au plus un manager ;

(RG2) Chaque manager est au moins et au plus un utilisateur ;

(RG3) Chaque utilisateur encadre au moins un et au plus plusieurs utilisateurs ;

(RG4) Chaque utilisateur est encadré par au moins et au plus un utilisateur.

Du fait de la conjugaison des règles RG1 et RG2, il y a bijection entre USER et FRAME, ce qui se traduit au niveau des opérations par une boucle infinie.
Du fait de la conjugaison des règles RG3 et RG4, il y a surjection entre USER et FRAME, ce qui se traduit au niveau des opérations par une autre boucle infinie.

On retrouve donc le problème que vous désiriez éviter quand vous écrivîtes à juste titre :

Dans ma première idée c'était d'avoir une relation récursive. Mais cela voudrais dire que chaque utilisateur a forcement un manager.

Il faut donc remplacer la bijection par une injection :

[USER]—||^________O|—[FRAME]

Et remplacer la surjection par une application :

[USER]—||------O<[FRAME]

Qui plus est, vous avez utilisé l’identification relative : FRAME est alors à la fois une propriété monovaluée de USER et une propriété multivaluée de USER, bref, dans votre diagramme, FRAME a pour clé primaire la paire {frame_fk_manager_user_id, frame_fk_user_id}, alors que ça devrait être le singleton {frame_fk_user_id}.

En tout cas, l’ensemble de vos tables est à vérifier quant aux cardinalités minimales et à l’dentification relative. Par exemple, l’association entre TYPE_QUIZ et QUIZ est très vraisemblablement « non identifying », car QUIZ fait plutôt référence à TYPE_QUIZ au lieu d’en être la propriété :

[TYPE_QUIZ]—||------O<[QUIZ]

D’où l’élimination de la colonne quiz_fk_type_quiz_id dans la clé primaire de la table QUIZ.