IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Agents et sous-agents dans la même table [MCD]


Sujet :

Schéma

  1. #1
    Membre éprouvé
    Avatar de beegees
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2004
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 610
    Points : 1 277
    Points
    1 277
    Par défaut Agents et sous-agents dans la même table
    Bonjour à tous,

    J'ai une table qui contient des agents commerciaux :

    ID (auto incrément)
    Nom
    Prenom
    Email

    J'ai aussi des sous-agents qui dépendent directement des agents commerciaux, c'est-à-dire qu'un sous-agent est géré par 1 et un seul agent mais qu'un agent peut gérer plusieurs agents.

    Ma question :

    Est-il nécessaire de créer une seconde table pour les sous-agents ?

    Les deux tables (agents commerciaux et sous-agents) sont identique à l'exception d'un champ id_agent dans la table sous-agents.

    Est-ce que cette table sous-agent est indispensable ?

    Je pensais mettre les agents et les sous-agents dans la même table, mais il faudra indiquer qu'un sous agent est géré par un agent de la même table.

    Comment vériez-vous cela ? Réflexive ?

    Je vous remercie d'avance.

    beegees

  2. #2
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour Beegees,

    Citation Envoyé par Beegees
    Réflexive ?
    ==> Oui, à mon sens.


    Personnellement, je ne créerais qu'une seule table. Donc :
    Agent
    - ID (PK, auto incrément)
    - Nom
    - Prenom
    - Email
    - Id_Manager
    ...

    Et donc :
    Agent ---(0,n)---[manage/est managé par]---(0,1)--- Agent
    ==> d'où l'apparition du fameux "bonhomme null"... mais, à mon sens, pas réellement gênant.

    Dans la fiche de l'agent, une liste déroulante devra être disponible pour choisir le manager (liste excluant l'agent sur lequel nous sommes...), et non obligatoire.

    Ensuite, nous pouvons nous poser la question : un agent manager possède-t-il des attributs particuliers que n'auraient pas un agent non-manager ? (par exemple, une date de contrat de passage en manager).

    Eh bien, même dans ce cas, il me semble qu'une table unique regroupant les informations communes reste judicieuse. En revanche, il faut isoler les attributs des managers dans une table spécifique. Cela donnerait :
    Manager
    - Id_Manager
    - Numero_contrat_manager
    - Date_passage_en_manager
    ...

    Relation
    Agent ---(1,1)---[a, pour contrat/est le contrat de]---(1,1)---Manager => via Id_Manager.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  3. #3
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    Février 2009
    Messages
    5 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2009
    Messages : 5 220
    Points : 19 452
    Points
    19 452
    Par défaut
    Bonsoir.

    Citation Envoyé par beegees Voir le message
    J'ai une table qui contient des agents commerciaux
    Au niveau conceptuel, on parle d'entité ... mais ce n'est qu'un détails .

    Citation Envoyé par beegees Voir le message
    Est-il nécessaire de créer une seconde table pour les sous-agents ?

    Les deux tables (agents commerciaux et sous-agents) sont identique à l'exception d'un champ id_agent dans la table sous-agents.

    Est-ce que cette table sous-agent est indispensable ?
    Si tu garde une seule et table (au niveau relationnel), cela signifie que ta clef étrangère sera NULL dans certains cas et ce n'est pas propre.

    Une autre solution pourrait être envisagée : un héritage entre l'entité sous-agent et l'entité agent avec une association de type 0,n/1,1 reliant l'entité mère et l'entité fille. Si le SGBD ne gère pas l'héritage, cela peut ce traduire par la création de la relation suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Sous-agent (id_agent#, id_agent_responsable#)
    
    X : relation
    X : clef primaire
    X# : clef étrangère
    Edit :

    Citation Envoyé par Richard_35 Voir le message
    Agent ---(0,n)---[manage/est managé par]---(0,1)--- Agent
    ==> d'où l'apparition du fameux "bonhomme null"... mais, à mon sens, pas réellement gênant.
    Il y a un débat à ce sujet. Beaucoup (dont moi) préfèrent créer une table associative dans le cas d'une cardinalité 0,1 pour éviter le cas d'une clef étrangère à NULL. Au niveau de l'optimisation de l'espace utilisé, tout dépend de la force du 0 ou du 1 de cette cardinalité. Si le 0 revient plus souvent, mieux vaut créer cette table associative ou au contraire si le 1 revient plus souvent, mieux vaut se contenter d'une simple clef étrangère.

    Cordialement,
    Idriss

  4. #4
    Membre éprouvé
    Avatar de beegees
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2004
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 610
    Points : 1 277
    Points
    1 277
    Par défaut
    Citation Envoyé par Richard_35 Voir le message
    Bonjour Beegees,
    Bonjour Richard et merci pour ta réponse,

    ==> Oui, à mon sens.

    Personnellement, je ne créerais qu'une seule table. Donc :
    Agent
    - ID (PK, auto incrément)
    - Nom
    - Prenom
    - Email
    - Id_Manager
    ...
    C'est ce que j'avais pensé au début.

    Et donc :
    Agent ---(0,n)---[manage/est managé par]---(0,1)--- Agent
    ==> d'où l'apparition du fameux "bonhomme null"... mais, à mon sens, pas réellement gênant.
    Je vais donc faire abstraction de ce "bonhomme null", qui me semble pas trop gênant.

    Dans la fiche de l'agent, une liste déroulante devra être disponible pour choisir le manager (liste excluant l'agent sur lequel nous sommes...), et non obligatoire.
    OK, très bon algorithme

    Ensuite, nous pouvons nous poser la question : un agent manager possède-t-il des attributs particuliers que n'auraient pas un agent non-manager ? (par exemple, une date de contrat de passage en manager).
    Non, pas d'autres attributs pour l'agent principal

    Citation Envoyé par ok.Idriss Voir le message
    Bonsoir.
    Bonjour OK.Idriss et merci pour ta réponse.

    Au niveau conceptuel, on parle d'entité ... mais ce n'est qu'un détails .
    Tu as raison

    Si tu garde une seule et table (au niveau relationnel), cela signifie que ta clef étrangère sera NULL dans certains cas et ce n'est pas propre.
    Pas propre mais ça reste acceptable ?

    Une autre solution pourrait être envisagée : un héritage entre l'entité sous-agent et l'entité agent avec une association de type 0,n/1,1 reliant l'entité mère et l'entité fille.
    Pas d'héritage avec MYSQL (il me semble)

    Si le SGBD ne gère pas l'héritage, cela peut ce traduire par la création de la relation suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Sous-agent (id_agent#, id_agent_responsable#)
    
    X : relation
    X : clef primaire
    X# : clef étrangère
    Je ne suis pas sûr de bien comprendre ce que tu me dis ici.

    On crée donc une table supplémentaire qui ne contient que l'id de l'agent principal et l'id du sous-agent ?

    Tout le reste (Nom, Prénom, Email...) pour les deux types d'agents vont dans la première table ?

    Donc, si on a un agent principal, il va dans la première table et pas dans la seconde ?

    Encore merci à vous deux pour l'aide.

    beegees


    Edit :


    Il y a un débat à ce sujet. Beaucoup (dont moi) préfèrent créer une table associative dans le cas d'une cardinalité 0,1 pour éviter le cas d'une clef étrangère à NULL. Au niveau de l'optimisation de l'espace utilisé, tout dépend de la force du 0 ou du 1 de cette cardinalité. Si le 0 revient plus souvent, mieux vaut créer cette table associative ou au contraire si le 1 revient plus souvent, mieux vaut se contenter d'une simple clef étrangère.

    Cordialement,
    Idriss
    Il y aura plus d'agents que de sous-agents (normalement, on ne connaît pas l'évolution de la société).

    Bon Week-End pascal.

  5. #5
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    Février 2009
    Messages
    5 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2009
    Messages : 5 220
    Points : 19 452
    Points
    19 452
    Par défaut
    Citation Envoyé par beegees Voir le message
    Il y aura plus d'agents que de sous-agents (normalement, on ne connaît pas l'évolution de la société).
    Dans ce cas il sera plus optimisé de crée une seconde table comme je l'ai montré ici :

    Citation Envoyé par ok.Idriss Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Sous-agent (id_agent#, id_agent_responsable#)
    
    X : relation
    X : clef primaire
    X# : clef étrangère
    Citation Envoyé par beegees Voir le message
    Pas propre mais ça reste acceptable ?
    MySQL l'acceptera mais puisque l'on peut éviter ceci, pourquoi s'en priver (d'autant que dans ton cas, ça n'optimisera pas l'espace utilisé comme montré précédemment) ?

    Citation Envoyé par beegees Voir le message
    Pas d'héritage avec MYSQL (il me semble)
    En effet, ce SGBD ne gère pas l'héritage mais cet héritage peut être implémenté par la simple création de la relation Sous-agent que j'ai montré précédemment.

    Citation Envoyé par beegees Voir le message
    On crée donc une table supplémentaire qui ne contient que l'id de l'agent principal et l'id du sous-agent ?
    Oui c'est bien ça, ça permettra de savoir qui est dirigé par qui et cela évitera les contraintes de clefs étrangères à NULL.


    Citation Envoyé par beegees Voir le message
    Tout le reste (Nom, Prénom, Email...) pour les deux types d'agents vont dans la première table ?
    Tout à fait. Après, il suffira de faire une jointure sur les identifiants des deux tables dans tes requêtes SELECT.

    Citation Envoyé par beegees Voir le message
    Donc, si on a un agent principal, il va dans la première table et pas dans la seconde ?
    Tout les agents et sous-agent vont dans la première table (Agent). Les sous-agent iront aussi dans la seconde table (Sous-agent) avec la clef étrangère vers les agents principaux.

    Je refais un schéma pour mieux comprendre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Agent (id_agent, nom, prenom, email)
    Sous-agent (id_agent#, id_agent_responsable#)
    
    X : relation
    X : clef primaire
    X# : clef étrangère
    Et voici un jeu d'occurrences pour illustrer :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    Agent :
    
    id_agent ; nom ; prenom ; email
    1 ; beeges ; beeges ; beeges@gmail.com
    2 ; toto ; titi ; toto.titi@yahoo.com
    3 : truc ; machin ; truc.machin@free.fr
    
    Sous Agent :
    
    id_agent ; id_agent_responsable
    2 ; 1
    3 ; 1
    On voit que l'agent 1 (beeges beeges) dirige les sous agents 2 (toto titi) et 3 (truc machin).

    La solution de créer deux relations comme ceci reste toutefois valable :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Agent (id, nom, prenom, email)
    Sous-agent (id, nom, prenom, email, id_agent#)
    
    X : relation
    X : clef primaire
    X# : clef étrangère
    Cordialement,
    Idriss

  6. #6
    Membre éprouvé
    Avatar de beegees
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2004
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 610
    Points : 1 277
    Points
    1 277
    Par défaut
    Re,

    Merci pour ton complément d'information ok.Idriss.

    C'est maintenant beaucoup plus claire.

    Je vous ajoute des points à tous les deux.

    Joyeuses Pâques.

    beegees

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Copier un enregistrement dans une même table
    Par slammer dans le forum Langage SQL
    Réponses: 11
    Dernier message: 05/05/2010, 00h17
  2. Réponses: 2
    Dernier message: 04/01/2010, 11h02
  3. Requète UPDATE avec sous-requète dans la même table.
    Par Selenite dans le forum Langage SQL
    Réponses: 6
    Dernier message: 16/03/2009, 16h04
  4. [Requête] plusieurs champs dans une même table ayants la même source
    Par Christophe93250 dans le forum Requêtes et SQL.
    Réponses: 4
    Dernier message: 25/04/2006, 17h18
  5. [SQL] Somme de 2 colonnes dans une même table
    Par Cyrilange dans le forum Langage SQL
    Réponses: 6
    Dernier message: 11/04/2005, 09h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo