Discussion :

[CinePhil]

Bonjour,

J'ai, d'une part, créé des héritages de utilisateur vers administrateur, professeur et élève, chacun de ces types d'utilisateur ayant des possibilités différentes sur les données (un prof peut créer un cours, un élève seulement s'y inscrire...).
Pour autant, un prof peut très bien être un élève dans une autre matière que la sienne ou un élève peut devenir prof. Ce n'est donc pas un héritage exclusif.

D'autre part, dans l'application, un type d'utilisateur accèdera à certaines fonctions mais pas à toutes.

Voilà l'extrait de mon MCD actuel, fais avec JMerise :


Ce MCD permet à un élève d'être de type prof ou même administrateur.

Comment puis-je représenter la contrainte spécifiant que le type de l'utilisateur matérialisé par tj_ttu_typer_uti_ttu corresponde à l'un des trois héritages ?
Et comment le matérialiser dans la BDD (Postgresql) ? Par un trigger ? Une assertion ?

[escartefigue]

Bonsoir Cinephil

Dans l'absolu qu'un élève puisse être également enseignant voire administrateur n'est pas forcément une aberration, du coup je pose l'incontournable question : quelles sont les règles de gestion ?

Dans l'attente, j'aurai tendance à dire que chaque personne possède un rôle pour un cours ce qui conduirait à une relation à 3 pattes entre personne, cours et rôle

En ce cas, ce serait la présence d'une occurrence de relation en tant qu'admin, qui autoriserait telle personne à avoir des droits étendus sur tel cours

[CinePhil]

Escartefigue, ce n'est pas tout à fait ça ma problématique.

D'un côté, il y a les différents rôles que peut avoir un utilisateur en utilisant l'application, ce qui lui donnera accès à différents menus et fonctions de l'application. C'est la partie basse de mon extrait de schéma.
Ainsi, un utilisateur peut être :
- seulement élève ;
- seulement prof ;
- élève et prof (parce qu'un prof dans une matière peut avoir envie de suivre un cours dans une autre matière) ;
- élève et admin (parce qu'un admin a bien le droit de s'inscrire à un cours, après tout !) ;
- prof et admin (parce qu'un admin peut avoir des compétences pour être prof dans une matière ou devenir admin après avoir été prof et rester prof sur sa matière tout en accédant aux fonctions d'admin).

De l'autre côté il y a ce que font réellement les profs et les élèves sur le site (délivrer un cours, suivre un cours, proposer des exercices et les corriger, répondre aux exercices relatifs au cours...). C'est la partie héritage de mon schéma qui différencie les associations avec les autres données (cours, exercices...).

Maintenant, si Jean Dupont est seulement élève et n'a accès qu'aux fonctions pour les élèves (il sera donc identifié dans th_eleve_elv), rien n'interdit dans mon schéma qu'il soit, par une manip accidentelle sur la BDD en fait enregistré dans tj_typer_uti_ttu en tant que prof ou admin et voit apparaitre les fonctions réservées aux profs ou aux admins.
Inversement, si l'utilisateur Jean Dupont est déclaré en tant qu'élève dans tj_typer_uti_ttu mais ne figure pas dans th_eleve_elv, il aura accès aux fonctions des élèves mais ça pourra planter parce que ses données ne seraient pas en association avec th_eleve_elv.

Donc, ma première question est :
Comment représenter dans mon MCD la contrainte qui oblige un utilisateur de tel type de figurer également dans le bon héritage correspondant à ce type ?

Ou bien y a t-il un autre moyen de modéliser ces deux aspects des choses pour empêcher une incohérence de données.

Ma seconde question qui sort du cadre du forum schéma est :
Que dois-je utiliser dans Postgresl pour formaliser cette contrainte ? Trigger(s) ? Assertion(s) ? Contraintes CHECK ?

Bien entendu, mon programme applicatif va bien faire les choses mais il peut arriver n'importe quoi qui contourne l'application et empêche le bon enregistrement des données en BDD par l'application.

Pour le moment, c'est simple ; je commence le développement et je suis tout seul et serai admin et prof. Mais j'espère qu'il y aura très vite d'autres profs (qui ne seront pas admins) et surtout qu'il y aura des élèves intéressés par mon site. Si mon concept fonctionne, j'aurai sans doute des cas de profs voulant aussi être élève, d'élèves devenant prof. Et le site a du succès, j'aurai besoin d'autres admins qui pourront être choisis parmi les profs et/ou les élèves. Voilà pourquoi je veux blinder ça dès le départ.

[alassanediakite]

Salut

- élève et prof (parce qu'un prof dans une matière peut avoir envie de suivre un cours dans une autre matière) ;
- élève et admin (parce qu'un admin a bien le droit de s'inscrire à un cours, après tout !) ;
- prof et admin (parce qu'un admin peut avoir des compétences pour être prof dans une matière ou devenir admin après avoir été prof et rester prof sur sa matière tout en accédant aux fonctions d'admin).
...

En dehors de la fonctionnalité utilisateurs et droits comment le schéma répond-il à ces problématiques.
Je suppose que prof, admin et élève héritent d'une table personne. A mon humble avis, c'est à cette dernière qu'il faut s'attaquer pour résoudre le problème.
Pour moi je lie la table tuser à la table personne tout en ajoutant le champs (ou colonne si vous préférez) naturepersonne(=élève, prof, ou admin).
@+

[escartefigue]

De l'autre côté il y a ce que font réellement les profs et les élèves sur le site (délivrer un cours, suivre un cours, proposer des exercices et les corriger, répondre aux exercices relatifs au cours...). C'est la partie héritage de mon schéma qui différencie les associations avec les autres données (cours, exercices...).

C'est cette remarque qui me perturbe.
A mon sens, un utilisateur est par exemple professeur, par ce que on l'a reconnu en tant que tel et donc accordé les droits qui vont avec, peu importe qu'il exerce véritablement son professorat ou non.
En d'autres termes, ouvrir les droits "professeur d'histoire" à l'utilisateur "dupond" doit suffire à considérer que dupond intervient en tant que professeur dans la matière histoire
A priori, sauf si le MCD fourni n'est qu'une ébauche, il n'y a aucun attribut spécifique lié aux sous-types, du coup ces sous-types ne sont plus nécessaires.
Ensuite, pour vérifier que l'utilisateur "dupond" a le droit de rédiger ou corriger un cours d'histoire, il faut poser une CIF de la relation "rédiger" ou "corriger" vers la relation entre cet utilisateur et la matirère pour laquelle il est professeur.
Cette CIF se résoudra par une contrainte de type "reference"

[CinePhil]

C'est cette remarque qui me perturbe.
A mon sens, un utilisateur est par exemple professeur, par ce que on l'a reconnu en tant que tel et donc accordé les droits qui vont avec, peu importe qu'il exerce véritablement son professorat ou non.
En d'autres termes, ouvrir les droits "professeur d'histoire" à l'utilisateur "dupond" doit suffire à considérer que dupond intervient en tant que professeur dans la matière histoire

Je pars du principe que la BDD doit interdire à l'élève Durand de créer un cours s'il n'est pas également typé en tant que professeur.
L'héritage, dans mon schéma, sert à dire que c'est le prof Dupont qui a créé le cours et l'élève Durand qui s'y est inscrit.

A priori, sauf si le MCD fourni n'est qu'une ébauche, il n'y a aucun attribut spécifique lié aux sous-types, du coup ces sous-types ne sont plus nécessaires.

1) Ils sont nécessaires parce qu'ils ont des associations différentes.
2) Il est fort probable que j'aie besoin de la date de naissance de l'élève pour avoir une idée de sa capacité en terme de compréhension des exercices qui lui seront proposés, et que j'aie par ailleurs besoin d'enregistrer le tarif du professeur ou d'autres informations spécifiques aux professeurs. Pour le moment, il est vrai que l'héritage vers administrateur est inutile et il est possible que ça le reste.

Ensuite, pour vérifier que l'utilisateur "dupond" a le droit de rédiger ou corriger un cours d'histoire, il faut poser une CIF de la relation "rédiger" ou "corriger" vers la relation entre cet utilisateur et la matirère pour laquelle il est professeur.
Cette CIF se résoudra par une contrainte de type "reference"

Ça c'est un autre sujet.

[escartefigue]

Je pars du principe que la BDD doit interdire à l'élève Durand de créer un cours s'il n'est pas également typé en tant que professeur.
L'héritage, dans mon schéma, sert à dire que c'est le prof Dupont qui a créé le cours et l'élève Durand qui s'y est inscrit.

Ensuite, pour vérifier que l'utilisateur "dupond" a le droit de rédiger ou corriger un cours d'histoire, il faut poser une CIF de la relation "rédiger" ou "corriger" vers la relation entre cet utilisateur et la matirère pour laquelle il est professeur.
Cette CIF se résoudra par une contrainte de type "reference"

Ça c'est un autre sujet.

J'ai du mal à suivre, ou alors je me suis mal exprimé
Dans ma proposition, avec la contrainte "référence" il est impossible à l'élève "durand" de créer un cours dans lequel il n'est pas professeur.

1) Ils sont nécessaires parce qu'ils ont des associations différentes.

Comme les associations n'apparaissaient pas dans l'extrait commniqué, j'ai supposé que c'étaient justement celles requises pour "rédiger", "corriger" etc...
Dans ma proposition, ces associations sont attachées directement à l'utilisateur, sans besoin de sous-type, et c'est la CIF qui règle le sujet

[CinePhil]

Donc tu supprimerais les héritages et tu mettrais une CIF par association entre utilisateur et cours, exercice...
Les héritages rendent inutiles ces CIF là, justement !

Bon, pas très grave si la représentation n'est pas possible. À moi de développer ça correctement.

[escartefigue]

Voilà c'est ça : je n'utilise que des CIF, plus besoin d'héritage
Bien sur, applicable seulement si les relations qui n'apparaissent pas sur l'extrait du modèle, ont bien des identifiants communs et qui constituent une clef unique dans la table issue de la relation cible de la contrainte

Exemple ci-dessous : j'utilise l'id relative du cours par rapport à la matière pour pouvoir vérifier que l'utilisateur qui rédige un cours est bien enseignant pour la matière concernée par le cours

Pièce jointe 319900

[CinePhil]

Ce n'est pas exactement comme ça que je modéliserais...
Dans mon projet, un utilisateur élève ne suit pas (ne s'inscrit pas à) une matière mais un cours et ce cours concerne effectivement une matière (quoique il n'est pas impossible qu'il y ait des cours concernant plusieurs matières ; c'est même fort probable).

Votre CIF empêche un prof non enseignant d'une matière de rédiger un cours dans cette matière mais ce n'est pas le problème que j'expose.
Votre schéma n'interdit pas un utilisateur de type élève seulement (pas prof, donc) de rédiger un cours. Pour aller loin, un bambin de huit ans pourrait être enregistré en tant que rédacteur d'un cours de maths de niveau master.

Moi il me faut une sorte de cif qui empêche ça. En règle de gestion, la contrainte en langage commun serait celle-ci :
Seul un utilisateur de type prof peut rédiger un cours, proposer un exercice et le corriger.

Avec l'héritage, je suis sûr que le rédacteur sera un prof mais ce dont je veux m'assurer est que l'identifiant du prof dans th_professeur_prf soit bien associé à l'identifiant du type professeur dans tj_tyu_typer_uti_ttu.
C'est ça que je souhaite représenter sur le MCD si c'est possible symboliquement (sinon une note suffira) et je m'interroge aussi sur la technique à mettre en oeuvre dans la BDD pour implémenter cette contrainte (assertion, trigger, check... ?).

[escartefigue]

Votre CIF empêche un prof non enseignant d'une matière de rédiger un cours dans cette matière mais ce n'est pas le problème que j'expose.
Votre schéma n'interdit pas un utilisateur de type élève seulement (pas prof, donc) de rédiger un cours. Pour aller loin, un bambin de huit pourrait être enregistré en tant que rédacteur d'un cours de maths de niveau master.

Non : avec ce modèle le MLD donne les tables et contraintes suivantes
Cours : (MA_id, CO_id)

constraint MA_id references matiere(MA_id)

Rediger : (UT_id, MA_id, CO_id)

constraint UT_id references utilisateur(ut_id)
constraint MA_id, CO_id references cours(ma_id, co_id)
constraint ma_id, ut_id references enseigner (ma_id, ut_id)

Enseigner : (UT_id, MA_id)

Mon modèle vérifie bien (ce que j'ai mis en rouge) que seul un utilisateur présent dans la relation enseigner pour la matière peut rédiger un cours de cette matière
Du coup un élève non prof ne peut jamais rédiger de cours, seul un prof de la bonne matière peut le faire


Mais le souci est que les cours peuvent être multi-matière du coup ça ne tient plus car je ne peux plus identifier un cours relativement à la matière
Je n'ai pas le temps d'y réfléchir ce soir, j'essaye de reprendre le sujet demain

[escartefigue]

J'avoue ne pas arriver à trouver de solution via la modélisation à cause du cours multi-matière
Si cette règle est incontournable, je sèche

[escartefigue]

J'avoue ne pas arriver à trouver de solution via la modélisation à cause du cours multi-matière
Si cette règle est incontournable, je sèche

Quoi-que, je reviens à la charge car

Si un cours est multi-matière
Si seul un prof qualifié pour une matière peut rédiger un cours
Alors il faut potentiellement deux profs pour rédiger le cours (sauf si, cas particulier, le prof enseigne les deux matières ce qui ne change rien à ma proposition)
Du coup, on peut considérer qu'il s'agit en fait de deux cours, qu'on peut associer par une nouvelle relation pour matérialiser qu'ils sont enseignés ensemble dans une même unité de temps et dans un même lieu (relation avec une cardinalité mini de zéro bien sur)

Avec cette proposition, mon schéma qui précède répond au besoin

[JPhi33]

Bonsoir à tous,

Mon avis est à l'inverse de celui d'escartefigue.

Mais avant d'en parler, revenons à la problématique. Philippe, tu veux associer chacune des occurrences d'une entité (ta_type_utilisateur_tyu) à une entité (th_eleve_elv, th_professeur_prf, ...) Et bien, ce n'est pas prévu. A ma connaissance, seuls deux auteurs ont avancé dans cette voie : Yves Tabourier dans "De l'autre côté de MERISE" et José MOREJON dans "Merise vers une modélisation orientée objet".

Ce dernier propose la modélisation d'un lien de type "est occurrence de" représenté par un triangle évidé au milieu du lien : [ S ]----|>----[ C ] ; S étant par ailleurs la spécialisation d'une entité G liée à C (entité critère) par une association de typage. Pour faire un parallèle avec ton schéma :

• G correspond à th_utilisateur_uti
• S correspond à th_eleve_elv, etc.
• C correspond à ta_type_utilisateur_tyu

Mais ces deux auteurs en restent au stade de la modélisation sans envisager l'implémentation en bdd.


Pour en revenir à mon avis, je pense que l'entité ta_type_utilisateur_tyu est superflue. Sa suppression du MCD résoud tous les problèmes.
1) Les types d'un utilisateur sont donnés par leur présence dans les entités spécialisées
2) Tu ne peux plus avoir d'incohérence entre le type d'un utilisateur et sa présence dans une entité spécialisée ou une autre.
3) Lorsque tu veux savoir si un utilisateur est élève, tu interroges l'entité Elève (oui, je raccourcis tes noms d'entités qui sont un peu longs à écrire ), idem pour les professeurs.

Quant à savoir quels sont leurs droits, les entités associées à chacune des entités Elève, Professeur et Admin sont suffisantes pour celà.
Par exemple : "seul un professur est habilité à rédiger un cours". Cette règle est implémentée en créant une occurrence d'association ("rédiger") entre Professeur et Cours. Par conséquent, il est impossible qu'un élève rédige un cours puisqu'on ne peut pas créer cette occurrence d'association.

[CinePhil]

je pense que l'entité ta_type_utilisateur_tyu est superflue.

Elle sert, par son association avec ta_fonction_fct à ouvrir des droits sur les fonctions du logiciel selon le type d'utilisateur.
Si je la supprime, comment je fais pour savoir que l'utilisateur Professeur Dupont a accès aux fonctions des profs ?

La partie basse de mon schéma permet de gérer les accès aux fonctions de l'application selon le type d'utilisateur.
La partie haute concerne les actions concrètes des utilisateurs (créer un cours, un exercice, suivre un cours, répondre à un exercice...).

Encore une fois, j'aimerais empêcher, dans la BDD, un utilisateur seulement élève d'être enregistré en tant que créateur de cours ou d'exercices. Comme il est possible que je programme des procédures SQL pour tout ce qui touche au DML, la procédure de création d'un cours pourra vérifier que le prof créateur est bien un utilisateur de type prof. Ou bien la procédure de création d'un prof peut aussi créer automatiquement l'association entre l'utilisateur et son type prof.
La représentation de cette contrainte sur le schéma est finalement un aspect secondaire. Si ce n'est pas représentable, tant pis.

[JPhi33]

Si je la supprime, comment je fais pour savoir que l'utilisateur Professeur Dupont a accès aux fonctions des profs ?

Tu sélectionnes les lignes de la table Professeur avec l'identifiant de Dupont.
Si une ligne est sélectionnée, c'est un prof.
Si aucune ligne n'est sélectionnée, ce n'est pas un prof.