Discussion :

[aminnio]

Bonjour,
Je reviens vers le forum pour demander de l'aide à propos d'une modelisation que je voudrais effectuer.

Je voudrais savoir comment je pourrais modeliser sur une BD la reponse à la question suivant :

Un Produit X est composé de Produit Y.
Un Produit Y est composant de produit X et Z.

En effect, un produit peut etre composant de plusieurs produits, et un produit X ne peut etre composé que d'un seul produit.

Voila !
J'ai pensé à quelques solutions alternative, qui fonctionnerait certainement, mais je souhaiterais avoir vos avis sur la question.


Cordialement.

[nico84]

Bonjour,

A priori je ferais comme une nomenclature :
- une table des produits
- une table des liens composant/composé

Cette architecture permet tous les cas de figure. Ensuite les règles de ce qui est permis ou non doivent se programmer à la saisie.

[sandrine]

Euh moi je vois ca autrement

Une table produit avec id, libelle, prix,..... + un champ "composé" puisque "un produit X ne peut etre composé que d'un seul produit."
Ce champ composé ne peut comporter que un Id de produit ( zone de liste facile a faire) ou etre null ( en fonction des règles)

comme ca ca donnerais:
produit | Composé
X | Y
Y |
Z | Y

le produit Y est bien le composé de X et Z
et dans ce cas le produit Y n'a pas de composé
c'est une relation recursive

Je suis d'accord qu'il faut souvent sortir des données d'une table mais dans ce cas, on sais que 1 produit n'a forcément qu'un seul composant, donc pas de multicité donc pas besoin de seconde table.

[fsmrel]

Bonsoir,


Je fais remarquer que la solution de nico84 est valide (notez la cardinalité 0..1) :



En effet, le prédicat de la variable relationnelle COMPOSITION est le suivant, conforme non seulement à la règle de gestion proposée aminnio, mais aussi à logique bivalente classique et à la théorie relationnelle :

Le produit ProduitComposéId est composé du produit ProduitComposantId.

Je fais aussi observer que la structure proposée par Sandrine fait intervenir Null et n’est donc pas celle d’une relation où par définition à l’intersection d’un n-uplet et d’un attribut on a exactement une valeur et rien d’autre, or Null n’est pas une valeur mais un marqueur, ce qui fait qu’il est de facto interdit de séjour au sein des relations. Le pseudo-prédicat de cette structure est le suivant :

Le produit ProduitComposéId est peut-être composé du produit ProduitComposantId.

Ce qui du point de vue de la logique bivalente n’est pas possible et nécessite de s’embarquer vers les terrae incognitae de la logique trivalente (voire quadrivalente...), pleine de chausse-trapes (par exemple p SI ET SEULEMENT SI p n’est plus une tautologie, le théorème de Heath n’est plus valide, etc.), et propre à inhiber les systèmes experts des SGBD SQL...

A cette occasion je rappelle que les auteurs de la norme SQL se sont fait piéger (et plus ou moins gentiment moquer...), en écrivant que la valeur de vérité UNKNOWN (Cf. le type BOOLEAN) et Null sont la même chose ! (Ils ont tout simplement oublié que, contrairement à Null, UNKNOWN est une valeur...)


Accessoirement, le jour où la règle de gestion proposée par aminnio évoluera, en ce sens qu’un produit pourra être composé de plusieurs produits, dans le cas de la version de nico84 il suffira d’ajouter l’attribut ProduitComposantId dans la composition de la clé de la table COMPOSITION, d'où une maintenance pour le moins réduite.