Bonsoir,
Je n’avais pas regardé le MLD. Il est vrai que Nanci (RIP) présente différentes façons de traduire l’héritage dans le MLD, cf. son ouvrage Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), page 251 (« Prise en compte des sous-types du MCD/MOD »).
A son tour, WinDesign offre certainement la possibilité de choisir (comme le fait PowerAMC).
Nino, vous avez manifestement fait le choix correspondant à la solution 2 de l’ouvrage, voire à un mix (surprenant) : il faut à tout prix vous caler totalement sur la solution 1, afin d’éviter les redondances funestes dénoncées par Paprick.
Pour le fun :
Chris Date dit à sa façon qu’il faut éviter ce genre de redondance, je vous renvoie au chapitre 14 “The principle of Orthogonal Design” de son ouvrage Database Design and Relational Theory - Normal Forms and All That Jazz pour mieux comprendre ce qui suit, mais attention, c’est du brutal, commencez avec du doliprane à portée de main ! :
Etant données deux
relvars (non nécessairement distinctes)
R1 et
R2, et la
dépendance de jointure ⁎{
X1, …,
Xn} irréductible pour
R1. Soit
Xi (1 ≤
i ≤
n) et un ensemble (éventuellement vide) de noms alternatifs d’attributs sur la projection, disons,
R1X de
R1 sur
Xi, faisant correspondre
R1X à, disons,
R1Y, où
R1Y a le même en-tête qu’un sous-ensemble
Y de l’en-tête de
R2 (
Y étant distinct de
Xi, si
R1 et
R2 ne font qu’un). Soit en outre
R2Y la projection de
R2 sur
Y. Alors
Le Principe de la Modélisation Orthogonale est violé par
R1 et
R2 si et seulement si il existe les conditions de restriction
c1 et
c2 non identiquement fausses, telles que soit vérifiée la dépendance d’égalité (
R1Y WHERE
c1) = (
R2Y WHERE
c2).
C’est clair, n’est-ce pas ? 
Paprick a noté que la clé primaire des tables CHAUSSURE et TEXTILE est une surclé qui viole le principe d’irréductibilité des clés candidates, à savoir que la clé primaire doit être seulement le singleton {ID_ARTICLE}.
En ayant fourni la paire {ID_ARTICLE_HIER_3, ID_ARTICLE}, WinDesign a commis une erreur grossière.
Marque d’un article :
Il devrait y avoir une entité-type MARQUE_ARTICLE dans le MCD : elle est absente, ainsi que dans le MLD. Par contre dans le MLD, la table ARTICLE est dotée d’une clé étrangère {ID_MARQUE_ARTICLE} ! Il faut mettre en oeuvre cette entité-type et y expulser l’attribut marque_article, car à défaut la 3NF est violée (présence de la dépendance fonctionnelle irréductible {id_marque_article} → {marque_article}, cf. ici).
Envoyé par
nino04
je pensais qu'il n'avais pas besoin de faire référence a un client vu que l'entité fait référence a une facture_vente.
Dans votre MCD, c’est FACTURE_VENTE qui fait référence à REGLEMENT_CLIENT : tel Dagobert, remettez ça à l’endroit ! (permutez les cardinalités). Même chose pour les règlements aux fournisseurs.
Etant donné qu’un client peut régler en plusieurs fois, il faut effectivement prévoir un attribut pour le montant du règlement, mais nommez-le montant_reglement_client plutôt que montant_paiement_fournisseur !
Envoyé par
nino04
et que celle ci faisant également référence a un ou plusieurs clients
Que nenni, une facture_vente ne se partage pas entre clients ! J’ai l’impression que vous lisez parfois les cardinalités dans le mauvais sens...
Envoyé par
nino04
j'ai rajouter ligne facture de cette manière pour les client je devrais surement refaire la même chose pour facture_achat
Oui, il faudra le faire. Ceci dit, vous pouvez modéliser les choses ainsi :
[ARTICLE]---0,N---(LIGNE_FACTURE_VENTE)---1,N---[FACTURE_VENTE]
[ARTICLE]---0,N---(LIGNE_FACTURE_ACHAT)---1,N---[FACTURE_ACHAT]
Où les associations sont évidemment porteuses de l’attribut quantite.
Entité-type CARTE_FIDELITE
Je répète : Supprimez l’attribut id_carte, sinon vous signifiez qu’un client peut avoir plus d’une carte...
Répondre avec citation
Si le concepteur souhaite cette duplication, qu'il la modélise au niveau du MCD ! 
Partager