Discussion :

[moimp]

Bonjour,
J'ai un site avec différentes parties et plusieurs utilisateurs, avec chacun des droits d'accès. Il s'agit plutôt d'une application.
J'ai besoin de conseils pour structurer ma table d'attribution des droits d'accès.
Je me demande comment structurer la table de gestion des droits 'dat_rights'.
Je voudrais 3 colonnes id_user / parts / right avec un index unique sur les deux premières colonnes.
La colonne right peut prendre les valeurs 1, 2 ou 3.
Faut-il créer une clef primaire distincte? Ou peut-on en créer une sur deux colonnes?
Les différentes parties sont à priori fixes et peuvent être enregistrées en base de données ou dans le code du site. L'application comprend 17 parties distinctes.

[escartefigue]

Bonjour

Il ne faut pas réfléchir sur les tables, les colonnes et les index avant d'avoir établi clairement ce qu'on a besoin de faire
Autrement dit, il faut décrire le "QUOI" avant le "COMMENT"

• un utilisateur bénéficie-t-il d'un et un seul type de droits ? De plusieurs ? Voire d'aucun ?
• les droits sont ils spécifiques à chaque utilisateur ou bien sont ils partagés par des groupes d'utilisateurs

En fonction des réponses, la modélisation diffère.
Le modèle le plus classique consiste à attribuer les droits non pas à chaque utilisateur, mais à des profils, chaque utilisateur étant associé, à date, à un profil. Ce qui permet de simplifier la gestion des droits (inutile de le faire pour chaque utilisateur). Ces profils sont ensuite associés à des fonctions.

Par exemple :
un profil administrateur de compte client aura droit aux fonctions créer, modifier, visualiser et clôturer un compte client
un profil gestionnaire de compte client aura droit aux fonctions modifier et visualiser un compte client et aux fonctions créer, modifier et visualiser les commandes client.

Ce qui donne le MCD suivant (notez l'entité-type fictive "CA_calendrier" qui ne sert qu'à faire participer la date comme composante des deux associations elle ne deviendra pas une table, ce serait inutile) :

Note : on peut ajouter une date de fin de validité dans chacune des associations

Et le MLD correspondant :


Soit le script suivant pour MySQL :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
CREATE TABLE UT_utilisateur(
   UT_ident INT AUTO_INCREMENT,
   UT_nom VARCHAR(50) NOT NULL,
   UT_prenom VARCHAR(50) NOT NULL,
   UT_courriel VARCHAR(64),
   PRIMARY KEY(UT_ident)
);
 
CREATE TABLE PR_profil(
   PR_ident INT AUTO_INCREMENT,
   PR_code CHAR(4) NOT NULL,
   PR_nom VARCHAR(50) NOT NULL,
   PR_debval DATE NOT NULL,
   PR_finval DATE NOT NULL,
   PRIMARY KEY(PR_ident),
   UNIQUE(PR_code)
);
 
CREATE TABLE FC_fonction(
   FC_ident INT AUTO_INCREMENT,
   FC_code CHAR(6) NOT NULL,
   FC_libelle VARCHAR(50) NOT NULL,
   FC_debval DATE NOT NULL,
   FC_finval DATE NOT NULL,
   PRIMARY KEY(FC_ident),
   UNIQUE(FC_code)
);
 
CREATE TABLE UP_ut_profil(
   UT_ident INT,
   PR_ident INT,
   CA_date DATE,
   PRIMARY KEY(UT_ident, PR_ident, CA_date),
   FOREIGN KEY(UT_ident) REFERENCES UT_utilisateur(UT_ident),
   FOREIGN KEY(PR_ident) REFERENCES PR_profil(PR_ident)
);
 
CREATE TABLE HA_habiliter(
   PR_ident INT,
   FC_ident INT,
   CA_date DATE,
   PRIMARY KEY(PR_ident, FC_ident, CA_date),
   FOREIGN KEY(PR_ident) REFERENCES PR_profil(PR_ident),
   FOREIGN KEY(FC_ident) REFERENCES FC_fonction(FC_ident)
);

[moimp]

En fait, j'ai des catégories hybrides.
La catégorie 1 comprend les webmasters qui ont accès à tout.
La catégorie 2 comprend les administrateurs de l'application. Ce sont eux qui gèrent les droits des utilisateurs de la catégorie 3.
A l'intérieur de ces catégories les droits sont les mêmes, donc c'est simple à partir des modèles proposés.
La catégorie 3 comprend les utilisateurs normaux. Là, chaque utilisateur peut avoir des droits d'accès différents pour chaque page ou fonctionnalité, ce qui reviendrait à créer presque autant de catégories que d'utilisateurs, d'où mon idée de créer une table associative avec 3 colonnes: id_user, page, rights. La dernière colonne contiendrait 3 niveaux (accès interdit, lecture seule, lecture/édition). La encore, on peut scinder l'édition en création, modification, suppression.

[escartefigue]

Si chaque utilisateur ni webmaster ni administrateur peut avoir des droits différents, il suffit d'ajouter une 3eme asso ternaire entre utilisateur, calendrier et fonctions.
On ajoutera éventuellement une contrainte d'exclusion entre cette nouvelle association et celle que j'ai appelée UP_ut_profil si on veut que les droits d'un même utilisateur passent soit par un profil, soit par des attributions directes de fonctions, mais pas un mélange des deux.