Discussion :

[fsmrel]

Donc pour l'exemple PERSONNE

Je peux avoir deux tables?

Personne(id_personne, nom)
Fils(id_personne, id_personne_fils)

Bien entendu.

Apparemment, vous utilisez Power AMC. Au lieu de modéliser ainsi :

Vous pouvez utiliser les schémas que je vous ai fournis, ou encore celui que vous a proposé JPhi33 et en l’occurrence procéder ainsi :







Et vous obtiendrez les tables que vous attendez.

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
Create Table Employe (
   EmpId                Integer          Not null,
   EmpNom               Varchar(48)      Not null,
   Constraint Employe_PK Primary Key  (EmpId)
) ;
Create Table Employe_Subordonne (
   EmpId                Integer          Not null,
   EmpIdSuperieur       Integer          Not null,
   Constraint Employe_Subordonne_PK Primary Key  (EmpId),
   Constraint Employe_Subordonne_Employe_A Foreign Key (EmpId)
      References Employe (EmpId),
   Constraint Employe_Subordonne_Employe_B Foreign Key (EmpIdSuperieur)
      References Employe (EmpId)
) ;

[juju034]

Nous ne sommes donc plus dans le cas d'une association reflexive, n'est ce pas ?
Ce la veut il dire que les associations reflexives sont à proscrire ?

[calito]

Bonsoir,
Sémantiquement parlant, la modélisation proposée par JPhi33 est évidemment la meilleure qui soit et c’est celle qu’il faut utiliser.

donc fsmrel à propos de l'exemple Employé, si la proposition de JPhi33 est bonne, celle de hed62 l'est egalement ( à savoir qu'il prefererait deux tables)!!

Ensuite concernant le deuxieme exemple PERSONNE(pere, fils):
1- Une Papa peut avoir 0 ou Plusieurs fils (0..n)
2- Un fils peut avoir un papa (1..1)
à vous tous, je veux savoir comment presenter mon MCD avec Merise. Ensuite combien de tables que j'aurai.

[fsmrel]

Bonsoir,


Remettons les compteurs à zéro.

Je n'arrive pas à comprendre l'association reflexive
Voici un exemple de MCD que j'ai trouvé:




d'apres l'explication du document: " chaque employé a 0 ou 1 supérieur hiérarchique direct. Simultanément, chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs employés. EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique)
#id_Sup_Hierarchique est l'identifiant (id_Employe) du supérieur hiérarchique direct de l'employé considéré.

Pouvez m'aider à le comprendre, SVP.
Merci.

Pour une meilleure compréhension, ajoutons au schéma les rôles joués par l’employé : subalterne ou supérieur.





Ce schéma conceptuel se lit alors ainsi :

Un employé peut participer au plus une fois à l’association-type sup_hierarchique en y jouant le rôle de subalterne.

Un employé peut participer plusieurs fois à cette association-type en y jouant le rôle de supérieur.

Autrement dit : un employé peut être au plus une fois subalterne et un employé peut être plusieurs fois le supérieur d’autres employés.

Un employé peut ne pas être subalterne (cas du président) et tous les employés ne sont pas chefs (cas de la base). Ceci est exprimé par respectivement les cardinalités 0,1 et 0,N. A noter que remplacer 0,1 par 1,1 signifierait que le président à nécessairement un chef, ce qu'il risquerait de ne pas apprécier.



Par dérivation (disons avec Power AMC), le schéma conceptuel donne ensuite lieu à un schéma logique (niveau SQL) :




Ce qui symbolise ce que l’auteur du document a formulé ainsi :

EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique)

Schéma de table dans lequel

L'attribut id_Employe entre dans la composition de la clé primaire (pk) de la table EMPLOYE,

L’attribut id_Sup_Hierarchique entre dans la composition de la clé étrangère (fk) établissant une contrainte référentielle de la table EMPLOYE avec elle-même : un subalterne doit faire référence à son supérieur, lequel doit donc exister avant création du lien subalterne-supérieur.

[fsmrel]

Bonsoir,

à vous tous, je veux savoir comment présenter mon MCD avec Merise. Ensuite combien de tables que j'aurai.

Quelle autorité ! Ça me rappelle mon service militaire...
Comme on l’a vu, vous avez plusieurs représentations possibles pour votre MCD, correspondant à autant de scénarios.

Premier scénario. Celui-ci correspond à la représentation que vous avez proposée dans votre 1er message, avec l’outil Power AMC. Au niveau MLD, l’outil produira une seule table s’auto-référençant (cf. mon précédent mesage).

Deuxième scénario. Celui-ci correspond à la représentation proposée par JPhi33 (dont je vous ai fourni l’équivalent avec Power AMC). Au niveau MLD, l’outil produira deux tables.

Troisième scénario. Celui-ci correspond à la représentation que je vous ai proposée comme alternative, selon un mode de représentation à l'anglo-saxonne. Au niveau MLD, l’outil produira encore deux tables et on sera finalement ramené au deuxième scénario.

Il existe des variantes, mais on en restera là.

Par ailleurs, quel que soit le résultat produit par l’outil lors du passage du MCD au MLD, vous pouvez retoucher celui-ci comme il vous plaira. Néanmoins, on va dire que l’on cherchera à modéliser de telle façon que l'on n'ait rien à devoir retoucher.

La question est de savoir ce que vous recherchez d’un point de vu fonctionnel et quelles sont les conséquences de votre choix, notamment en relation avec le métabolisme des données (comme dit Ted Codd, les tables ne sont pas à considérer du simple point de vue anatomique, mais aussi physiologique, ça vit tout ça !)

1) Si fonctionnellement, la disparition d'un employé doit entraîner celle de tous ses collaborateurs, alors vous pouvez retenir la solution correspondant au premier scénario (mais avec NULL possible pour l’attribut ChefEmpId).
Au niveau SQL, ce scénario donne lieu à un code qui peut varier selon les SGBD, lesquels ont chacun leurs caprices. Par exemple, DB2 for z/OS permet l’emploi de CASCADE ou de NO ACTION concernant le métabolisme, alors que SQL Server n’autorise que NO ACTION. Les restrictions invoquées varient en général avec l’époque à la quelle elles ont été énoncées (par exemple, jadis DB2 n’autorisait que CASCADE).

Avec DB2, vous pourrez coder :

Code SQL :

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

1
2
3
4
5
6
7
8
Create Table Employe (
     EmpId     Char(4)        Not Null
   , EmpNom    Varchar(48)    Not Null
   , ChefEmpId Char(4)         
 , Constraint Emp_PK Primary Key (EmpId)
 , Constraint EMP_FK1 Foreign Key (ChefEmpId) References Employe
     On delete CASCADE 
) ;

Et si vous voulez supprimer un employé et tous ses collaborateurs du plus grand au plus petit :

Code SQL :

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

1
2
DELETE FROM Employe  
       WHERE EmpId = 'Nico' ;

Avec SQL Server, pour effectuer le même travail, il faudra remplacer CASCADE par NO ACTION, puis ruser et baguenauder du côté de la récursivité :

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
WITH Vue (Cezig, ChefDeCezig) AS 
    (
     SELECT EmpId, ChefEmpId 
     FROM   Employe  
     WHERE  ChefEmpId = 'Nico'  
    UNION ALL 
     SELECT I.EmpId, I.ChefEmpId  
     FROM   Vue, Employe AS I 
     WHERE  I.ChefEmpId = Vue.Cezig 
    )
  DELETE FROM Employe  
         WHERE EmpId = 'Nico'
            OR EXISTS (SELECT *
                       FROM   Vue
                       WHERE  Vue.Cezig = Employe.EmpId)
;

2) S’il est hors de question que la disparition d’un employé entraîne celle de ses collaborateurs, mais seulement la rupture des liens qu’il entretient avec ses collaborateurs directs (qui de facto grimpent d’un cran dans la hiérarchie), on aura besoin des deux tables. Le code est le suivant :

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
Create Table Employe (
     EmpId     Char(4)        Not Null
   , EmpNom    Varchar(48)    Not Null
 , Constraint Emp_PK Primary Key (EmpId)
) ;  
 
Create Table Employe_Subordonne (
     EmpId        Char(4)     Not Null
   , ChefEmpId    Char(4)     Not Null
 , Constraint Hie_PK Primary Key (EmpId)
 , Constraint Hie_FK1 Foreign Key (EmpId) References Employe
     On delete Cascade
 , Constraint Hie_FK2 Foreign Key (ChefEmpId) References Employe
     On delete No Action
) ;

Les contraintes propres à DB2 ou SQL Server disparaissent. Pour supprimer un employé ainsi que les liens l’unissant à ses collaborateurs directs, mais sans propagation aux niveaux dépendants :

Code SQL :

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

1
2
3
4
5
6
Delete from Employe_Subordonne
         where ChefEmpId = 'nico' 
;
Delete from Employe 
         Where EmpId = 'nico'
;

3) Variante : s’il est toujours hors de question que la disparition de l’employé entraîne celle de ses collaborateurs, mais si cette fois-ci, l’ensemble des liens hiérarchiques doit aussi disparaître pour tous les niveaux dépendants :

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
WITH Vue (Cezig, ChefDeCezig) AS 
    (
     SELECT EmpId, ChefEmpId 
     FROM   Employe_Subordonne  
     WHERE  ChefEmpId = 'nico'  
    UNION ALL 
     SELECT I.EmpId, I.ChefEmpId  
     FROM   Vue, Employe_Subordonne AS I 
     WHERE  I.ChefEmpId = Vue.Cezig 
    )
  DELETE FROM Employe  
         WHERE empid = 'nico' 
            OR EXISTS (SELECT *
                       FROM   Vue
                       WHERE  Vue.Cezig = Employe.EmpId) ;

Moralité : le choix de la représentation graphique d’une relation réflexive peut être conditionné par les aspects fonctionnels d’une application et cette représentation n’est que la partie émergée de l’iceberg. J’ai évoqué les conséquences de la suppression des employés et de leurs liens hiérarchiques, reste à traiter de la modification d’y-ceux : l’union récursive devrait permettre une fois de plus de traiter le problème (je vous le laisse à titre d’exercice). En tout état de cause, si l’on veut éviter l’apparition du bonhomme NULL, dans tous les cas on pourra s’en sortir en évitant l’auto-référence (réflexivité) donc en utilisant deux tables et en se servant de l’union récursive.
On pourrait aussi conserver le schéma d’origine et y remplacer la cardinalité 0,1 par une cardinalité 1,1 ; on n’aurait plus qu’une seule table mais la hiérarchie ne serait plus respectée stricto sensu (le PDG deviendrait son propre subalterne) : en tout cas c’est ce dont ne voulait pas le colonel H*, voyez la discussion Relation réflexive avec mise à jour/suppression en cascade.

[JPhi33]

Bonjour à tous,

Nous ne sommes donc plus dans le cas d'une association reflexive, n'est ce pas ?
Ce la veut il dire que les associations reflexives sont à proscrire ?

Non, bien sûr que non !

Mais il faut être conscient des conséquences que cela implique au niveau logique puis physique, comme démontré dans l'exposé de fsmrel (n°25 de cette discussion).