Discussion :

[arthuro45]

Bonjour,

J'aimerais votre avis sur mon MCD.
Je dois créer des profils et leur affecter des droits sur le menu de mon site, certains verront tous et d'autres non. (Le début d'une gestion utilisateurs).

PROFIL
id_profil
code
libelle

MENU
id_menu
theme
sous_menu

PROFIL_MENU
id_profil_menu
id_profil
id_menu

[JPhi33]

Bonjour arthuro45,

Ce modèle manque cruellement d'indications de type :
- clé primaire (clé alternative)
- clé étrangère identifiante
- clé étrangère non identifiante

Tout ceci est à préciser.

[arthuro45]

Oui effectivement

PROFIL
id_profil PK
code
libelle

MENU
id_menu PK
theme
sous_menu

PROFIL_MENU
id_profil_menu PK
id_profil
id_menu

[JPhi33]

Pour une gestion de droits, ne manque-t-il pas une donnée de type "niveau de droit" ? Par exemple : "administrateur", "utilisateur", "utilisateur avec pouvoir", etc.

Si un profil n'a qu'un seul niveau de droits par menu, alors id_profil_menu est inutile :

PROFIL_MENU (DROIT ?)
id_profil PK, FK
id_menu PK, FK


Pour conclure, la rétro-ingénierie en modèle conceptuel donne :

[ PROFIL ]--0,n----( DROIT )----0,n--[ MENU ]



En supposant que chaque droit accordé à un profil pour un menu donné relève d'un seul niveau de droit, on a :

( DROIT )--1,1----( )----0,n->[ NIVEAU_DROIT ]

Ce qui se traduit au niveau logique par :

NIVEAU_DROIT
id_niveau_droit PK
intitulé_niveau_droit

DROIT
id_profil PK, FK
id_menu PK, FK
id_niveau_droit FK

[arthuro45]

Pour conclure, la rétro-ingénierie en modèle conceptuel donne :

[ PROFIL ]--0,n----( DROIT )----0,n--[ MENU ]

Intéressant, les droits sur les données seraient gérés par DROIT et les droits fonctionnels par MENU, ou mon MCD ne suffit pas pour gérer les 2 ?

Pour une gestion de droits, ne manque-t-il pas une donnée de type "niveau de droit" ?

Je pensais qu'implicitement la notion de droit était acquise par le fait d'affecter un menu à un profil.

Donc si je reprend :

NIVEAU_DROIT
id_niveau_droit PK
intitulé_niveau_droit

DROIT
id_profil PK, FK
id_menu PK, FK
id_niveau_droit FK

MENU
id_menu PK
theme
sous_menu

[JPhi33]

Intéressant, les droits sur les données

Ca, c'est nouveau. Il n'en n'était pas question dans le post d'origine. Quelles sont les règles de gestion en matière de droit sur les données ?

seraient gérés par DROIT et les droits fonctionnels par MENU

Non, l'association DROIT (donc la table DROIT) ne sert qu'à enregistrer les droits sur les menus et la table MENU ne sert qu'à enregistrer les menus.

Je pensais qu'implicitement la notion de droit était acquise par le fait d'affecter un menu à un profil.

Oui, mais ce n'est pas implicite. Affecter un menu à un profil doit être enregistré. Ceci est fait dans la table DROIT.



Si la notion de niveau de droit n'existe pas, il suffit de supprimer la table NIVEAU_DROIT (et la clé étrangère correspondante dans la table DROIT).

[arthuro45]

Code :

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

Ca, c'est nouveau. Il n'en n'était pas question dans le post d'origine. Quelles sont les règles de gestion en matière de droit sur les données ?

Je ne connais pas les règles en matière de droit sur les données.

Pouvez-vous me donner votre avis sur l'état de mon MCD, celui-ci se veut simpliste et gère une gestion utilisateur :

[JPhi33]

Sans être fausse, la table DROIT_PROFIL n'est pas conforme au MLD (j'ai ôté la FK id_niveau_droit puisqu'il n'y a pas de gestion de niveau de droit) :

DROIT
id_profil PK, FK
id_menu PK, FK

L'annotation "PK" en regard des attributs id_profil et id_menu signifie que la clé est constituée par l'ensemble de ces deux attributs qui se trouvent être aussi des clés étrangères (annotation FK).

L'introduction de l'attribut ID_DROIT_PROFIL en tant que clé primaire, en remplacement de la clé {id_profil, id_menu} du MLD, n'est pas fausse en soi mais elle autorise l'insertion de droits erronés. Par exemple :

Code :

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

1
2
3
4
5
6
7
ID_DROIT_PROFIL ID_PROFIL ID_MENU
--------------- --------- -------
1               P1        M1
2               P1        M2
3               P1        M1
4               P1        M1

Dans cet exemple, le couple (P1, M1) existe en triple exemplaire, ce qui est évidemment inutile, mais aussi dangereux en cas de suppression (on pourrait en oublier). Pour y remédier, il faudra doter le couple {ID_PROFIL, ID_MENU} de la clause "UNIQUE" ou contrôler l'unicité par programme si cette clause n'est pas disponible sur un ensemble d'attributs.

Bref, en résumé, il est beaucoup plus simple de respecter le MLD lors de l'implémentation du MPD.

[arthuro45]

Merci, vos explications sont limpides.

Code :

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

L'introduction de l'attribut ID_DROIT_PROFIL en tant que clé primaire, en remplacement de la clé {id_profil, id_menu} du MLD, n'est pas fausse en soi mais elle autorise l'insertion de droits erronés.

Je suppose qu'il en va de même pour la table DROIT_UTILISATEUR avec la PK id_droit_utilisateur ?

[JPhi33]

Je suppose qu'il en va de même pour la table DROIT_UTILISATEUR avec la PK id_droit_utilisateur ?

Bien entendu. Comme pour la table DROIT_PROFIL, la clé unique de la table DROIT_UTILISATEUR, définie par le couple {ID_UTILISATEUR, ID_PROFIL}, se suffit à elle-même.

Selon cette table, un utilisateur peut donc avoir plusieurs profils. Cette règle de gestion est plutôt rare. Habituellement, un utilisateur a un profil (et ce profil dispose de droits sur les différents éléments de l'application : menus, données, actions, etc.)

[arthuro45]

Code :

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

Selon cette table, un utilisateur peut donc avoir plusieurs profils. Cette règle de gestion est plutôt rare. Habituellement, un utilisateur a un profil (et ce profil dispose de droits sur les différents éléments de l'application : menus, données, actions, etc.)

J'ai supprimé la table DROIT_UTILISATEUR qui effectivement n'avait pas de "sens" si un utilisateur n'a qu'un profil, et c'est le cas dans le cahier des charges.

J'ai ajouté une table SESSION pour tracer les connections des utilisateurs, cette table ne vous semble pas redondante ?

[JPhi33]

Non, à première vue, la table SESSION n'est redondante avec rien.

Attention à bien conserver l'ID_SESSION courant de chaque utilisateur connecté afin de mettre à jour FIN_CONNECTION dans la bonne ligne de la table.

[arthuro45]

Merci pour vos réponses, je vais pouvoir avancer de façon plus structuré dans le monde de la conception.