Discussion :

[alas70]

Bonjour à tous, je vous envoie ce petit mail car je ne suis pas un expert en base de donnée et la j'avoue que je bloque un peu

Alors voici mon problème :

J'ai une administration a faire (en php et mysql ) dans cette administration je vais avoir 3 types de personnes qui pourront y accèder au moyen d'un login et d'un mot de passe.

Super Admin
Manager
Commerciale

Voici les 3 niveaux, le super admin peut avoir un accès sur toute l'administration
tandis que le manager peut avoir un accès sur ses ventes (oui car il s'agit de vente ) ainsi que sur les ventes DE SES COMMERCIAUX

Sachant q'un manager possède un ou plusieurs commerciaux, je vais devoir avoir 2 tables d'authentification ou est t'il possible de garder une seule table d'authentification. Comment faire si j'ai 2 tables, je vais devoir faire mon authentification a chaque fois sur les 2 tables.

Je suis un peu perdu merci pour votre aide

[CinePhil]

Avant de parler de construire des tables, modélisons les données...

je vais avoir 3 types de personnes

Règles de gestion possibles :
1) Une personne est d'un seul type et un type peut recouvrir plusieurs personnes
2) Une personne est de un à plusieurs types et un type peut recouvrir plusieurs personnes

MCD possibles découlant des règles de gestion précédentes :
1) type -0,n----recouvrir----1,1- personne

2) type -0,n----recouvrir----1,n- personne

Tables qui découlent des schémas précédents :
1) type (ty_id, ty_nom)
personne (prs_id, prs_id_type, prs_nom, prs_prenom, prs_login, prs_mot_passe...)

2) type (ty_id, ty_nom)
personne (prs_id, prs_nom, prs_prenom, prs_login, prs_mot_passe...)
personne_type (pt_id_personne, pt_id_type)

À vous de choisir la bonne règle de gestion et le schéma et les tables qui en découlent.

Il n'y aura donc bien sûr qu'un login.

le super admin peut avoir un accès sur toute l'administration
tandis que le manager peut avoir un accès sur ses ventes (oui car il s'agit de vente ) ainsi que sur les ventes DE SES COMMERCIAUX

Après pour la gestion des accès, si c'est une option de menu accessible ou pas selon le type de la personne, ça peut se faire directement dans le code de l'application.
Si les droits d'accès sont plus complexes (lecture ou écriture, à certains objets et pas à d'autres, création, modification suppression...), ça peut se modéliser aussi dans la base de données mais il faudrait en dire plus. La démarche de réflexion est en tout cas la même que ci-dessus : règle de gestion puis MCD puis tables. Ou si vous utilisez un logiciel de modélisation, ce que je vous conseille fortement, génération d'un MLD à partir du MCD puis génération des tables à partir du MLD vérifié et complété.

Sachant q'un manager possède un ou plusieurs commerciaux

Managers et commerciaux sont tous des personnes.
S'ils ont des attributs spécifiques, on peut mettre en oeuvre un héritage.

MCD :
commercial -(1,1)----être----0,1- personne
manager -(1,1)----être----0,1------------|

Tables :
commercial (cm_id_personne, cm_attributs_spécifiques_du_commercial)
manager (man_id_personne, man_attributs_spécifiques_du_manager)
Ici, la clé primaire de la table est aussi clé étrangère par identification relative à l'entité mère 'personne'.

Dès lors, il devient facile de modéliser l'association entre manager et commercial :
manager -1,n----encadrer----1,1- commercial

Ce qui donne une clé étrangère supplémentaire dans la table commercial :
commercial (cm_id_personne, cm_id_manager, cm_attributs_spécifiques_du_commercial)

[alas70]

Tout d'abord merci pour la réponse, il est vrai que j'ai lu a 2 reprises avant de tout comprendre

Alors voici une solution que j'ai essayer de faire par rapport a ce que vous m'avez dit.

Si je fais 3 tables

une table UTILISATEUR
une table NIVEAU ACCES
une table CORRESPONDANCE

La table utilisateur aura toutes les données de type nom, prenom, login, mdp
la table niveaux accès va lister mes 3 niveaux possibles ( admin, manager commercial )
et la table correspondance va être le lien entre les 2 tables précédentes c'est à dire

TABLE CORRESPONDANCES
--------------------------
ID_ACCES (1,2,3) [1=admin, 2=manager, 3=commercial]
ID_UTILISATEUR_1 (qui correspond a l'identifiant admin )
ID_UTILISATEUR_2 ( qui correspondra a l'identifiant manager)
ID_UTILISATEUR_3 (qui correspondra a l'identifiant commercial)

Si l'utilisateur est un admin alors la table correspondance aura comme entré ID_ACCES et ID_UTILISATEUR_1 (ayant comme valeur ID_ITILISATEUR ), ID_ITILISATEUR_2 et 3 ayant des valeurs = 0

Si l'utilisateur est un manager alors seul les champs ID_ACCES et ID_UTILISATEUR_2 seront remplis les autres champs ayant une valeur null.

Si l'utilisateur est un commerciale alors les champs
ID_ACCES, ID_UTILISATEUR_2 et ID_UTILSATEUR_3 auront une valeur, le champ ID_UTILISATEUR_1 étant null.


Ainsi je peux faire mon identification sur une seule table (table utilisateur) et pour faciliter la requete sur la table utilisateur je peux egalement ajouter dans celle-ci le niveau d'accès.

Ce qui va me donner IDENTIFICATION je vais interoger ma base de données avec login et mot de passe, je récupère le niveau d'accès ainsi que l'identifiant utilisateur. Avec ses deux données je vais interroger ma table CORRESPONDANCE pour obtenir si l'utilisateur est un manager tous les commerciaux qui lui sont affilier ( SELECT FROM CORRESPONCE WHERE ID_ITILUSATEUR_2 = ID_UTILISATEUR )

J'espère que je me suis bien expliqué

[CinePhil]

une table UTILISATEUR
une table NIVEAU ACCES
une table CORRESPONDANCE

Jusque là, ça va !

TABLE CORRESPONDANCES
--------------------------
ID_ACCES (1,2,3) [1=admin, 2=manager, 3=commercial]
ID_UTILISATEUR_1 (qui correspond a l'identifiant admin )
ID_UTILISATEUR_2 ( qui correspondra a l'identifiant manager)
ID_UTILISATEUR_3 (qui correspondra a l'identifiant commercial)

Si l'utilisateur est un admin alors la table correspondance aura comme entré ID_ACCES et ID_UTILISATEUR_1 (ayant comme valeur ID_ITILISATEUR ), ID_ITILISATEUR_2 et 3 ayant des valeurs = 0

Si l'utilisateur est un manager alors seul les champs ID_ACCES et ID_UTILISATEUR_2 seront remplis les autres champs ayant une valeur null.

Si l'utilisateur est un commerciale alors les champs
ID_ACCES, ID_UTILISATEUR_2 et ID_UTILSATEUR_3 auront une valeur, le champ ID_UTILISATEUR_1 étant null.

Là par contre, c'est nettement moins bon !

Pourquoi ne pas avoir gardé la structure proposée dans mon message :

type (ty_id, ty_nom)
personne (prs_id, prs_nom, prs_prenom, prs_login, prs_mot_passe...)
personne_type (pt_id_personne, pt_id_type)

Je développe avec des données...

Contenu de la table 'type' (chez vous NIVEAU_ACCES) :
ty_id / ty_nom
1 / 'admin'
2 / 'manager'
3 / 'commercial'

Contenu de la table 'personne' (chez vous UTILISATEUR) :
prs_id / prs_nom / prs_prenom / prs_login / prs_mot_passe
1 / 'Leménager' / 'Philippe' / 'CinePhil' / 'xyz123'
2 / 'Dupont' / 'Jean' / 'BigBoss' / 'abdcde'
3 / 'Durand' / 'Jacques' / 'Costard' / 'jhgjhg'
4 / 'Dugenou' / 'Paul' / 'Cravate' / 'dfgfjolmù'

Contenu de la table personne_type :
pt_id_personne / pt_id_type
1 / 1
2 / 2
2 / 3
3 / 3
4 / 3
Le manager Jean Dupont est aussi commercial dans cet exemple.

Quels sont les types (niveaux d'accès) de l'utilisateur qui se connecte avec le login 'BigBoss' ?

Code SQL :

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

1
2
3
4
5
SELECT t.ty_id, t.ty_nom
FROM type AS t
INNER JOIN personne_type AS pt ON pt.pt_id_type = t.ty_id
  INNER JOIN personne AS p ON p.prs_id = pt.pt_id_personne
WHERE p.prs_login = 'BigBoss'

Je continue avec ma structure :

commercial (cm_id_personne, cm_id_manager, cm_attributs_spécifiques_du_commercial)
manager (man_id_personne, man_attributs_spécifiques_du_manager)

Quels sont les commerciaux encadrés par le manager 'BigBoss' ?

Code SQL :

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

1
2
3
4
5
6
SELECT p1.prs_nom, p1.prs_prenom
FROM personne AS p1
INNER JOIN commercial AS c ON c.cm_id_personne = p1.prs_id
  INNER JOIN manager AS m ON m.man_id_personne = c.cm_id_manager
    INNER JOIN personne AS p2 ON p2.prs_id = m.man_id_personne
WHERE p2.prs_login = 'BigBoss'

[alas70]

OK, je comprend mieux maintenant avec les exemples , c'est vrai que votre solution va faciliter la programmation au niveau de la gestion des accès. Ce qui est interressant dans tout cela c'est le fait d'avoir un "double statut" pour le manager qui peut également avoir un rôle commercial le petit hic c'est que au niveau programmation pour avoir ce double statut je vais devoir faire une double insertion sur une même table.

J'avoue que j'avais du mal avec les requetes du type INNER JOIN mais avec les exemples cela devient bcp plus compréhensible pour moi ( sachant que j'etais rester au niveau basique des requètes du type SELECT WHERE FROM )

Un grand merci pour votre aide et réactivité !! Je vais maintenant pouvoir avancer dans ma conception de bdd.