Discussion :

[xnopre]

Bonjour,

J'ai une application qui travaille avec une base de données ayant plusieurs tables. Mon application va être utilisée par plusieurs groupes distincts de personnes.

Solution 1 : plusieurs instances de mon appli et plusieurs BDD avec la même structure, mais dans chaque BDD, les données d'un groupe

Solution 2, si ça existe : une seule instance de mon appli, une seule BDD, mais un moyen de spécifier l'ensemble des enregistrements qui concerne l'utilisateur courant.

C'est possible ? Il me semble qu'il y a une notion comme ça, mais impossible de retrouver ....

Merci pour votre aide,

Xavier

[CinePhil]

Si je comprends bien, tu as l'une des règles de gestion suivantes :
1) Un utilisateur appartient à un seul groupe et un groupe peut comprendre plusieurs utilisateurs.
2) Un utilisateur appartient à un ou plusieurs groupes et un groupe peut comprendre plusieurs utilisateurs.

Ce qui donne les MCD (methode Merise) suivants :
1) utilisateur -1,1----appartenir----0,n- groupe
2) utilisateur -1,n----appartenir----0,n- groupe

Il en découlera dans ta BDD les tables suivantes :
1)
groupe (grp_id, grp_nom...)
utilisateur (uti_id, uti_id_groupe, uti_nom...)

2)
groupe (grp_id, grp_nom...)
utilisateur (uti_id, uti_nom...)
uti_appartenir_grp (uag_id_utilisateur, uag_id_groupe)

Ensuite, tu peux avoir une notion de droits attribués aux groupes, selon le schéma suivant :
groupe -1,n----bénéficier----0,n- droit

Ce qui donne les tables :
droit (drt_id, drt_libelle...)
grp_beneficier_drt (gbd_id_groupe, gbd_id_droit)

[tatayo]

Bonjour,
Si je comprends bien la question, au lieu de donner des droits sur les tables de la base, crée des vues et donnes les droits qui vont bien sur les vues. Ainsi les utilisateurs ne peuvent voir que les enregistrements renvoyés par les vues sur lesquelles ils ont un droit de lecture.

Tatayo.

[xnopre]

Bonjour Philippe,

En fait, ma question ne porte pas sur la gestion des utilisateurs, groupes et droits, ça, ça n'est pas un problème.

Je cherche à "cloisonner" les autres données (enregistrements) de la base selon l'utilisateur connecté.

Je vais essayer de prendre un exemple. Imaginons une application qui permet de gérer des événements pour une association. Chaque utilisateur appartient à une association et ne doit voir que les événements de sons association.

Bien sûr, je pourrais le faire en liant chaque événement à une association et en faisant des requêtes selon l'association de l'utilisateur en cours. Mais mon application comporte de nombreuses tables, et ça alourdi considérablement ...

Mais je me demande s'il n'y a pas une fonctionnalité plus "forte" dans les base de données permettant de définir un système de "domaine" (c'est le mot qui me vient mais je ne suis pas sûr que ce soit le bon), permettant de filtrer les enregistrements de toutes les tables de façon assez transparente (sans les avoir dans toutes les requêtes).

J'espère être un peu plus clair ...

Merci

Xavier

[xnopre]

Bonjour Tatayo,

Tous les utilisateurs ont accès aux mêmes vues. Ils utilisent la même application mais avec des jeux de données différents. Et je cherche à éviter de dupliquer mon application en plusieurs instance connectées à autant de bases de données ...

Merci

Xavier

[CinePhil]

Il faut que ton modèle de données prenne en compte cette séparation par groupe si tu veux que la même application interrogeant une seule BDD soit accessible pour tous les groupes.

En complément de mon MCD, l'entité type groupe sera associée à au moins une autre entité type du reste du MCD, laquelle sera à son tour associée à au moins une autre entité type...
Ainsi, en connaissant l'utilisateur, on connaît son groupe et on peut filtrer les données des tables issues du reste du schéma en fonction du groupe de l'utilisateur.

Pour reprendre ton exemple de plusieurs associations, chaque utilisateur représentant une association pourrait voir la liste de ses adhérents mais pas les adhérents de l'association d'à côté.

MCD :
utilisateur -1,1----appartenir----0,n- association -0,n----avoir----1,1- adherent

Tables :
association (ass_id, ass_nom...)
utilisateur (uti_id, uti_id_association, uti_nom...)
adherent (adh_id, adh_id_association, adh_nom, adh_prenom...)

Si je suis utilisateur de l'association 'ATB', je n'ai accès qu'aux membres de l'ATB avec cette requête :

Code SQL :

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

1
2
3
4
5
6
SELECT adh.adh_nom, adh.adh_prenom
FROM adherent adh
INNER JOIN association ass ON ass.ass_id = adh.adh_id_association
    INNER JOIN utilisateur u ON u.uti_id_association = ass.ass_id
WHERE u.uti_nom = 'CinePhil'
ORDER BY adh.adh_nom, adh.adh_prenom

[xnopre]

Re-bonjour Philippe,

Grand merci pour tes réponses rapides.

Encore une fois, gérer cela au travers de tables et de liens entre ces tables n'est pas un problème pour moi. Ma question est de savoir s'il n'y a pas une solution plus global au SGBD permettant en quelque sorte de lui dire "maintenant, pour cette session, je veux travailler sur cet ensemble de données, quelque soit les tables". Il me semble que ça existe. J'avais en tête la notion de "domaine", mais je crois que ça n'est pas le bon terme ....

Merci

Xavier

[CinePhil]

À ma connaissance non et à mon avis c'est plus simple de le modéliser que de le gérer hors SQL. Mais je ne connais que MySQL (assez bien), Postgresql (moins ben), Access (vielle version, vieux souvenirs), Open Office Base (assez peu) alors peut-être que d'autres SGBD savent faire ce genre de truc en quelques clics mais moi pas savoir.

[xnopre]

Bon, je viens d'avoir un collègue en ligne, spécialiste base de données, à qui ça ne dit rien ...

J'ai du rêvé, dommage ...

En tout cas, merci pour vos réponses !

Xavier

[Richard_35]

Bonjour Xnopre et CinePhil,

En final, deux cas :

• les tables sont, physiquement, les mêmes pour tous les "domaines" : pour des raisons évidentes de maintenance, c'est la solution la plus efficiente. L'ajout d'un champ est immédiatement valide pour tous les "domaines".
  Par exemple, les progiciels comptables qui gèrent plusieurs sociétés (plusieurs "domaines", donc), intègrent dans toutes les tables, le n° de la société. La navigation, dans une société, ne dérive pas dans une autre société, sauf si l'utilisateur veut changer de société.
  ==> la solution de CinéPhil convient parfaitement à ce cas.
  
  
• les tables ne sont pas, physiquement, les mêmes (stockées à des endroits différents, donc). L'ajout d'un champ devra s'effectuer à tous les endroits de stockage.
  La problématique devient donc de "variabiliser" le chemin pour arriver aux bonnes tables suivant un paramètre d'entrée. Cela dépend donc des systèmes :
  
  • répertoires, serveurs, etc... (orientation "physique") ;
  • bases de données (orientation "logique"). Par exemple, sous SQL Server, il peut y avoir plusieurs bases de données (dans le "même SQL Server"). Je suppose que l'ouverture des tables de l'une ou de l'autre doit être paramétrable : le forum SQL Server pourrait nous donner facilement la réponse.
  
  ==> la question est donc de "variabiliser" l'accès logique aux tables.