Discussion :

[elechi.ahmed]

Bonjour,

Pour la relation binaire comme celle-ci :

on dit : Un Client passe 0 à n Commande. Et une Commande est passée par un et un seul Client.

Mais pour les relations n-aire, je n'arrive pas à interpréter les cardinalités correctement.

Pouvez-vous m'aider à interpréter les cardinalités d'une relation à la forme suivant :


Merci pour votre aide.

[Le Pharaon]

Pouvez-vous m'aider à interpréter les cardinalités d'une relation à la forme suivant :

D'hab on part des règles de gestion (ce que tu appelles interprétation) pour faire le MCD.

Un exemple d'interpétation d'une relation (0.n <--> 0.n) Utilisateur-Goupe

• Un utilisateur peut appartenir à plusieurs groupes
• Un Groupe est composé d'utilisateurs.

[elechi.ahmed]

Merci pour votre tentative. Mais je dit bien que je n'arrive pas à interpréter les cardinalités d'une relation n-aire et pas binaire.

[Pilloutou]

Hello,

voici un exemple de relation ternaire:

http://www.developpez.net/forums/sho...43&postcount=9

Sinon il est conseillé tant que possible d'utiliser des relations binaires plutôt que des relations n-aire.
http://sql.developpez.com/modelisati...page=topologie

Tu commences par déterminer les relations binaires et ensuite tu optimises en faisant une relation n-aire si possible.
Lis le cours Conception d'une base de données disponible sur ce site.

ByeBye

[N_I_C_S]

Salut,

pour comprendre, il faut voir l'identifiant d'une relation ternaire comme la concaténation des identifiants des 3 entités (a+b+c).

Par exemple (exemple connu) :
entité A : Course hippique
entitè B : Cheval
entité C : Jockey
Relation ternaire : PARTICIPE.

La relation PARTICIPE est composée de l'identifiant (ID course + ID cheval + ID jockey). Une participation est bien la somme d'une course, d'un cheval et d'un jockey particulier.

Ceci est juste d'un point de vue conceptuel mais souvent, grace aux cardinalités, on peut ramener une relation ternaire à des relations binaires. Dans l'exemple, il y a "transitivité" : connaissant la course et le cheval on connait le jockey, connaissant la course et le jockey on connait le cheval.
on peut donc faire :
JOCKEY---monte---CHEVAL---participe---COURSE---participe---JOCKEY

les relations ternaires sont en général assez difficiles à manipuler et surtout souvent réductibles à des binaires si l'on trouve le bon concept.

[fsmrel]

Bonjour,

Exemple de lecture de votre graphe.

Supposons que nous nous intéressions aux missions effectuées par ses ingénieurs experts en SGBD chez les clients de la Société de Services Sbrozniet.

Dans votre exemple de relation ternaire, remplacez A par Ingénieur, B par SGBD, C par Client et le terme "relation" figurant dans l’ovale par Mettre en œuvre.

Votre schéma est la représentation symbolique de la mise en œuvre par les ingénieurs, de SGBD chez les clients.

Exemple :

L’ingénieur Arthur a mis en œuvre le SGBD SQL Server chez le client Banque Schmilblick.
L’ingénieur Arthur a mis en œuvre le SGBD DB2 for z/OS chez le client Banque Schmilblick.
L’ingénieur Arthur a mis en œuvre le SGBD DB2 for z/OS chez le client Banque des Schtroumpfs.
L’ingénieur Bernard a mis en œuvre le SGBD SQL Server chez le client Banque Schmilblick.
Etc.

En logique, "Mettre en œuvre" est un prédicat triadique : MettreEnOeuvre (Ingénieur, SGBD, Client).

Incidemment, certaines règles particulières à l'entreprise peuvent faire que la relation Mettre en œuvre soit décomposable. Mais il arrive aussi que cela soit impossible sans que l’on rende invalide le système.

[Black-Hawk]

Incidemment, certaines règles particulières à l'entreprise peuvent faire que la relation Mettre en œuvre soit décomposable. Mais il arrive aussi que cela soit impossible sans que l’on rende invalide le système.

Invalide le système ? Que voulez-vous dire par là ?

L'obtention de combinatoires qui n'existent pas dans la réalité à l'issue de certaines requêtes ?


Je profite de ce topic puisque j'éprouve la même difficulté que son initiateur à interpréter les cardinalités sur les relations n-aire et donc entre autre les ternaires , pour exposer un petit exemple afin de solliciter votre aide pour m'amener vers la clarté.

Je m'arrache les cheveux depuis un certain temps pour comprendre le raisonnement mais je ne fais qu'augmenter ma confusion.

Si on considère la relation ternaire suivante :

Code :

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

1
2
3
4
5
6
7
  Projet ( 1,n ) ---------------------------------- ( 0, n )Role  
                                  | PARTICIPE |
                                           |
                                           |
                                           |
                                        ( 0 , n )
                                       Employe

Une relation ternaire entre les entités Projet , Role , Employé .

Ceci est extrait d'un polycopié de cours et donc les cardinalités présentées sont supposées être correctes mais elle m'impose pas moins le trouble .

Je me suis posé comme objectif de fixer les cardinalités moi-même pour espérer trouver la même chose que ce qui se présente dans le polycopié mais je n'y arrive pas.

Il est clair que :
- un employé peut avoir plusieurs rôles dans plusieurs projets ou dans un meme projet
- un projet possède au minimum un employé avec un rôle
- un rôle concerne au moins un employé dans un projet

Quelle est la méthode pour fixer les cardinalités ?
Comment fait-on pour déterminer les cardinalités ?

Dans le polycopié , il est écrit que si la relation est n-aire , le couple ( min , max ) correspond au nombre d'occurences possibles d'entités associées dans la relation quand les autres ( n-1 ) valeurs sont fixées .

Par exemple si je veux déterminer les cardinalités correspondant à la branche coté rôle , je me dis que je fixe 2 éléments dans les ensembles d'entités Projet et Employé et je regarde le nombre de rôles que je peux associer .

Mais à ce stade pour moi , c'est encore trop flou car si je suppose que je pioche un employé et un projet , il y a deux possibilités .
Soit l'employé participe au projet et dans ce cas là il a forcément un rôle et donc le min = 1 , soit il ne participe pas au projet et donc n'a pas de rôle dans ce projet et min =0 .
Pour le max je ne ressens pas de problèmes car un employé peut avoir plusieurs rôles dans un projet.

Quand on fixe les deux autres entités , comment faut-il les fixer ? Sans relation , avec relation ?

Puisque dans le polycopié , le résultat est ( 0 , n ) pour cette première branche , je suppose que l'on doit faire cette fixation sans présomption de relation.

Passons à la détermination de la branche du bas côté Employé ,
je fixe un projet , je fixe un rôle , ce rôle peut ne pas concerner le projet et donc pas d'employé exerçant ce rôle dans le projet .( donc min=0 et "tout va bien " )

Passons à la branche de gauche , côté Projet et c'est là qu'apparait le hic .
Si je fixe un employé et un rôle , il se peut que l'employé n'exerce jamais ce rôle et donc qui ne corresponde pas de projet dans lequel l'employé aurait exercé avec ce rôle et donc que le min serait égal à 0.

Mais ci-dessus c'est ( 1 , n ) .

J'ai donc un mauvais raisonnement et je ne sais également pas interpréter les cardinalités puisque le fait d'avoir les résultats ne m'amène pas le raisonnement .

Quelqu'un pourrait m'expliquer le projet ( 1 , n) ?

J'arrive pas à le voir comme pour tout employé avec un rôle correspond un projet .

Merci

[fsmrel]

Il est clair que :
- un employé peut avoir plusieurs rôles dans plusieurs projets ou dans un meme projet
- un projet possède au minimum un employé avec un rôle
- un rôle concerne au moins un employé dans un projet

La 1re affirmation est conforme à votre représentation graphique.
La 2e affirmation l’est aussi.
La 3e ne l’est pas. En effet, d’après la représentation graphique il peut exister des rôles qui ne concernent pas les projets et les employés. Un rôle peut donc seulement concerner facultativement un ou plusieurs projets et un ou plusieurs employés.

si je suppose que je pioche un employé et un projet , il y a deux possibilités .
Soit l'employé participe au projet et dans ce cas là il a forcément un rôle et donc le min = 1, soit il ne participe pas au projet et donc n'a pas de rôle dans ce projet et min =0.

=> min = 0 l’emporte sur min = 1.

Passons en effet à une représentation tabulaire des choses (modèle logique) :



Les employés e1, e2 et e3 participent au moins à un projet en y tenant un certain rôle (e1 quatre fois, e2 deux fois et e3 une fois). En revanche, l’employé e4 ne participe à aucun projet (mais rien ne dit que cela ne se fera pas un de ces jours, quand il aura acquis la compétence nécessaire). A cause de la règle de gestion qui précise que des gens, à l’instar de e4 peuvent ne participer à aucun projet, la cardinalité min est nécessairement égale à zéro entre Emp et Participer.
De la même façon, les rôles r1, r2 et r3 sont utilisés dans au moins un projet (r1 quatre fois, r2 deux fois et r3 une fois). En revanche, le rôle e4 n’est utilisé dans aucun projet (mais rien ne dit que cela ne se fera pas un de ces jours, par exemple quand un employé aura acquis la compétence de concepteur).

Dans la représentation graphique que j’ai fournie, Participer est à un interpréter comme un prédicat de la bonne vieille logique :

L’employé EmpId participe au projet ProjId en y tenant le rôle RoleId.

Les propositions correspondantes sont par définition tenues pour vraies :

(1) L’employé e1 participe au projet p1 en y tenant le rôle r1.
(2) L’employé e1 participe au projet p1 en y tenant le rôle r2.
(3) L’employé e3 participe au projet p1 en y tenant le rôle r3.
(4) L’employé e2 participe au projet p1 en y tenant le rôle r1.
(5) L’employé e1 participe au projet p2 en y tenant le rôle r1.
(6) L’employé e2 participe au projet p2 en y tenant le rôle r2.
(7) L’employé e1 participe au projet p3 en y tenant le rôle r1.

Maintenant, si vous estimez qu’une des propositions n’est pas valide, par exemple que l’employé e2 n’a pas la compétence r3, c’est que la modélisation est à revoir, car non conforme à une hypothétique règle de gestion interdisant de faire figurer la proposition mise en cause.

Quelqu'un pourrait m'expliquer le projet ( 1 , n) ?

J’espère que ce qui précède est une réponse. Vous observerez en effet dans la représentation graphique tabulaire, que pour chaque projet, il y a au moins un employé et au moins un rôle.

Invalide le système ? Que voulez-vous dire par là ?

Je disais donc :

Incidemment, certaines règles particulières à l'entreprise peuvent faire que la relation Mettre en œuvre soit décomposable. Mais il arrive aussi que cela soit impossible sans que l’on rende invalide le système.

Pour reprendre votre exemple, supposons qu’il existe une règle de gestion (un peu alambiquée, j’en conviens) selon laquelle :

Si un employé participe à un projet, lequel requiert un rôle pour lequel cet employé doit être compétent, alors cet employé participe nécessairement au projet en y jouant le rôle requis.

Conformément à cette règle, est-ce que toutes les propositions du prédicat Participer requises font partie de l'énumération ci-dessus ? Non, car :

L’employé e1 participe au projet p2 ; lequel requiert la compétence r2 qu’a effectivement cet employé, donc il faut ajouter à la liste la proposition suivante :

(8) L’employé e1 participe au projet p2 en y tenant le rôle r2.

De même, il manque les propositions :

(9) L’employé e2 participe au projet p1 en y tenant le rôle r2.
(10) L’employé e2 participe au projet p2 en y tenant le rôle r1.

La représentation tabulaire devient en conséquence la suivante et conforme à la règle alambiquée :



En fait, la table Participer devient redondante et pour garantir la règle alambiquée, la théorie de la normalisation recommande (sans l’imposer) de décomposer cette table en 3 tables (appelons-les Requerir, Participer et Maitriser) : c’est ce qu’on appelle normaliser en 5e forme normale (5NF), processus qui permet d’éviter certaines redondances nichées dans la table qu'il a fallu compléter, difficilement perceptibles et qu’il ne faut pas oublier d’injecter pour que la table soit valide.

Si l’on normalise en 5NF, par rétroconception on obtient le MCD normalisé suivant :



Quand j’ai dit :

Mais il arrive aussi que cela soit impossible sans que l’on rende invalide le système

Cela voulait dire que le MCD normalisé ne vaut que lorsque la règle de gestion alambiquée est effective, sinon, si cette règle n’existe pas, alors ce MCD n'a rien à faire ici et c’est le vôtre MCD qui est le bon.

[Black-Hawk]

Je tiens à remercier l'attention mise à cette réponse.
Merci fsmrel.
Je m'excuse de ma réponse tardive mais entre temps j'ai dû faire un séjour à l'hôpital et passé par une période de stabilisation de forme.

Au niveau des cardinalités , ce que j'avais du mal à interpréter , je comprends maintenant.
J'ai changé le "sens de vision" et là je n'ai plus de problèmes , c'est à dire que du côté de la branche où je veux calculer les min , max je fixe l'entité et je regarde combien de couples je peux lui associer , de la même manière que dans une relation binaire alors qu'avant je faisais l'inverse , je fixais les autres entités et je regardais combien je pouvais associer d'entités correspondant à la branche.

Pourtant j'étais persuadé avant lecture de ta réponse que la façon d'interpréter différait lorsqu'on tombe dans le cadre de relation n-aire.

[CinePhil]

Un prof du CNAM nous disait toujours que pour lire un MCD (ou pour établir les cardinalités d'un MCD que l'on dessine) : "on s'arrête au verbe".

Dans l'association ternaire :
Projet -1,n----Participer----0,n- Role
Employé -0,n------|

On peut lire chaque branche en s'arrêtant au verbe 'participer' :
1) Un projet a combien de participant(s) ? --> au moins 1.
2) Un employé participe combien de fois ? --> de 0 à plusieurs.
3) Un rôle participe combien de fois ? --> de 0 à plusieurs.

Là ou le schéma ci-dessus peut être incomplet, c'est que rien ne m'interdit de faire participer à un projet un employé qui n'a pas de compétence pour le rôle qu'il doit assumer dans le projet.
Ceci dit, pas mal d'entreprises le font !

Une dernière chose en terme d'implantation...
Il faut aussi se rendre compte qu'avec une association n-aire contenant au moins une branche avec une cardinalité minimum à 1, je dois pouvoir compléter l'association dès que je crée une instance de cette branche.
Dans l'exemple ci-dessus, dès que je crée un projet, je dois remplir participer c'est à dire choisir un employé et un rôle avant d'enregistrer le projet.
Il est plus facile de mettre des cardinalités minimales à 0 partout dans le cas d'une relation n-aire.

[fsmrel]

Une dernière chose en terme d'implantation...
Il faut aussi se rendre compte qu'avec une association n-aire contenant au moins une branche avec une cardinalité minimum à 1, je dois pouvoir compléter l'association dès que je crée une instance de cette branche.
Dans l'exemple ci-dessus, dès que je crée un projet, je dois remplir participer c'est à dire choisir un employé et un rôle avant d'enregistrer le projet.
Il est plus facile de mettre des cardinalités minimales à 0 partout dans le cas d'une relation n-aire.

Vous mélangez les niveaux. Le MCD a pour objet de rendre compte des règles de gestion de l’entreprise et si une règle (disons RG1) dit qu’un projet a au moins un participant, ça n’est pas parce qu’au niveau implantation cela pose parfois, voire souvent des problèmes qu’on devra modifier le MCD sans réfléchir.

Dans le cas particulier des projets, de deux choses l’une :

• Soit il est indispensable qu’un projet ne puisse exister dans la base de données qu’à la seule condition que l’on connaisse au moins une valeur du triplet {ProjId, EmpId, RoleId}, auquel cas on utilisera les possibilités de contrôle offertes par le SGBD (si elles existent) pour garantir la règle RG1.
  
  
• Soit l’utilisateur convient que la règle RG1 peut être amendée, et la cardinalité 1,N pourra être transformée en 0,N.

Mais il ne faut pas généraliser, ce qui reviendrait à dire que la cardinalité 1,N de Merise (ou autre approche conceptuelle) a une valeur sémantique nulle dans le cas des associations-types n-aires.

[CinePhil]

Je ne mélange pas mais j'ai bien dit 'en terme d'implantation'.
Je suis bien d'accord que le MCD doit respecter les contraintes du cahier des charges.
C'est à la solution d'implantation de voir ensuite comment gérer les contraintes un peu délicates de ce genre.

[fsmrel]

Je ne mélange pas mais j'ai bien dit 'en terme d'implantation'.
Je suis bien d'accord que le MCD doit respecter les contraintes du cahier des charges.
C'est à la solution d'implantation de voir ensuite comment gérer les contraintes un peu délicates de ce genre.

Comme dit l’autre, ça va mieux en le disant comme ça. Mais votre observation précédente était quelque peu ambiguë et eut pu être mal interprétée par le lecteur pas assez averti de ces choses-là. Ne m'en veuillez pas, mais j'ai tellement rencontré ce genre de situation depuis plus de vingt ans...

[hegros]

voilà une démarche que j'utilise pour les n-aire, en partant de l'exemple précédent


pour un projet peut-il y avoir plusieurs couple employe/role?

ex : martin:developpeur, marie:administrateur

réponse oui cardinalité à N

pour un projet peut-il y aucun couple employe/role?

réponse oui cardinalité minimale à 0

--------------on fait de même avec le reste---------

pour un employe peut-il y avoir plusieurs couple projet/role?

ex : star:developpeur, plugins:concepteur
réponse oui cardinalité à N (dans le cas de non cardinalité à 1)

pour un employe peut-il y aucun couple projet/role?

réponse oui cardinalité minimale à 0 (dans le cas de la réponse non cardinalité à 1)

je vous laisse le soin de tester avec la troisiéme patte role. pour une ternaire encore cela peut aller mais n-aire genre mille-patte wow