Discussion :

[calito]

Bonjour,

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.

[bruno_pages]

l'énoncé contient deux associations (mono directionnelles) :

1. chaque employé a 0 ou 1 supérieur hiérarchique direct
2. chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs employés

ces associations sont réflexives car elles vont d'une classe à elle même

et ces deux associations (mono directionnelles) sont regroupées en une association bidirectionnelle

[hed62]

Attention, un MCD n'est pas de l'UML.

La reflexion est identique que ce soit en Merise ou en UML, mais il ne faut pas tout confondre

[calito]

Est-ce que je peux representer ma table ainsi:
IdEp Nom IdSu
E001 Toto 0
E002 Lolo E001
E003 Stef E001
E004 Paul 0
E005 Jean E002

Est-ce qu'on peut associer l'employé E001 au deuxieme cas(chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs employés) et E002 à E005 au premier cas(chaque employé a 0 ou 1 supérieur hiérarchique direct). Est-ce que la table est correcte, sinon, comment on peut la représentée.

je veux comprendre. Merci deja pour votre aide.

[hed62]

Je préfèrerai deux tables:

Employe
IdEp Nom
E001 Toto
E002 Lolo
E003 Stef
E004 Paul
E005 Jean

Hierarchie
IdEp IdSu
E002 E001
E003 E001
E005 E002

[calito]

Ah bon okey, je comprends. Mais est-ce que cela veut dire que je dois avoir deux tables pour quelque soit la cardinalité?

ensuite,
Prenons par exemple le type "PERSONNE" avec ses deux associations d'où:
1- Un papa peut avoir 0 ou Plusieurs fils (0..n)
2- Un fils peut avoir un papa (1..1)
est-ce ce que j'aurai tjrs deux tables?
Personne(idP,Nom)
Fils(idF,idP)

[juju034]

C'est justement la cardinalité qui va t'indiquer si tu as plusieurs tables ou non, c'est pour cette raison qu'elle sont cruciales.

Dans ton exemple, un pere peut avoir plusieurs fils, il est donc interressant d'avoir une autre table mettant en relation pere et fils, c'est une cardinalité 0..N du côté du pere et 1..1 du côté du fils.

Maintenant si on prend l'exemple d'une table éleve et une relation "binome", on aura obligatoirement 1 élève relié à 0 ou 1 seul autre élève, la on peut se permettre de mettre le champ "binome" dans la table éleve pointant vers le binome de l'éleve enregistré.

Lorsque que tu te demande combien de table il faut faire dans n'importe quelle relation, pose toi le problème des cardinalités , si un truc A est en relation avec un et un seul truc B, alors dans la table des truc A on aura la clé étrangere qui pointe vers un truc B , par contre si un truc A peut être en relation à plusieurs trucs B alors la relation va se transformer en une nouvelle table avec comme clé le couple (id_truc_a , id_truc_b).

[hed62]

La seconde table est surtout présente pour éviter les valeurs nulle. Elle sera également présente dans le cas du binome, puisque la cardinalité minimale donnée est 0.

Il n'y aurait pas eu de seconde table dans le cas d'une cardinalité 1.1 - 1.1 dans l'association reflexive.

[juju034]

autant pour moi ... je n'avais pas pensé à la possibilité d'avoir ce type de cardinalité dans une association...

[calito]

hed62
si c impossible d'avoir une seconde table dans le cas d'une cardinalité 1.1 - 1.1 dans une association reflexive, pour mon deuxieme exemple, comment je peux faire avec une table?

[hed62]

Puisqu'il y a au moins une occurence, et au plus une occurence, ta première modélisation fonctionne.

IdEt Nom IdBinome
E001 Toto E002
E002 Lolo E001
E003 Stef E004
E004 Paul E003

[calito]

Avec cette cardinalité cela 'm parrait diff
Je'n comprends pas pourquoi E001 à pour superiireu hierarchique E002, puis E002 à pour superiireu hierarchique E001!!!
Ensuite d'apres le deuxieme exemple que j'ai pris (PERSONNE)
"PERSONNE" avec ses deux associations d'où:
1 cas - Un papa peut avoir 0 ou Plusieurs fils (0..n)
2 cas - Un fils peut avoir un papa (1..1)

IDP NOM IDF
P01 mxx P02
P02 myy
P03

IDP(ID_PERSONNE) et IDF(ID_FILS)

Je suis blocké, je n'arrive pas, à partir de cette table à faire resortir les deux cas.

[hed62]

Je'n comprends pas pourquoi E001 à pour superiireu hierarchique E002, puis E002 à pour superiireu hierarchique E001!!!

Ma précédente réponse correspondait à l'hypothèse des binomes

Le problème Pere - Fils est identique au problème Employe - Superieur

[calito]

Donc la reponse #7 de juju034 est bonne?

Ensuite, S'ils sont identique, donc j'aurai une deuxieme table pour le probleme Personne-Fils?

[juju034]

Je ne sais pas si ca va t'aider, mais je viens d'avoir un exemple de relation reflexive dans le projet sur lequel je suis en train de travailler.

Deja on a une table compte_utilisateur :

Id_compte
Nom
Prenom
date_derniere_modification

Le truc c'est que un utilisateur peut, selon son profil, en modifier un autre.
On a donc une relation "Modifier" du type 0,N - 0,1 (un modifiant modifie 0 ou plusieurs comptes et un compte est modifié par 0 ou 1 autre compte car on ne retient que la derniere modification).

Bon chouette, alors la maintenant j'ai le choix.
Soit je fais une table de cette relation et j'ai :
Modifier :
id_compte_modifiant
id_compte_modifié

Soit dans la table compte_utilisateur je me retrouve avec l'identifiant de celui qui modifie:

Compte_utilisateur:
Id_compte
Nom
Prenom
date_derniere_modification
FK_id_compte_modifiant

Je pense que la chacun aura ses préférences.
Ce problème est le même que employé-supérieur.

Perso, je ne pense pas que je ferais une deuxième table car j'estime que id_compte_modifiant dépend directement de id_compte, et puis si personne ne modifie un compte ce champ prendra la valeur null.

Et je pense que je me serais débrouiller de cette manière pour le problème père fils mais cela n'engage que moi.

Enfin pour ce qui est de la cardinalité 1-1, 1-1 je doute fortement que se soit possible, en effet lors d'une relation non réflexive la question ne se pose pas une telle cardinalité serait triviale (c'est un dépendance fonctionnelle, d'ailleurs impossible à paramétrer sous un logiciel comme win design), et je crois sincèrement que c'est de même pour une relation réflexive.

Voila en espérant que cet exemple te servira, maintenant c'est juste ma vision des choses

[hed62]

ce champ prendra la valeur null.

C'est bien là tout le problème. Les valeurs nulles sont à éviter au plus possible dans une base de données. Je transfère dans le forum Schéma pour qu'un expert puisse confirmer mes dires

[JPhi33]

Bonjour à tous,

Si la solution présentée par hed62 est peut-être satisfaisante techniquement (elle a le mérite de supprimer les Null), elle l'est moins conceptuellement.

Je préfèrerai deux tables:

Employe
IdEp Nom
E001 Toto
E002 Lolo
E003 Stef
E004 Paul
E005 Jean

Hierarchie
IdEp IdSu
E002 E001
E003 E001
E005 E002

La rétro-conception de ce modèle logique donne ceci :



La flèche épaisse ouverte représente un lien de généralisation - spécialisation.
La cardinalité 1,1 correspond au résultat voulu par hed62, à savoir la suppression des Null.

Notez au passage que j'ai renommé l'entité correspondant à la table "Hiérarchie" en "Employé_subordonné". Bien que le terme "Hiérarchie" ne soit pas conceptuellement faux et représente bien la réalité décrite, il ne nomme pas correctement l'entité en tant que spécialisation de "Employé".

Vous voyez qu'on est loin du MCD initial par la simple volonté d'éliminer les Null.

En conclusion, je dirai qu'il faut porter une attention particulière, lors des optimisations des niveaux logique et physique, à ne pas trop s'éloigner de la sémantique d'origine.


JPhi33

[fsmrel]

Bonsoir,

Notez au passage que j'ai renommé l'entité correspondant à la table "Hiérarchie" en "Employé_subordonné". Bien que le terme "Hiérarchie" ne soit pas conceptuellement faux et représente bien la réalité décrite, il ne nomme pas correctement l'entité en tant que spécialisation de "Employé".

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

Toutefois, l’amateur de représentation graphique à la mode anglo-saxonne peut considérer Hiérarchie comme entité-type associative (au sens de Codd) et préciser le rôle dominant de l’entité-type Employe par rapport à l’entité-type Hierarchie (rôle symbolisé par (D) dans le MCD). (Outil utilisé : Power AMC.)

Maintenant, au niveau logique, il faut aussi considérer l’impact de la suppression d’un employé (table Employe) : si on utilise l’option CASCADE dans le contexte de l’intégrité référentielle (table Hierarchie), cette suppression aura pour effet de rompre les liens avec ses subordonnés (table Hierarchie). La suppression du PDG se traduit donc par la "promotion" automatique de ses collaborateurs directs.

Pour en revenir au tout premier schéma présenté par calito, au niveau MLD on aura une table Employe s’auto-référençant et du fait de CASCADE (si le SGBD l’autorise, ce qui est le cas par exemple de DB2), si l’on supprime le PDG, à la fin de l’opération la table Employe sera vide.

Le choix de la modélisation au niveau conceptuel n’est pas neutre dans ses effets (indépendamment de la présence éventuelle du bonhomme NULL).

[hed62]

Je savais bien que j'avais encore des lacunes ><

Comment faire, alors, pour passer du MCD d'origine, avec une asssociation réfléxive donc, à un MPD qui ne contiendrait pas de valeur nulle, sans trop s'éloigner de la sémantique de départ ?

[calito]

Donc pour l'exemple PERSONNE
Je peux avoir deux tables?
Personne(id_personne, nom)
Fils(id_personne, id_personne_fils)