Discussion :

[le_bono]

Bonjour, j'ai une question concernant la structure d'une table, j'ai à gérer une table de commerciaux,
chaque commercial est affecté à un responsable qui est lui même un commercial.
J'ai donc procédé de la manière suivante, chaque enregistrement de la table "commercial" a une colonne "idresponsable" qui référence un enregistrement
de la table "commercial"
Je pensais dans un premier à gérer une table annexe avec les responsable mais un responsable peut lui même dépendre d'une autre responsable.
Pensez vous que cette méthode soit conforme?

Merci.

[CinePhil]

chaque commercial est affecté à un responsable qui est lui même un commercial.

Sauf un peut-être ? Sinon c'est le serpent qui se mord la queue :
Alain est affecté à Benoït qui est affecté à Corinne qui est affectée à Alain !
Donc c'est plutôt :
"Chaque commercial peut être affecté à un responsable qui est lui même un commercial"

Ce qui se traduit par le schéma :
Commercial -0,1----Affecter----0,n- Commercial

Et qui donne effectivement la table :
Comercial (C_Id, C_Nom, C_Prenom, C_IdResponsable, ...)

[le_bono]

Merci,

c'est le schéma que j'ai adopté, le seul inconvenient c'est pout l'intégrité référentielle.

[fsmrel]

Bonjour,

le seul inconvenient c'est pout l'intégrité référentielle.

Au plan théorique, il n’y a pas de problème d’intégrité référentielle :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE Commercial
(
    C_Id             int           not null,
    C_Nom            varchar (48)  not null,
    C_IdResponsable  int           null,
  PRIMARY KEY (C_Id),
  FOREIGN KEY (C_IdResponsable)
        REFERENCES Commercial (C_Id)
          ON DELETE ...
);

Mais la cardinalité 0,1 se traduit par NULL pour l’attribut C_IdResponsable.
En plus, selon les SGBD vous pouvez être amené à vous plier à des règles qui se contredisent dans leurs justifications. Par exemple, vous devez coder :

« ON DELETE CASCADE » dans le cas de DB2 for z/OS,
« ON DELETE NO ACTION » dans le cas de SQL Server.

Pour ne pas mélanger ce qui est propre à une personne avec ses rapports hiérarchiques, et par ailleurs pour éviter NULL, vous pouvez de préférence coder :

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
CREATE TABLE Commercial
(
    C_Id             int           not null,
    C_Nom            varchar (48)  not null,
  PRIMARY KEY (C_Id),
);
CREATE TABLE Hierarchie
(
    C_Id             int           not null,
    C_IdResponsable  int           not null,
  PRIMARY KEY (C_Id),
  FOREIGN KEY (C_Id)
        REFERENCES Commercial (C_Id)
          ON DELETE ...,
  FOREIGN KEY (C_IdResponsable)
        REFERENCES Commercial (C_Id)
          ON DELETE ...
);

Mais les SGBD continuent à se contredire joyeusement.

[CinePhil]

Et si la hiérarchie est plus complexe et forme un arbre, comme un organigramme, voir le tutoriel de SQLPro sur la modélisation des arborescences par intervalles.