Bonsoir Marco94,
Envoyé par
Marco94
Un salarié DIRECTEUR accède à toutes les affaires d'une ou plusieurs entités
Un salarié a-t-il tous les droits sur les affaires d’une entité dont il est directeur ? (Le verbe « accéder » est ici ambigu).
Une entité peut-elle avoir plus d’un directeur ? (selon votre diagramme c’est possible).
Envoyé par
Marco94
Un salarié RESPONSABLE D'AFFAIRE ne verra que les affaires auxquelles il est rattaché.
Votre diagramme ne montre pas les liens entre les salariés et les affaires dont ils sont responsables. Ces liens seront-ils établis à l’occasion de la définition de leurs droits sur ces affaires ?
Dans le diagramme ci-dessous, on part sur les règles suivantes (à confirmer) :
R01 - Seuls certains salariés sont administrateurs (rôle Être admin).
R02 - Seuls certains salariés sont directeurs (rôle Être directeur).
R03 - Un salarié peut être directeur de plus d’une entité.
R04 - Une entité a exactement un directeur.
R05 - Tout salarié
S responsable d’une affaire
A de l’entité
E fait l’objet d’une ligne <
E,
S> dans la table ENTITE_SALARIE.
R06 - Un responsable d’une affaire peut avoir plusieurs droits sur cette affaire.
R07 - La table RESP_AFFAIRE a pour prédicat :
Pour l’affaire A de l’entité E, le salarié S a le droit D
La table RESP_AFFAIRE contient les quadruplets de valeurs <
a,
e,
s,
d> tels que
s représente un responsable d’affaire qui n’est pas directeur de l’entité
e (Le responsable
s peut être directeur d’une autre entité, mais ceci n’a pas à être consigné dans la table RESP_AFFAIRE puisque connu grâce à la table DIRECTEUR, et il y aurait alors redondance).
A noter que les valeurs des clés primaires sont non significatives et hors du champ de vision (donc du contrôle) de l’utilisateur (cf. l’observation d’Yves Tabourier). Par exemple, {AffaireCode} est clé alternative pour la table AFFAIRE, mais c’est la paire {EntiteId, AffaireId} qui est clé primaire.
A noter encore l’emploi de l’identification relative pour la table AFFAIRE : ceci permet d’empêcher d’attribuer des droits à un salarié sur des affaires qui ressortissent à une entité avec laquelle il n’est pas en relation (contrainte de chemin). Si on utilise l’identification absolue (clé primaire = {AffaireId}), une assertion ou un trigger devra garantir la contrainte.
Pour éviter des redondances, en toute rigueur on devrait garantir par assertion ou trigger qu’un admin ne figure pas dans la table RESP_AFFAIRE et qu’un directeur d’une entité ne figure dans cette table qu’en relation avec les entités dont il n’est pas directeur mais simple responsable d’affaire.
Diagramme hypothétique (à aménager en fonction des précisions que vous apporterez)
En passant, vous avez oublié de répondre aux questions posées l’an dernier, espérons qu’il y aura du mieux cette fois-ci... Et en repassant, disons que votre requête aurait gagné à être décorée d’un « s’il vous plaît » et/ou « merci ». Je suppose qu'il s'agit d'un simple oubli...
Partager