MCD à MLD identifiants relatifs

Version imprimable

07/01/2011, 07h06
dlgdev

1 pièce(s) jointe(s)

MCD à MLD identifiants relatifs

Bonjour,
j'ai un petit soucis pour passer de mon MCD à mon MLD puis à mon MPD. Voilà tout se situe au niveau des identifiants relatifs :
Pièce jointe 71387
Pour la table catégorie pas de soucis,
pour la table ss_catégorie nn plus car sa clé primaire devient code_c et code_sc avec code_c clé étrangère en référence à catégorie. C'est pour produit et ligne__cmde que le problème se pose :
pour produit :
Clé primaire : code_c, code_sc, ref_p ?
si oui produit.code_c a pour référence code_c de catégorie ou de ss_catégorie ??
de plus, pour ligne_cmde :
clé primaire : num_l, ref_p ou num_l, ref_p, code_c, code_sc ??
concernant les références comment faire ?

Merci
07/01/2011, 09h53
gototog

Oui, sa clef primaire est ref_p, #code_sc, # code_c
#Code_C a pour référence sous catégorie (elle meme liées a catégorie donc c'est bon)

Pour la ligne de commande, sa clef primaire est num_l, #num_d car elle est liée a produit par une CIF, parcontre, la clef étrangère de ligne_cmde est #(ref_p, #code_sc, # code_c)
j'espère avoir bien compris tes questions
07/01/2011, 13h20
dlgdev

Il me semble que tu as bien compris ma question. Pour ligne de commande effectivement, je m'étais trompé dans la rédaction, sa clé primaire est bien :
num_l, #num_d comme tu le dit.
Par contre, ligne de commande lié à produit par 1,1 donc la clé étrangère que contient ligne_cmde sera :
#(ref_p, #code_sc, # code_c)
avec ref_p référence à produit
#code_sc référence à code_sc de produit
#code_c référence à code_c de produit
c'est bien cela ?
dans ce cas au niveau du MPD j'aurai dans ma table ligne_cmde les champs :
de mon entité initiale et
ref_p, code_c, code_sc en clé étrangère ?

Merci à toi.
Etant étudiant c'est la 1ère fois que je suis confronté à ce genre de cas. Cas que j'ai facilité car mon entité document est en réalité l'entité mère d'une spécialisation ayant 3 filles.
07/01/2011, 15h30
gototog

Citation:

Envoyé par dlgdev

Par contre, ligne de commande lié à produit par 1,1 donc la clé étrangère que contient ligne_cmde sera :
#(ref_p, #code_sc, # code_c)
avec ref_p référence à produit
#code_sc référence à code_sc de produit
#code_c référence à code_c de produit
c'est bien cela ?

Oui, c'est ca :)

Citation:

Envoyé par dlgdev

dans ce cas au niveau du MPD j'aurai dans ma table ligne_cmde les champs de mon entité initiale et
ref_p, code_c, code_sc en clé étrangère ?

Oui!

Personnelement pour ce genre de cas, je raisonne en simulant mentalement les futurs enregistrement de la base de donées, et c'est ici le seul moyen pour que ta ligne de commande sache à quel produit elle réfère.

Edit pour en dessous: C'est noté pour l'ordre, je ne savais pas.

Bonjour,

Citation:

Envoyé par gototog

sa clef primaire est ref_p, #code_sc, # code_c

L’ordre des attributs dans la clé a son importance notamment au niveau physique (indexation, partitionnement et autres joyeusetés), il est donc recommandé qu’elle soit la suivante : {code_c, code_sc, ref_p}.

Par ailleurs, un produit a sa propre référence, dont la valeur est du ressort de l’utilisateur : au niveau conceptuel il faudrait prévoir un identifiant alternatif composé d’un attribut du genre Reference_Utilisateur.

D’où au niveau logique :
Code:

1 2 3 4 PRODUIT {Code_c, Code_sc, Ref_p, Reference_Utilisateur, Lib_p, Cout_p, Mo_p, Autre_p} PRIMARY KEY {Code_c, Code_sc, Ref_p} UNIQUE {Reference_Utilisateur} FOREIGN KEY {Code_c, Code_sc} REFERENCES SS_categorie ;

07/01/2011, 16h08
dlgdev

Qu'entendez-vous par cela :

Citation:

Envoyé par fsmrel

Bonjour,

Par ailleurs, un produit a sa propre référence, dont la valeur est du ressort de l’utilisateur : au niveau conceptuel il faudrait prévoir un identifiant alternatif composé d’un attribut du genre Reference_Utilisateur.

A quoi va-t-il servir ?

Merci
07/01/2011, 16h49
fsmrel

Citation:

Envoyé par dlgdev

Qu'entendez-vous par cela :

Citation:

Envoyé par fsmrel

Par ailleurs, un produit a sa propre référence, dont la valeur est du ressort de l’utilisateur : au niveau conceptuel il faudrait prévoir un identifiant alternatif composé d’un attribut du genre Reference_Utilisateur.

A quoi va-t-il servir ?

Votre attribut Ref_p est utilisé pour l’identification relative, donc ses valeurs sont relatives à la paire {Code_c, Code_sc} : il prend les valeurs successives 1, 2, 3, etc., relativement à chaque valeur prise par cette paire : l’attribut Ref_p est interne à votre système et ne concerne pas l’utilisateur, lequel a quand même besoin de gérer ses propres références de produits (celles que les clients ou fournisseurs connaîtront), d’où l’attribut ad-hoc Reference_Utilisateur qu'il peut structurer et valoriser comme bon lui semble.
07/01/2011, 16h54
dlgdev

je comprend mieux maintenant, l'utilisateur pourra utiliser sa propre notation. Cependant, j'avais prévu cela directement sur le champ ref_p lui même. Que me conseillez-vous ? Passer obligatoirement par "Ref_user" ?
07/01/2011, 18h24
fsmrel

Concernant la distinction entre identifiants naturels (par exemple Ref_user) et artificiels, reportez-vous à ces réflexions concernant les clés et méditez ce qu’a écrit le grand Yves Tabourier.

D’autre part, l’attribut ref_p n’est qu’un des composants de la clé K = {code_c, code_sc, ref_p} de la table PRODUIT et n’a pas à garantir l’unicité des valeurs de K. Si les valeurs de ref_p étaient uniques, K ne respecterait pas la règle d’irréductibilité des clés candidates et devrait être réduite à {ref_p}.

Si donc vous utilisez l’identification relative, vous êtes obligé d’en passer par l’utilisation en plus d’une clé alternative telle que {Ref_user}. Si vous n’utilisez pas l’identification relative, de toute façon vous serez obligé d’avoir une clé primaire singleton (mono-attribut), non significative, gérée par le système ({ref_p} par exemple), plus une clé « utilisateur », à savoir {Ref_user}.

Si dans vos traitements vous avez besoin de connaître les codes-catégories pour des objets en relation avec les produits (commandes par exemple), l’identification relative est intéressante, sinon vous pouvez vous contenter d’une identification absolue. Voyez le 4e exemple du paragraphe1.7 ainsi que l’annexe F de l’article « Bases de données relationnelles et normalisation ».
07/01/2011, 19h08
dlgdev

Merci en tout cas pour ces informations complémentaires..
08/01/2011, 11h35
CinePhil

Pourquoi donc mettre en oeuvre une identification relative dans le cas du produit ? 8O
Dans les entreprises, un produit est un produit avec sa référence propre, quelle que soit la catégorie à laquelle il appartient.
Et comme on peut vouloir réorganiser les catégories sans pour autant changer la référence du produit, ni supprimer les produits qui appartiennent à la sous-catégorie si on supprime celle-ci, il me semble que ref_produit est une clé candidate qui se suffit à elle même.
Par contre, comme cette référence pourrait être du style 'XZ8124', elle constitue une mauvaise clé pour la table et doit être accompagnée d'une clé de type entier auto-incrémenté et utile uniquement à la BDD, jamais présentée à l'utilisateur.

Selon moi, tu as la règle de gestion suivante :
" Un produit appartient à une seule sous-catégorie et une sous-catégorie peut accueillir plusieurs produits. "

Ce qui donne le morceau de MCD suivant :
Produit -1,1----Appartenir----0,n- Sous-categorie

Tables :
Sous-categorie (sc_id, sc_libelle)
Produit (prd_id, prd_id_sous_categorie, prd_reference, prd_nom...)

Examinons maintenant l'identification relative de la sous-catégorie par rapport à la catégorie...
Elle peut être justifiée par le fait que sans catégorie mère, la sous-catégorie n'a pas de raison d'exister. Laissons là et complétons le MCD précédent :
Produit -1,1----Appartenir----0,n- Sous-categorie -(1,1)----Appartenir----1,n- Categorie

Ce qui modifie et complète les tables de la façon suivante :
Categorie (cat_id, cat_libelle)
Sous-categorie (sc_id_categorie, sc_id, sc_libelle)
Produit (prd_id, prd_id_categorie, prd_id_sous_categorie, prd_reference, prd_nom...)

Voyageons maintenant vers la ligne de commande...

Cette ligne de commande ne devrait-elle pas être identifiée relativement à une commande ? :?
Et un produit peut n'avoir pas encore été vendu donc la cardinalité minimale est de 0 côté produit !

MCD :
Commande -1,n----Composer-(1,1)- Ligne_commande -1,1----Concerner----0,n- Produit

Ce qui donnerait les tables suivantes :
Produit (prd_id, prd_id_categorie, prd_id_sous_categorie, prd_reference, prd_nom...)
Commande (cmd_id, cmd_id_client, cmd_numero, cmd_date...)
Ligne_commande (lc_id_commande, lc_num_ligne, lc_id_produit...)

Qu'est-ce que l'entité "Document" ? S'agit-il de la commande ? Alors appelle la "Commande" !
07/03/2011, 12h13
dlgdev

merci de tes conseils. J'en ai pris compte car tu as tout à fait raison.
Concernant ta question :

Citation:

Qu'est-ce que l'entité "Document" ? S'agit-il de la commande ? Alors appelle la "Commande" !

En réalité, c'est une spécialisation Document entité mère
Facture, Devis et Bon de commande entités filles.
07/03/2011, 13h47
CinePhil

Citation:

Envoyé par dlgdev

En réalité, c'est une spécialisation Document entité mère
Facture, Devis et Bon de commande entités filles.

Ce qui veut dire que, d'après ton MCD, une ligne de commande peut faire partie d'un devis ou d'une facture ! :aie:
Ce serait acceptable si la ligne figurant dans le devis est reproduite fidèlement dans la commande et ne subit pas plus de modification dans la facture. Mais s'il y a des négociations commerciales entre temps qui engendrent une modification, alors celle-ci est répercutée de la facture vers la commande et vers le devis !