Agents et sous-agents dans la même table

Version imprimable

24/04/2011, 18h13
beegees

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
24/04/2011, 19h57
Richard_35

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.
24/04/2011, 20h03
ok.Idriss
Bonsoir.

Citation:

Envoyé par beegees

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

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:

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

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
25/04/2011, 10h31
beegees
Citation:

Envoyé par Richard_35

Bonjour Beegees,

Bonjour Richard et merci pour ta réponse,

==> Oui, à mon sens.

Citation:

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.

Citation:

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.

Citation:

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

Citation:

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

Bonsoir.

Bonjour OK.Idriss et merci pour ta réponse.

Citation:

Au niveau conceptuel, on parle d'entité ... mais ce n'est qu'un détails ;) .

Tu as raison ;)

Citation:

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 ?

Citation:

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)
Citation:
Si le SGBD ne gère pas l'héritage, cela peut ce traduire par la création de la relation suivante :

Code:

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 :

Citation:

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.

Citation:

Envoyé par beegees

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
Code:

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

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

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

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

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

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:

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:

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:

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

25/04/2011, 12h00
beegees

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