Discussion :

[cfried]

Bonjour à tous,

Malgré mes recherches je ne trouve pas ce que je cherche.

J'ai conçu une base qui évolue avec le temps et avec les besoins ...

La problématique c'est que j'ai :
- une table d'utilisateurs de 3000 lignes ;
- une table de pays
- une table de sites
- une table de services
- une table d'applications
- une table de niveau d'accès (root, user, ...)

Maintenant j'ai déjà des choses en place pour donner des droits à des utilisateurs mais je voudrais optimiser la chose. Je voudrais :
- Pouvoir définir des droits pour une application directement à un pays qui cascade sur les sites puis sur les services puis sur les utilisateurs.
- Pouvoir définir des droits pour une application mais au niveau spécifique site
- Pouvoir définir des droits pour une application mais au niveau spécifique service
- Pouvoir définir des droits pour une application mais au niveau spécifique user

Sachant qu'un user peut être dans plusieurs service (table associative) et même dans plusieurs sites (un service a un et un seul site et un site a un et un seul pays)

Mon idée est de jouer avec des triggers mais j'avoue que je me sens un peu faible face à cette "grosse" problématique et je ne suis pas contre vos idées, si vous avez déjà rêvé de faire la même chose.

Toute suggestion est bonne à prendre

Merci d'avance de m'avoir lu !

[Richard_35]

Bonjour Cfried,

Plusieurs précisions (en rouge) :

- Pouvoir définir des droits pour une application directement à un pays qui cascade sur les sites puis sur les services puis sur les utilisateurs.
==> OK
- Pouvoir définir des droits pour une application mais au niveau spécifique site
==> dans l'ensemble des droits accordés au pays, ou accorder des droits aux sites sans que ceux-ci soient accordés au pays "père" ?
- Pouvoir définir des droits pour une application mais au niveau spécifique service
==> dans l'ensemble des droits accordés au pays et au site, ou accorder des droits aux services sans que ceux-ci soient accordés au pays/site "père" ?
- Pouvoir définir des droits pour une application mais au niveau spécifique user
==> dans l'ensemble des droits accordés au pays, au site et au service ou accorder des droits aux users sans que ceux-ci soient accordés au pays/site/service "père" ?

[cfried]

Bonjour Cfried,
Plusieurs précisions (en rouge) :

Envoyé par Cfried
- Pouvoir définir des droits pour une application directement à un pays qui cascade sur les sites puis sur les services puis sur les utilisateurs.
==> OK
- Pouvoir définir des droits pour une application mais au niveau spécifique site
==> dans l'ensemble des droits accordés au pays, ou accorder des droits aux sites sans que ceux-ci soient accordés au pays "père" ?
- Pouvoir définir des droits pour une application mais au niveau spécifique service
==> dans l'ensemble des droits accordés au pays et au site, ou accorder des droits aux services sans que ceux-ci soient accordés au pays/site "père" ?
- Pouvoir définir des droits pour une application mais au niveau spécifique user
==> dans l'ensemble des droits accordés au pays, au site et au service ou accorder des droits aux users sans que ceux-ci soient accordés au pays/site/service "père" ?

Bonjour Richard, merci de vous intéresser à mon problème.

Pour vous répondre, je voudrais que "par défaut" les droits des sites soient ceux du pays père, les droits des services soient ceux du site père et les droits des utilisateurs soient ceux du service père MAIS que l'on puisse définir des exceptions qui n'aient pas d'impact sur les droits par défaut.

Est-ce que c'est plus clair pour vous ?

[Richard_35]

Bonjour Cfried,

Est-ce que c'est plus clair pour vous ?

==> oui.

Autre précision :

Sachant qu'un user peut être dans plusieurs service (table associative) et même dans plusieurs sites .../...

==> "et même dans plusieurs sites" : à l'intérieur d'un service ?
Autrement dit, il n'existe pas de relation directe entre un user et un site sans passer par un service ?

D'autre part, possèdes-tu un outil de modélisation ?

[cfried]

Bonjour Cfried,

==> oui.

Autre précision :
==> "et même dans plusieurs sites" : à l'intérieur d'un service ?
Autrement dit, il n'existe pas de relation directe entre un user et un site sans passer par un service ?

D'autre part, possèdes-tu un outil de modélisation ?

Vous avez bien compris, un user est en relation directe avec un/des service(s) et ceux ci ont un et un seul site (donc indirectement il est possible que des users travaillent dans plusieurs sites et même dans plusieurs pays car un service a un et un seul pays).

Pour l'outil de modélisation je pourrais faire un reverse-engineering de ma base avec Open-ModelSphere ... ou même MySQL WorkBench ...
Vous voudriez voir à quoi ça ressemble ?
Mes bases sont faites sur MySQL avec InnoDB comme moteur.

[Richard_35]

OK.

Pour l'outil de modélisation je pourrais faire un reverse-engineering de ma base avec .../...

==> pourquoi ne pas faire de l'engineering tout court ?

Il vaut mieux passer, d'abord, par un MCD qui générera, ensuite un MLD (la structure des tables), et non l'inverse.

Vite fait, dans un premier temps, une partie du MCD :



==> qui entraîne une question pour la suite : faut-il prévoir des droits aux users (entité User) et/ou aux couples user/service (table associative Composer) ?

[cfried]

OK.

==> pourquoi ne pas faire de l'engineering tout court ?

Il vaut mieux passer, d'abord, par un MCD qui générera, ensuite un MLD (la structure des tables), et non l'inverse.

Vite fait, dans un premier temps, une partie du MCD :



==> qui entraîne une question pour la suite : faut-il prévoir des droits aux users (entité User) et/ou aux couples user/service (table associative Composer) ?

Une étude basée sur un MCD a été faite par mes soins lors de la création de la base mais nous n'avions pas les mêmes besoins qu'aujourd'hui. Je vais devoir la faire évoluer sans tout casser (diverses applications se basent déjà dessus).

La base est faite exactement comme vous l'avez modélisé à la différence près qu'il n'y a pas de contrainte 'un utilisateur a au moins un service' car lors de la création de l'user, on ne connait pas forcément son service de destination. On a donc une cardinalité possiblement nulle de ce côté (en gros il n'y a pas forcément d'occurrence de membre_service à la création du membre).

Pour répondre à votre dernière question, on ne peut envisager de donner les droits sur l'association membre/service qu'à la condition qu'on ai une règle de type :
"l'utilisateur a les droits max de l'ensemble de ses droits" (pour une application)
J'en viens donc à la table applications : un utilisateur peut être root sur l'application1 et user sur l'application2. Il peut même avoir un accès refusé sur l'application3.
Le nombre d'applications évoluant au cours du temps je ne peux pas me permettre que ce soit une colonne de la table associative membre_service. Il faut une solution simple en maintenance.

Ce que j'ai pensé de plus simple était une table associative :
membre_app_droit

Mais cette solution nécessiterait une table associative :
service_app_droit

Qui entraîne elle même une table associative :
site_app_droit

et ainsi de suite avec :
pays_app_droit

Ce qui fait que quand on ajoute un membre à un service, un trigger viendrait ajouter automatiquement une ligne à membre_app_droit en fonction du droit du service et ainsi de suite. C'est son droit par défaut et on a la possibilité de le modifier plus tard.

Pour que je me fasse bien comprendre, un autre exemple ...

J'ajoute un service à un site (donc une occurrence de service, qui a obligatoirement un site). Lors de l'ajout du site, un trigger viendrait checker le
site_app_doit correspondant pour ajouter à service_app_droit les lignes qu'il faut.

Qu'en pensez vous ?

En tous cas merci de me lire et bonne journée

[Richard_35]

Bonjour Cfried,

.../... à la différence près qu'il n'y a pas de contrainte 'un utilisateur a au moins un service' .../...

==> OK, modifié :

.../...
Qu'en pensez vous ?

==> compliqué, me semble-t-il. Suggestion : passer par une sorte de catalogue des droits possibles et affecter une occurrence de ce catalogue aux niveaux souhaités. Cela donnerait :

J'ai "éclaté" volontairement les relations n,n pour plus de clarté.
L'affectation aux niveaux souhaités consiste à "brancher" cette partie du MCD à la première partie en affectant un n° de liste de droits au niveau en question (NB : une même liste de droits pourra servir plusieurs fois).

[cfried]

J'avoue ne pas comprendre où vous voulez en venir avec votre dernier MCD et le catalogue de droits dont vous parlez. (les relations n-aires extraites m'embrouillent ).

Nous avons fait un brainstorming avec quelques collègues et ma proposition de cascader des triggers ne sera pas conservée pour une raison simple : donner des droits "par défaut" est dangereux.

Nous allons donc identifier des responsables par service qui déclareront leurs utilisateur sur les applications auxquelles ils auront eux même le droit et pas plus, et ce via un outil approprié.

Au final, on aura au maximum une table service_app_droit et une autre membre_app_droit (qui sera bien remplie mais qui permettra de gérer toutes les exceptions ... genre secrétaire qui fait le boulot de son chef et qui doit avoir accès à des applis ... etc).

Maintenant je réfléchis à la façon de modéliser des settings particulier pour chaque user/app et je vais créer une discussion pour ça.

[Richard_35]

Bonjour Cfried,

J'avoue ne pas comprendre où vous voulez en venir avec votre dernier MCD et le catalogue de droits dont vous parlez.

==> exemple :

Droit(IdDroit, Nom, ...)

Code :

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

1
2
3
IdDroit  Nom
1        Root
2        User

Application(IdApplication, Nom, ...)

Code :

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

1
2
3
4
IdApplication  Nom
12             Logistique
25             Commercial
105            Facturation

La liste de droits n° 108 concerne les applications "Logistique" et "Commercial" (mais pas l'application "Facturation") :
ListeDroit(IdListeDroit, ...)

Code :

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

1
2
IdListeDroit
108

ListeDroit_DetailApplication(IdListeDroit, IdApplication, ...)

Code :

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

1
2
3
IdListeDroit  IdApplication
108           12
108           25

La liste de droits n° 108 concerne les applications "Logistique" avec les droits "Root"et "User" ainsi que l'application "Commercial" avec les droits "User" :
ListeDroit_DetailApplication_Droit(IdListeDroit, IdApplication, IdDroit, ...)

Code :

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

1
2
3
4
IdListeDroit  IdApplication  IdDroit
108           12             1
108           12             2
108           25             2

Nous affectons la liste de droits n° 108 au pays "Allemagne" :
Pays(IdPays, Nom, ...)

Code :

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

1
2
3
IdPays  Nom
7        France
9        Allemagne

Pays_ListeDroit(IdPays, IdListeDroit, ...)

Code :

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

1
2
IdPays  IdListeDroit
9       108

Cela permet de centraliser une liste de droits à un "endroit" unique (n° 108) et, par conséquent, de faciliter l'attribution de cette liste aux niveaux souhaités.

[cfried]

Bonjour Richard et merci de suivre mon cas encore une fois ^^

Je comprends mieux avec des exemples et en l'occurrence ça n'est pas exactement ce que je cherche car dans votre cas la "liste" de droits 108 aurait plusieurs droits pour la même application.

ListeDroit_DetailApplication(IdListeDroit, IdApplication, ...)

Code :

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

1
2
3
IdListeDroit  IdApplication
108           12
108           25

La liste de droits n° 108 concerne les applications "Logistique" avec les droits "Root"et "User" ainsi que l'application "Commercial" avec les droits "User" :
ListeDroit_DetailApplication_Droit(IdListeDroit, IdApplication, IdDroit, ...)

Code :

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

1
2
3
4
IdListeDroit  IdApplication  IdDroit
108           12             1
108           12             2
108           25             2

Je ne veux pas qu'il y ai d’ambiguïté au final mais l'idée de catalogue n'est pas mauvaise car elle élimine un maximum de doublons d'association de droits (il n'y aurait au final qu'un produit cartésien des applications et des droits comme possibilités de catalogue différents).

Le seul problème que je vois à cette solution c'est qu'il faudrait modifier tous les catalogues à chaque ajout d'application (ou découverte d'un nouveau niveau de droits).

Pour résumer je garderais seulement une table "CATALOGUE" avec :

CATALOGUE_ID
CATALOGUE_APP
CATALOGUE_DROIT

et ça m'évite de faire une table membre_app_droit et service_app_droit. J'aurais juste une colonne MEMBRE_CATALOGUE et SERVICE_CATALOGUE avec une contrainte de clé étrangère sur CATALOGUE_ID.

[Richard_35]

en l'occurrence ça n'est pas exactement ce que je cherche car dans votre cas la "liste" de droits 108 aurait plusieurs droits pour la même application.

==> en remplaçant :

ListeDroit_DetailApplication_Droit(IdListeDroit, IdApplication, IdDroit, ...)

par

ListeDroit_DetailApplication_Droit(IdListeDroit, IdApplication, IdDroit, ...)

il n'y a plus qu'un seul droit possible par couple IdListeDroit/IdApplication.


Il s'agit, là, d'une base de travail à adapter. L'idée générale est de centraliser une liste de droits à un "endroit" unique.