Discussion :

[dimix77]

Bonjour à tous !

Je travaille actuellement sur un MCD dans lequel il se trouve une relation ternaire de cardinalité 0,N / 0,N / 1,1.

Je crois savoir que ce type de relation n'est pas consseillé, sauf dans un cas particulier, il se trouve que je suis exactement dans ce cas, mais ce n'est pas le sujet de ce post.

Je cherche donc simplement comment transcrire cette relation ternaire de cardinalité 0,N / 0,N / 1,1 en model physique.

J'ai bien ma petite idée, mais j'aimerai en débattre avec vous.
Quel est votre avis ?

Merci.

[CinePhil]

Si tu nous donnais ton cas concret, ce serait plus facile !

Tu as donc une association ternaire de ce type :
A -1,1----Associer----0,n- B
C -0,n----------|

Les tables qui en découlent :
A (id_a, ...)
B (id_b, ...)
C (id_c, ...)
Associer (id_a, id_b, id_c...)

La question à se poser alors est :
Peut-on transférer les attributs de B et de C dans A puisque A ne peut être associé à des valeurs de B et de C qu'une seule fois ?

Ou alors :
Peut-on transformer l'association ternaire en deux associations binaires de type (1,1 - 0,n) ?
A -1,1----Associer1----0,n- B
|----1,1---Associer2----0,n- C

Auquel cas A accueille simplement les deux identifiants de B et de C en tant que clé étrangère :
B (id_b, ...)
C (id_c, ...)
A (id_a, id_b, id_c...)

[fsmrel]

Comme dit CinePhil, avec un cas concret ça serait plus facile de traiter le problème.

Supposons maintenant qu’il existe une association R entre les entités-types B et C grâce à laquelle on définit les paires légales {B, C}. Dans ces conditions, l’association R doit être conservée, nonobstant la cardinalité 1,1 côté A.

Le MLD ressemble alors à quelque chose comme ceci :



Mais il est évident que dans le contexte Merise, le MCD diffère de celui de CinePhil.

Même chose si l’on cherchait par exemple à produire le MLD :

[MacFly58]

Je réouvre ce topic pour éclaircir un point :


dimix77 :

Je crois savoir que ce type de relation n'est pas conseillé, sauf dans un cas particulier

De quel cas particulier s'agit-il selon vous ?

[CinePhil]

Le premier MLD de fsmrel est issu du MCD suivant :
B -0,n----associer_1----(1,1)- R -(1,1)----associer_2----0,n- C
A -1,1----associer_3----0,n-----|

Il produit les tables suivantes :
B (id_b, ...)
C (id_c, ...)
R (id_b, id_c...)
A (id_a, id_b, id_c...)

À noter que dans A il y a une clé étrangère faisant référence à deux colonnes de R et non pas deux clés étrangères.

Le second MLD de fsmrel est issu du MCD suivant :
B -0,n----associer_1----(1,1)- R -(1,1)----associer_2----0,n- C
A -0,n----associer_3----1,1-----|

Les cardinalités de associer_3 ne sont pas les mêmes !

Il produit les tables suivantes :
A (id_a...)
B (id_b, ...)
C (id_c, ...)
R (id_b, id_c, id_a...)

Quant à mon MCD :

A -1,1----Associer----0,n- B
C -0,n----------|

Il donne le MLD suivant :
A <--(R)--Associer----> B
C <--------------|

Je crois que l'identification relatrive se représente ainsi sur un MLD mais je n'en suis pas sûr. Je ne fais jamais de MLD, plutôt des schémas EER à la MySQL Workbench.
Sous cette dernière forme, le schéma serait celui-ci :
A >|----||- Associer -||----o< B
C >o-----------||

[MacFly58]

Arf j'ai modifié mon post entre temps, et donc ma question.

Mais ceci dit merci CinePhil, votre post apporte des précisions utiles.

[MacFly58]

Le premier MLD de fsmrel est issu du MCD suivant :
B -0,n----associer_1----(1,1)- R -(1,1)----associer_2----0,n- C
A -1,1----associer_3----0,n-----|

Il produit les tables suivantes :
B (id_b, ...)
C (id_c, ...)
R (id_b, id_c...)
A (id_a, id_b, id_c...)

Dans l'hypothèse ou dans le MLD la table "R" ne contient que les attributs id_a et id_b, que contient l'entité-type "R" dans le MCD ?

Il me semble que l'entité-type "R" est dépourvue de propriétés et d'identifiant, ce serait donc plutôt une association-type (n-n).

Par ailleurs, quel est l'intérêt d'utiliser l'identification relative pour ce MCD ?

Merci pour vos lumières

[CinePhil]

Dans ce MCD, R est en effet une association transformée en entité. Le cas classique est celui des commandes :
Commande -1,n----Comprendre----0,n- Produit

Comme on veut ensuite suivre individuellement la livraison et la facturation de chaque ligne de commande, qui se trouve en fait matérialisée dans l'association "comprendre", on transforme cette association en entité Ligne_commande :

Commande -1,n----Comprendre----(1,1)- Ligne_commande -(1,1)----Concerner----0,n- Produit

Ainsi on peut mettre en association la ligne de commande avec autre chose alors que normalement dans un MCD on ne met pas une association en liaison directe avec une autre association.

Par ailleurs, quel est l'intérêt d'utiliser l'identification relative pour ce MCD ?

L'intérêt est justement de en pas créer un identifiant artificiel pour cette association transformée en entité, ce qui obligerai à ajouter une contrainte d'unicité sur le couple de clés étrangère, en plus de la clé primaire. Pour reprendre mon exemple, on identifie relativement une ligne de commande par rapport à la commande et au produit.

Mais on pourrait aussi avoir ce MCD :
Commande -1,n----Comprendre----(1,1)- Ligne_commande -1,1----Concerner----0,n- Produit

Cette fois, la ligne de commande est une vraie entité mais comme la ligne de commande dépend directement de la commande, on l'identifie quand même relativement à la commande.
La table a ainsi cette structure :
Ligne_commande (lc_id_commande, lc_num_ligne, lc_id_produit...)
On recommence à 1 la numérotation des lignes pour chaque commande. C'est plus cohérent d'avoir un jour la ligne de commande 126352 - 3 que d'avoir la ligne de commande n° 124579627. Même si la clé primaire n'est pas censée avoir une signification, ici ce n'est pas gênant de lui en donner une.

[MacFly58]

Donc votre entité-type "ligne_commande" matérialisée par un rectangle pourra potentiellement être vide ? c'est-à-dire ne contenir ni propriétés ni identifiant dans le MCD ?
(Je pense que généralement une telle entité-type contiendra des propriétés du genre "Montant de la réduction", "Montant total"... Mais que potentiellement elle peut ne rien contenir)

Ceci me semble aller à l'encontre des règles de bases de Merise.

Je crois comprendre que vous utilisez cette représentation pour pallier à l'une des lacunes de Merise, ce qui me semble salutaire. Mais d'un autre coté, un rectangle vide dans un MCD ne me convient pas non plus.

La solution est peut-être d'avoir effectivement un rectangle vide dans notre MCD d'informaticien, et de présenter à notre commanditaire un MCD simplifié plus lisible.

[CinePhil]

Donc votre entité-type "ligne_commande" matérialisée par un rectangle pourra potentiellement être vide ? c'est-à-dire ne contenir ni propriétés ni identifiant dans le MCD ?

Oui.

(Je pense que généralement une telle entité-type contiendra des propriétés du genre "Montant de la réduction", "Montant total"... Mais que potentiellement elle peut ne rien contenir)

Effectivement, dans ce cas précis, il y aura au moins la quantité de produit acheté et probablement son prix de vente hors-taxe, son code de TVA, le montant de la remise...

Ceci me semble aller à l'encontre des règles de bases de Merise.

Je crois comprendre que vous utilisez cette représentation pour pallier à l'une des lacunes de Merise, ce qui me semble salutaire. Mais d'un autre coté, un rectangle vide dans un MCD ne me convient pas non plus.

C'est peut-être un peu ça oui. J'ai déjà présenté cette solution sur le forum sans déclencher les foudres des spécialistes de Merise.
Je préfère ça à relier deux association personnellement.

Mais dans la pratique, si j'avais à modéliser les commandes, je passerais tout de suite à la seconde solution :

Commande -1,n----Comprendre----(1,1)- Ligne_commande -1,1----Concerner----0,n- Produit

Ligne_commande (lc_id_commande, lc_num_ligne, lc_id_produit...)

Et cette fois, l'entité Ligne_commande comprend un attribut participant à l'identification : lc_num_ligne

La solution est peut-être d'avoir effectivement un rectangle vide dans notre MCD d'informaticien, et de présenter à notre commanditaire un MCD simplifié plus lisible.

Présente t-on un MCD détaillé avec les attributs à un commanditaire (je comprends par ce terme "client") ?
Perso je présenterais éventuellement le MCD avec le nom des entités et les verbes des associations mais pas les attributs de manière à ne pas embrouiller le client.
Avec un MCD moderne fait avec un logiciel de modélisation, on est déjà proche de l'architecture physique des données.

À la limite, ce qui est plutôt à présenter à un client c'est le Modèle Organisationnel des Données, c'est à dire les données telles qu'elles lui seront présentées, proche des vues qui seront faites dans la BDD et accessibles au logiciel.

[fsmrel]

Bonsoir,

Le second MLD de fsmrel est issu du MCD suivant :
B -0,n----associer_1----(1,1)- R -(1,1)----associer_2----0,n- C
A -0,n----associer_3----1,1-----|

Du point de vue d’une modélisation avec laquelle on n’utilise pas les CIF, c’est exact. Pour aboutir au même MLD, dans le cas de Merise on peut de préférence représenter graphiquement les choses ainsi :



Ou plus simplement :

Quant à mon MCD :

Code :

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

1
2
3
 
A -1,1----Associer----0,n- B
C -0,n----------|

Il donne le MLD suivant :
A <--(R)--Associer----> B
C <--------------|
Je crois que l'identification relative se représente ainsi sur un MLD mais je n'en suis pas sûr.

Normalement l’identification relative ne concerne pas le MLD, mais seulement le MCD. Cela dit, certains outils ne sont pas regardants, c'est le cas de Workbench qui tricote allègrement les niveaux : il utilise le concept de clé étrangère (qui par construction ne concerne pas les MCD) mais aussi celui de « identifying relationship » qui concerne plutôt le niveau conceptuel et, quoi qu'il en soit, viole le principe d’essentialité cher à Codd, car redondant avec le fait que l'on sait définir de deux façons différentes comment les attributs participant à une clé étrangère peuvent aussi participer à une clé primaire (plus généralement candidate). Incidemment, je note que Workbench qualifie à tort ses diagrammes de « EER » (Enhanced Entity Relationship) : pour mériter cette étiquette, il faudrait en évacuer le concept de clé étrangère, faire figurer les concepts de généralisation/spécialisation et autres.

Cela dit, le MLD à produire (cf. mon 1er message) est plutôt celui-ci (dans lequel « R » est un alias de « Associer ») :



Ou, dans le style d’IEF (Information Engineering Facility) :



Avec Workbench lui-même, on retrouve quelque chose de semblable :



Notez que vos propres cardinalités (Workbench) sont à remettre à l’endroit (comme eu dit saint Éloi...)


Pour en revenir à la représentation conceptuelle :

Tu as donc une association ternaire de ce type :

Code :

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

1
2
A -1,1----Associer----0,n- B
C -0,n----------|

Les tables qui en découlent :

Code :

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

1
2
3
4
A (id_a, ...)
B (id_b, ...)
C (id_c, ...)
Associer (id_a, id_b, id_c...)

Il s’agit du MLD qu’on doit logiquement produire, mais les outils (je pense à Power AMC) peuvent fournir des résultats surprenants et surtout faux...

Cela dit, une ternaire dont une des pattes porte une cardinalité 1,1 est suspecte, voyez ce qu’en dit Yves Tabourier (cf. la discussion avec philou029).

[fsmrel]

Le premier MLD de fsmrel est issu du MCD suivant :
B -0,n----associer_1----(1,1)- R -(1,1)----associer_2----0,n- C
A -1,1----associer_3----0,n-----|

Il produit les tables suivantes :
B (id_b, ...)
C (id_c, ...)
R (id_b, id_c...)
A (id_a, id_b, id_c...)
Dans l'hypothèse ou dans le MLD la table "R" ne contient que les attributs id_a et id_b, que contient l'entité-type "R" dans le MCD ?

Il me semble que l'entité-type "R" est dépourvue de propriétés et d'identifiant, ce serait donc plutôt une association-type (n-n).

Par ailleurs, quel est l'intérêt d'utiliser l'identification relative pour ce MCD ?

Merci pour vos lumières

Je complète l’éclairage donné par CinePhil. R est bien une association-type (n-n). Le problème est qu’il faut établir une autre association entre R et A, or (la version classique de) Merise ne permet pas d’établir une association entre une association-type et une autre chose-type, d’où la nécessité d’un subterfuge pour contourner ce diktat : R déguisée en entité-type et utilisation de l’identification relative pour qu’au stade du MLD on trouve bien id_b et id_c comme composant la clé de R.

[fsmrel]

Bonsoir,


La discussion ici avec philou029 étant marquée comme résolue, je reprends ici la question posée par MacFly58 dans cette même discussion, à propos de la représentation (1) :



Et pour laquelle j’ai écrit :

la représentation (1) peut se justifier si une valeur de A31 implique une paire de valeurs particulière (A11,A21). Sinon, selon la représentation (2), A31 peut être associé à n’importe quel A11 et n’importe quel A21. La question de MacFly est la suivante :

Qu'entendez-vous par "valeurs particulière" ?

Dois-je comprendre :

Code :

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

1
2
3
4
5
6
A31           A11           A21
 1             8             4
 2             2             1
 3             7             7
 4             2             1

Pour la dernière occurrence, les valeurs (2-1) ne sont pas "particulières" car ce couple (2-1) a déjà été utilisé ?

Si c'est cela, cela se traduit plus simplement par une dépendance fonctionnelle A11+A21 -----> A31 ou mieux peut-être, par une CIF dans le MCD (une flèche sur la patte 1,1)

mais tout cela ne m'explique pas pourquoi dans ce cas il est souhaitable de conserver l'association ternaire.

Il ne s’agit en aucune façon de cela. Pour les dépendances fonctionnelles, on doit plutôt lire :

{A31} → {A11, A21}

Et en vertu de la règle de décomposition :

{A31} → {A11}
{A31} → {A21}

Autrement dit, pour une valeur de A31 on a exactement une valeur de A11 et exactement une valeur de A21. Mais ce que cherche à faire comprendre le MCD est que, en plus, A11 et A21 doivent préalablement être compatibles.


Prenons un cas plus significatif :

Par exemple, une entreprise vend des produits qui peuvent être qualifiés de neufs, d’occasion, retapés, rogatons, etc.
Les clients de cette entreprise font eux aussi l’objet d’une typologie : particuliers, entreprises privées, entreprises publiques, administrations, militaires, etc.

Pour préciser quels sont les types de produits que l’on peut vendre à quels types de clients, on peut représenter les choses ainsi :




On peut parier sans risque que la paire <armée de l’air, rogaton> ne fera pas l’objet d’une occurrence de l’association-type ETRE_COMPATIBLE...

Supposons maintenant que l’on définisse un type de commande, avec la contrainte suivante : un type de commande fait référence à un type de client et à un type de produit, mais à condition que le type de produit et le type de client soient compatibles.

Pour ne pas risquer de vendre des rogatons à l’Armée de l’Air, je ne peux donc décemment pas représenter les choses ainsi :




Et je peux donc préférer cette représentation, assez maladroite, certes, et pas très satisfaisante, je vous l’accorde :




Aussi serai-je plus enclin à suivre Smith & Smith (rien à voir avec les Dupondt) et appeler un chat un chat (voyez la discussion avec bloups) :




Cette façon de représenter les choses (agrégation) a plus de 30 ans et n’emballe plus les foules. On peut aussi essayer d’en passer par une CIF :




Mais en ce qui concerne Merise, vu les possibilités réduites offertes par les outils tels que Power AMC, pour une dérivation correcte du MLD, j’en suis réduit à déguiser une association-type en entité-type, à affaiblir la sémantique du MCD :




Système D oblige, on fait ce qu'on peut avec ce qu'on a. Do you agree tovaritch ?

P.–S. Et pendant ce temps-là, il neige, il neige, même dans le Relationland...

[MacFly58]

Si j'ai bien compris, dans le cas "A31 implique une paire de valeurs particulière (A11,A21)" il est conseillé de générer 4 tables lors du passage au MLD. Sinon, 3 tables sont suffisantes, et l'association ternaire du MCD est à décomposer en 2 binaires.

[CinePhil]

Si j'ai bien compris, dans le cas "A31 implique une paire de valeurs particulière (A11,A21)" il est conseillé de générer 4 tables lors du passage au MLD.

Oui, c'est le cas décrit dans le dernier message de fsmrel avec ses produits compatibles avec le type de clients.

Sinon, 3 tables sont suffisantes, et l'association ternaire du MCD est à décomposer en 2 binaires.

C'est la représentation (2) de l'autre discussion, que je reproduis ci-dessous :

On passe habituellement à celle-ci (2) :

[MacFly58]

Merci à vous deux, c'est limpide maintenant, et très utile car ce cas d'association N/N/1 n'est pas si rare que ça je trouve.

C'est vrai qu'avec un exemple concret on capte mieux