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

[CinePhil]

pour être certain d'avoir bien compris, la clé primaire de la table PRODUIT devient-elle clé primaire de la table COMPOSANT

Oui, avec des cardianlités (0,1 - 0,n). Et comme indiqué dans la structure des tables que j'ai donnée, la clé primaire de la table Composant est l'identifiant du composant, pas du produit dont il est composant.

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

Dans la base sur laquelle je travaille le composé à la même forme que le composant , je l'ai appellé REF_PRODUIT

REF_PRODUIT a une signification et est potentiellement alphanumérique, c'est donc une mauvaise clé !
Si tu en as la possibilité, tu devrais ajouter un identifiant artificiel, jamais présenté à l'utilisateur et utile seulement pour la BDD et les programmes, de type entier et auto-incrémenté dans la table des produits et de type entier pour la table des composants, sans auto-incrémentation puisqu'il s'agit d'une clé étrangère.

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 ?

Non, voir ce que j'ai écrit plus haut et qui me semblait pourtant clair dans la description de mes tables !

Que se passe-t-il lorsque qu'un composant devient un composé

Un composant est un produit donc comme tout produit il peut être composant et/ou composé.

Exemple...
Produit (prd_id, prd_reference, prd_nom...)
1, 'O122416', 'Ordinateur de bureau Machin'...
2, 'U500456', 'Unité centrale Machin truc'...
3, 'CM12547', 'Carte mère Athlon bi-pro 64...'...

Composant (cps_id_produit_composant, cps_id_produit_compose)
3, 2
2, 1

=> La carte mère est un composant de l'unité centrale qui est composant de l'ordinateur.

[patmar83]

merci beaucoup pour ces explications, je vais juste retravailler sur le problème du type de clé pour mettre une clé numérique comme tu me le suggères

[fsmrel]

Bonjour à tous,

La bonne modélisation est celle que j'ai donnée dans mon précédent message avec une table associative.
À 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.

Absolument !


Pour ceux qui aiment bien les dessins et les correspondances, voici le MCD Merise (dans lequel j’ai ajouté un attribut Quantite porté par l’association-type COMPOSER) :



Je passe au MCD E/R (façon Power AMC) afin de produire par la suite un MLD correspondant au vôtre :



Dans ces conditions, le MLD produit par Power AMC est le suivant :



Ou pour ceux qui préfèrent la notation E/R :


Power AMC permet de créer des synonymes, ce qui est bien pratique quand il y a beaucoup d’objets et que les pattes se croisent : grâce aux synonymes graphiques on y voit plus clair. Je m’en sers ici seulement pour avoir une présentation équivalente à celle d’ACCESS :



Pour la petite histoire, le montage ACCESS passe par les phases suivantes :

1) Affichage des tables :




2) Lien d’intégrité référentielle Composant vers PRODUIT :



Au résultat :




3) Lien d’intégrité référentielle Composé vers PRODUIT :




Au résultat :




Comme disait Hubuc :

...