Discussion :

[patmar83]

je viens de lire le tuto concernant les relation reflexive
Dans un des paragraphes l'auteur concernant les relations 0n-0,1 indique que certains SGBD (access par exemple ) ne supportent pas cette modélisation, il faut dédoubler les tables
Peut-on m'expliquer exactement ce que cela signifie car je suis dans ce cas avec une table PRODUIT- et une relation réflexive composé, composant

merci

[CinePhil]

je viens de lire le tuto concernant les relation reflexive

De quel tuto parles-tu ? Un petit lien ?

Dans un des paragraphes l'auteur concernant les relations 0n-0,1 indique que certains SGBD (access par exemple ) ne supportent pas cette modélisation, il faut dédoubler les tables.

D'une manière générale, la bonne manière d'implémenter une association aux cardinalités (0,n - 0,1) est de créer une table associative, comme lorsque les cardinalités sont (0,n - 0,n). Que ce soit dans Access ou dans un autre SGBD !

Peut-on m'expliquer exactement ce que cela signifie car je suis dans ce cas avec une table PRODUIT- et une relation réflexive composé, composant

J'imagine qu'il s'agit de mettre en oeuvre une règle de gestion ressemblant à ce qui suit ?
" Un produit peut être composé de plusieurs produits et un produit ne peut être composant que d'un seul produit. "

MCD :
Produit -0,n----Composer
|------------(0,1)----------|

Tables :
Produit (prd_id...)
Composant (cps_id_produit_composant, cps_id_produit_compose)

[patmar83]

bonjour et merci pour la réponse
En vérité il ne s'agit pas d'un tuto mais d'un texte lu dans les FAQ Merise MCD

Pour ce qui est de ton analyse c'est tout à fait ce que je cherche à faire
Pourrais tu me confirme les clé dans la table composant
Dois je construire une table avec deux clé id_composant ou id_composé ou bien je ne prends qu'une seule clé
merci

[f-leb]

bonsoir,

je suppose que tu parles de cette mention qui figure dans la FAQ : Comment transformer une relation réflexive ?

Attention certains SGBD (Access par exemple) ne supportent pas cette modélisation, il faut alors dédoubler ces tables.

Pour reprendre l'exemple de la FAQ, dans la fenêtre des Relations d'Access:

Article-1------∞-Nomenclaturer-∞-------1-Article_1

où Article_1 est obtenu en ajoutant une deuxième fois la table Article.

Sous Access, ça se passe comme ça

[CinePhil]

J'ai posté ce MCD :

Produit -0,n----Composer
|------------(0,1)----------|

J'ai hésité à le faire de cette façon :
Produit -0,n----Composer----(0,1)- Produit

Dans cette autre représentation, il y a deux fois l'entité Produit et cela correspond à la manière de représenter ce genre d'association dans la fenêtre des relations d'Access. On met deux fois la table Produits, ce qui ne veut pas dire que la table existe réellement deux fois.

Par contre, si la solution préconisée par Access consiste à ajouter une colonne à la table Produit pour y matérialiser la clé étrangère, ce n'est pas conforme aux bonnes pratiques !

Article-1------∞-Nomenclaturer-∞-------1-Article_1

Dans le Schéma de f-leb, "Nomenclaturer" devrait représenter une table physique dans la BDD Access ; elle correspondrait à ma table Composant.

En ce sens, je ne suis pas du tout d'accord avec ce que préconise la FAQ Merise !

Pour une relation réflexive 0n – 0,1
Elle devient un attribut clé étrangère dans la table transformée, attribut éventuellement suffixé par le rôle de la patte 0,1. Cette clé étrangère réfère à la clé primaire de cette même table.

Ceci conduit à peupler la table unique de bonshommes NULL.
La bonne modélisation est celle que j'ai donnée dans mon précédent message avec une table associative.

MCD :
Produit -0,n----Composer
|------------(0,1)----------|

Tables :
Produit (prd_id...)
Composant (cps_id_produit_composant, cps_id_produit_compose)

À noter que comme il s'agit de cardinalités (0,1 - 0,n), la clé primaire est mono-colonne, contrairement aux cardinalités (0,n - 0,n) où la clé primaire est bi-colonnes.

EDIT
Je viens de proposer une correction de cette FAQ.

[patmar83]

merci pour ces explications, mais pour être certain d'avoir bien compris, la clé primaire de la table PRODUIT devient-elle clé primaire de la table COMPOSANT
Dans la base sur laquelle je travaille le composé à la même forme que le composant , je l'ai appellé REF_PRODUIT

J'aurais donc dans mon cas
Une table produit PRODUIT (# REF_PRODUIT, ......)
Une table composant COMPOSANT (#REF_PRODUIT, REF_PRODUIT_COMP,....)

REF_PRODUIT_COMPOSANT représentant la référence du produit composant
Est-ce exact ?
Que se passe-t-il lorsque qu'un composant devient un composé
La structure proposée permet-elle de traiter ce cas
merci