Discussion :

[ibram_im]

Bonjour!

j'ai ce diagramme de classe qui me semble embigu.


j'aimerai optimiser ce diagramme pour qu'il y'ait plus de redondance. en fait dans ma logique, je voudrai savoir à tout moment que un Employé X utilise une application
Y et a le Profil Z dans cette application.
voici les règles de gestion:

un employé peu utiliser 1...* application
une application est utilisée par 1..* employe
une application possède 1..* profil
un profil est possédé par une seule application
un employé peut avoir 1..* profil
un profil peut être possédé par 1..* employé

Merci d'avance pour votre aide

[bruno_pages]

Bonjour,

Je ne vois pas ce qui est ambiguë dans le diagramme qui me semble bien

Seules remarques :

• nom et prénom sur un caractère c'est un peu court, une string me parait plus approprié
• les intitulés de type int c'est également bizarre, j'aurais également vu une string
• la multiplicité 0..* devrait être 1..* d'après les règles de gestion, ceci dit je trouve bizarre que par exemple un profil soit impérativement utilisé par un utilisateur

[CinePhil]

je voudrai savoir à tout moment que un Employé X utilise une application
Y et a le Profil Z dans cette application.

Le problème que vous soulevez est, si j'ai bien compris, qu'avec votre diagramme, rien n'interdit un employé qui n'a pas le profil requis pour une application d'utiliser cette application. C'est ça ?

Comme le profil est dépendant de l'application il peut être identifié relativement à l'application : Profil(id_application, numero_profil, intitule). Dans la BDD, la table Profil aurait pour clé primaire le couple (id_application, numero_profil).

Ensuite, si un employé ne peut avoir qu'un seul profil dans une application, il suffirait de savoir quel profil il est en train d'utiliser pour savoir quelle application il utilise. Le lien entre Employe et Application devient inutile.

[ibram_im]

• la multiplicité 0..* devrait être 1..* d'après les règles de gestion, ceci dit je trouve bizarre que par exemple un profil soit impérativement utilisé par un utilisateur

Merci pour ces remarques.
par rapport fait que un profil soit impérativement utilisé par un utilisateur, mon chef me dit qu'il y' aura un profil spécial pour toute personne qui n'aura pas d'application a utiliser. alors la requête sera facile pour interroger la DB sur la liste d'application ainsi que les profils utilisés pour un employé donné.

[ibram_im]

Mercie pour ces remarques et propositions

Ensuite, si un employé ne peut avoir qu'un seul profil dans une application, il suffirait de savoir quel profil il est en train d'utiliser pour savoir quelle application il utilise. Le lien entre Employe et Application devient inutile.

dans ce cas, quelles seront les cardinalités au niveau de la relation entre Employé et Profil?
Merci d'avance

[CinePhil]

Ensuite, si un employé ne peut avoir qu'un seul profil dans une application, il suffirait de savoir quel profil il est en train d'utiliser pour savoir quelle application il utilise. Le lien entre Employe et Application devient inutile.

Dans ce cas, quelles seront les cardinalités au niveau de la relation entre Employé et Profil?

Les règles de gestion que j'ai supposées ici sont les suivantes :
R1 : Un profil est lié à une seule application et une application comporte de un à plusieurs profils.
R2 : Un profil peut être attribué à plusieurs employés et un employé se voit attribuer de un à plusieurs profils => conséquence : s'il a plusieurs profils, c'est qu'il est habilité à utiliser plusieurs applications.

Diagramme de classes :
Employe -*--------1..*- Profil -1..*--------1..1- Application

Tables :
Employe (emp_id, emp_nom, emp_prenom...)
Application (app_id, app_nom...)
Profil (prf_id_application, prf_numero, prf_libelle...)
Employe_Profil (emp_id, prf_id_application, prf_numero...)

Le profil est identifié relativement à l'application ; la clé étrangère référençant l'application fait partie de la clé primaire de la table Profil.
Ainsi, si on veut savoir quelles applications à le droit d'utiliser l'employé, il suffit d'interroger la table associative Employe_Profil et la relation entre Employé et Application est implicite ; inutile de la représenter dans le DC et de l'implémenter supplémentairement dans la BDD.

[ibram_im]

CinePhil , merci pour la réponse rapide et les explication mon diagramme est bien optimisé