MCD Gestion d'un magasin de vente de détails

Version imprimable

30/05/2020, 17h40
nino04

4 pièce(s) jointe(s)

MCD Gestion d'un magasin de vente de détails
bonjour à tous,
Voila j'ai décider de réaliser un mcd d'un magasin de vente de détails dans le cadre de mon cours d’ingénieurie logiciel.

le système d'information en question concerne un petit magasin de vente de détails spécialisé dans la vente de chaussure et de vêtement.Celui ci désire un moyen de gestion informatisé permettant de gérer son stock, ses ventes, et ses commandes.

Le projet en question doit permettre l'achat d'article en magasin ou sur une plateforme.

Un système de solde est disponible grâce à une carte de fidélité qui ne peut être posséder que par un et un seul client. cette carte de fidélité à pour but d'emmagasiner les points et de fournir par tranche de 500 point un code de réduction de 20% sur n'importe quel article du magasin.

Le magasin en question effectue également des commandes auprès de fournisseur et gère ses commandes.

Données du client:
- un client achète un ou plusieurs article et un article peut être acheté par un ou plusieurs clients
- un client possède au plus une carte de fidélité et une carte de fidélité peut être posséder par un et un seul client
- un client peut avoir 0 ou plusieurs factures et une facture correspond à un seul client
- une facture comprend une ou plusieurs lignes de facture et une ligne de facture correspond à une et une seule facture
- une facture correspond à une et une seule vente effectue( si 2 ventes effectuée >> 2 facture)
- une vente effectuée correspond à une et une seule facture et une facture correspond à une et une seule vente
- une vente comprend une ou plusieurs lignes de ventes et une ligne de vente correspond a une seul vente
MCD Associé:

Pièce jointe 569014

Données de l'article
- un article doit etre un vetement ou une chaussure
- un article peut etre présent une ou plusieur fois en stock
- dans une ligne de facture, il ne peut y avoir qu'un seul article
- Un article peut ne pas etre présent dans une ligne ou être présent plusieur fois
- un article correspond à une ou plusieurs lignes de vente
MCD associé:
Pièce jointe 569018

Données de commande auprès de fournisseur:
- un fournisseur possède 0 ou plusieur fois le produit
- une commande comprend une ou plusieur lignes
- une ligne de commande concerne une et une seule commande
- une livraison comprend une ou plusieur lignes
- une ligne de livraision corrspond a une seule livraison
- un produit peut etre une fois ou plusieur fois dans le catalague
- pour un produit, il existe 1 ou plusieur fournisseur (oui, 2 fournisseur peuvent vendre le même produit)
- un founisseur possède 0 ou plusieur fois le produit
Pièce jointe 569022

MCD FINAL:
Pièce jointe 569024

j'espere vous avoir fournit suffisamment d'information, maintenant question:
1) Concernant les article est ce que le faite de mettre l'article en héritage exclusif d'une chaussure ou d'un vêtement peux t'elle se faire ainsi ?( vraiment pas sur)
2) concernant la carte de fidélité est ce que je dois mettre la propriété code de réduction dans l'entité d’après moi oui mais je vois pas trop comment faire ?
3) voyez quelque chose de choquant une erreur de redondance ou autre que je ne vois pas ? (^^ deso c'est une question bonus mais j'aimerais vraiment être sur qu'il n'y a pas d’erreur)

merci d'avoir lu jusqu'ici et n’hésiter pas a répondre :D

bien a vous,
31/05/2020, 04h36
fsmrel

Bonsoir nino04,

Je n'ai pas tout regardé de votre MCD, mais il y a déjà quelques observations à faire.

Citation:

Envoyé par nino04

Concernant les article est ce que le faite de mettre l'article en héritage exclusif d'une chaussure ou d'un vêtement peux t'elle se faire ainsi ?

Oui, la représentation est correcte dans la mesure où pointure, modèle et solde sont des propriétés spécifiques des chaussures tandis que taille et type de vêtement sont des propriétés spécifiques des vêtements. Si le magasin ne vend que des chaussures et des vêtements, le symbole « XT » présent dans le triangle est pertinent et représente une contrainte de partitionnement (« X » = exclusion : un article ne peut pas être à la fois chaussure et vêtement ; « T » = totalité : il n’y a pas d’autres articles que des chaussures et des vêtements).

(Q1) Quel rôle jour l’attribut type_article de l’entité-type ARTICLE ?

Vous avez mis en oeuvre une bijection entre FACTURE et VENTE : l’usage est d’éviter cela (au stade SQL vous risquez de mauvaises surprises). Autrement dit, il est préférable qu’une entité-type absorbe l’autre (par exemple, les propriété de VENTE sont rapatriées dans FACTURE). Lors du passage à SQL, il ne faudra pas oublier la contrainte d’unicité concernant par exemple les attributs num_facture, num_ticket, code_barre_vente qui sont des identifiants alternatifs.

les entités-types LIGNE_FACTURE et LIGNE_VENTE sont toutes deux porteuses d’un attribut relatif à la quantité (quantite_ligne_facture et quantite_ligne_vente). On ne peut s’empêcher de poser les questions suivantes :

(Q2) Pour une facture et une vente données, il n’y a aucune contrainte entre les lignes de facture et les lignes de vente ? Par exemple, le nombre de lignes de vente peut être différent du nombre de lignes de facture, c’est bien ça ?

(Q3) Sinon, pour une facture et une vente données, les valeurs prises par quantite_ligne_facture sont bien indépendantes des valeurs prises par quantite_ligne_facture ?

Le MCD comporte une boucle CLIENT, FACTURE, LIGNE_FACTURE ARTICLE, CLIENT. Autrement dit, un client peut être facturé pour un article qu’il n’a pas acheté (un classique !). Il y a une contrainte d’inclusion à prévoir, impliquant les associations ACHETER et CORRESPOND (celle du côté ARTICLE...). On pourra en reparler à l’occasion du passage au MLD.

Selon le MCD, une ligne de vente peut faire référence à plus d’un article.

(Q4) Dans ces conditions, quelle signification donner à l’attribut quantite_ligne_vente ? On a des quantités (hétérogènes) de quoi ?

De l’identification relative :

Pour des raisons sémantiques et surtout en prévision du passage à SQL, préférer identifier CARTE_FIDELITE relativement à CLIENT, LIGNE_FACTURE relativement à FACTURE et LIGNE_VENTE relativement à VENTE (ou plutôt à FACTURE si FACTURE absorbe VENTE).

Citation:

Envoyé par nino04

concernant la carte de fidélité est ce que je dois mettre la propriété code de réduction dans l'entité ?

Si 500 points donnent lieu à 20% de réduction, une fonction devrait suffire : à voir en fonction du SGBD que vous utilisez.

On retrouve au niveau des commandes le problème de boucle impliquant les factures. Là aussi, prévoir une contrainte d’inclusion. Je développerai un peu plus tard.

Votre association CATALOGUE n’est pas valide, puisque la ligne de commande y joue un rôle équivalent à celui de l’article et du fournisseur, or le catalogue n’est pas fonction de la ligne de commande !

Envisagez de trans former l’association en entité-type avec identification relative :

[ARTICLE]---1,N---(X)---1,1(R)---[CATALOGUE]---1,1(R)---(Y)---0,N---[FOURNISSEUR]

Puis établissez une association entre CATALOGUE et LIGNE_COMMANDE :

[CATALOGUE]---0,N---(Z)---1,1---[LIGNE_COMMANDE]

D’une façon générale, n’utilisez pas deux fois le même nom pour les associations.

A suivre.
31/05/2020, 13h24
Paprick

Bonjour,

Je poussois les remarques de fsmrel en insistant sur quelques points :
1) Effectivement Facture et Vente doivent être fusionnées dans la mesure où les cardinalités 1,1---1,1 sont vérifiées : d'ailleurs, je suis surpris que Win'Design autorise ça... :calim2:
2) Les associations "tripattes" catalogue et existe ne sont pas maitrisée. La décomposition de catalogue proposée par fsmrel est d'autant plus la bien-venue que vous avez déjà prévu un id_catalogue qui peut vous éviter l'identification relative (même si je préfère la solution de fsmrel qui rend alors inutile cet id_catalogue).
3) Pour l'association "existe", une décomposition du même type vous permettra de mieux maitriser les cardinalités. J'ai déjà du mal à comprendre qu'il puisse exister plusieurs plusieurs articles pour une même ligne_vente... :koi:
4) Vous avez fait le choix de rajouter des id_ dans toutes les classes d'entités, y compris celles qui pourraient s'en passer : je ne rentrerai pas dans ce looooong débat sur lequel je ne suis pas totalement d'accord avec mes collègues contributeurs sur ce site :mouarf:, mais avec cette option vous ne pouvez pas faire l'économie de la définition de clés alternatives (futurs index) en déclarant "UNIQUE" les rubriques concernées (num_facture, num_ticket, num_carte, ...). Dans la même veine, il faut prévoir une référence article, car dans la logique que vous avez choisie, id_article ne correspondra pas à une information du SI.

Il doit y avoir plein d'autres choses à verifier, mais commencez par ça !
31/05/2020, 20h55
nino04

1 pièce(s) jointe(s)

bonjour à vous,
et merci de vos réponse,

Citation:

Envoyé par fsmrel

(Q1) Quel rôle jour l’attribut type_article de l’entité-type ARTICLE ?

Aucun effectivement a la base cette propriété étais la pour pour définir le type d'article( chassure ou vetement) mais je me suis rendu compte que le magasin ne vendait que des chaussures et des vêtements et que les propriétés de chacune étaient différente. Ainsi j'ai mit chaussure et vêtement en héritage ac leur propriétés propre a chacune
ex: vetement ==> taille {XS,S,M,L,XL} et type_vetement{pull, sweatshort,...}
chaussure ==> pointure{36,36.5,...,46}
Ainsi je pense qu'il est préférable de supprimer la propriété type_article et de garder les entités chaussure et vêtement. ( c’était un oubli de ma part)

Citation:

Q2 :Pour une facture et une vente données, il n’y a aucune contrainte entre les lignes de facture et les lignes de vente ? Par exemple, le nombre de lignes de vente peut être différent du nombre de lignes de facture, c’est bien ça

q2:alors je me suis effectivement tromper, la ligne de facture est la même que la ligne de vente j'ai donc décider d'enlever l'entité ligne de vente et l'entité vente , cependant il me semblait nécessaire de garder un num de ticket et un codebare vente, ainsi j'ai rajouté ces propriété dans l'entité facture !

Citation:

Q3: Sinon, pour une facture et une vente données, les valeurs prises par quantite_ligne_facture sont bien indépendantes des valeurs prises par quantite_ligne_facture ?

q3: ainsi il me semble avoir repondu a cette question égalemePièce jointe 569189nt

Citation:

remarque: Selon le MCD, une ligne de vente peut faire référence à plus d’un article.

remarque: oui, c'est une erreur de ma part. C'est a dire que une lignes de ventes ne peut contenir qu'un seul articles et la vente peux contenir plusieurs ligne de vente ou chaque ligne a une quantité spécifié.

je pense également répondre la la Q4 par la même occasion.

Pièce jointe 569694
31/05/2020, 23h33
Paprick

Bonsoir,

Citation:

Envoyé par nino04

Pour le catalogues et les commandes j'ai essayer d'appliquer les changement cité ! dites moi ce que vous en pensez

Concernant l'identifiant de "Catalogue", il faut choisir entre "id_catalogue" et l'identification relative 1,1(R).
En effet, avec les identifiants relatifs, "id_article" et "id_fournisseur" feront partie de la clé primaire de "Catalogue" : "id_catalogue" est alors inutile et le rajouter provoque une surclé.

L'association "existe" pose toujours problème avec ses 3 pattes, et j'ai des doutes sur l'utilité de l'association "acheter", le lien étant assuré via la facture (ce qui remet en cause la contrainte d'inclusion).
Attention également à l'association "coïncide" qui n'a pas de sens en l'état :weird: : d'une façon générale les associations n-aires sont délicates à manipuler et nécessitent souvent la mise en œuvre de CIF.

Comme indiqué précédemment, "Vente" et "Facture" ne doivent faire qu'un : c'est une base essentielle pour que le modèle prenne une bonne tournure.

A suivre...
01/06/2020, 04h02
fsmrel
Bonsoir nino et Paprik,

Citation:

Envoyé par Paprick

Concernant l'identifiant de "Catalogue", il faut choisir entre "id catalogue" et l'identification relative 1,1(R).
En effet, avec les identifiants relatifs, "id_article" et "id_fournisseur" feront partie de la clé primaire de "Catalogue" : "id catalogue" est alors inutile et le rajouter provoque une surclé.

De fait, nino, il faut choisir. En l’état du MCD, au stade MLD la clé primaire de CATALOGUE sera le triplet {id_article, id_fournisseur, id_catalogue}, ce qui revient à dire que pour un article et un fournisseur donnés on pourra avoir plusieurs lignes dans la table CATALOGUE, ce dont on ne veut certainement pas. Donc :

— Soit vous conservez l’identification relative pour montrer que CATALOGUE n’est jamais qu’une entité-type associative, mais alors vous supprimez l’attribut id_catalogue, auquel cas la clé primaire de la table CATALOGUE se réduit correctement à {id_article, id_fournisseur} ;

— Soit vous n’utilisez pas l’identification relative et vous vous contentez de la modélisation :

[ARTICLE]---1,N---(X)---1,1---[CATALOGUE]---1,1---(Y)---0,N---[FOURNISSEUR]

Auquel cas la clé primaire de la table CATALOGUE sera le singleton {id_catalogue}, mais vous n’échapperez pas à la nécessité de définir la paire {id_article, id_fournisseur} comme clé alternative (contrainte d’unicité) de la table, sinon vous courrez le risque d’avoir à nouveau plusieurs lignes de catalogues pour un article et un fournisseur donnés. Ainsi, cette table sera nécessairement dotée de deux clés, une clé primaire et une clé alternative. Si je coiffe ma casquette de DBA, alors je conseille de conserver l’identification relative et de supprimer l’attribut id_catalogue (mises à jour moins lourdes et autres avantages).

En passant, dans votre dernier MCD, il faudra permuter les cardinalités pour les associations CONTIENT et COMPREND, sinon une ligne de facture contient plusieurs factures et une ligne de vente comprend plusieurs ventes…:D

Citation:

Envoyé par nino04

Le projet en question doit permettre l'achat d'article en magasin ou sur une plateforme.

Dans votre dernier MCD, vous précisez que tout achat d’article fait l’objet d’une ligne de vente, mais pas nécessairement d’une facture : les entités-types VENTE et FACTURE ne peuvent donc plus ne faire qu’une.

(Q5) Si je fais un achat dans le magasin, je ne demande pas forcément de facture. Mais si j’achète en ligne, j’aurai nécessairement une facture. Est-ce bien ainsi qu’il faut voir les choses ?

Quoi qu’il en soit, l’association COÏNCIDE n’est pas fameuse, elle est même maladroite...

Si les règles sont :

(RG01) Une vente fait référence à un client ;

(RG02) Une facture fait référence à un client.

Alors la modélisation ressemble à ceci :

[CLIENT]---1,N---(X)---1,1---[VENTE]

[CLIENT]---0,N---(Y)---1,1---[FACTURE]

Variante, où la facture est rattachée à la vente :

[CLIENT]---1,N---(X)---1,1---[VENTE]---0,1---(Y)---1,1---[FACTURE]

(Q6) Comment voyez-vous les choses ?

La contrainte d’inclusion est incomplète, il lui manque un pivot (l’entité-type qui doit y participer).

Pour aller dans le sens de Paprick, l’association EXISTE pose quelques problèmes...

En conjugaison avec la contrainte d’inclusion, elle signifierait que pour un triplet donné {article, ligne de vente, ligne de livraison}, il doit exister un client ayant acheté cet article.

Mais du fait des cardinalités 0,N dans la base de données, on pourra tricoter tout avec tout, par exemple :
```
CLIENT  ARTICLE  LIGNE_VENTE  LIGNE_LIVRAISON   
c1      a1       lve1         liv1 
c2      a1       lve1         liv2
c3      a2       lve1         liv3
...     ...      ...          ... 
```
Il est urgent que l’association EXISTE soit décomposée en deux binaires :

[ARTICLE]---0,N---(X)---1,1---[LIGNE_VENTE]

[ARTICLE]---0,N---(Y)---1,1---[LIGNE_LIVRAISON]

Pour aller dans le sens de Paprick, on doit pouvoir faire l’économie de l’association ACHETER. Supposons que cette association n’existe effectivement pas.

Puisque tout achat de l’article 'A' fait l’objet d’une ligne de vente :

Cette ligne de vente faisant référence au moins et au plus à un article, en l’occurrence l’article 'A', et au moins et au plus à une vente ;
Cette vente faisant référence au moins et au plus à un client :
Ce client a donc acheté l’article 'A'.

Dans ces conditions, l’association ACHETER est redondante et disparaît, quitte à renaître au stade SQL, mais seulement sous forme d’une vue (de jointure).

Bon y encore pas mal de boulot, mais ne vous découragez pas ! Une fois stabilisé le MCD, on pourra se pencher sur les histoires de salades de factures, de ventes et de livraisons...

D’un point de vue technique, il serait bon que vous revoyiez et approfondissiez le sens des cardinalités, que vous compreniez les conséquences de votre modélisation des associations COÏNCIDE et EXISTE. N’hésitez pas à ce sujet de vous (re)plonger-vous dans Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001).

Votre SGBD cible ?

1 pièce(s) jointe(s)

Bonsoir nino04 et Paprick,

Entité-type CLIENT : Nino, définir un attribut pour la référence client

Si vous répondez positivement à la question Q6, les factures en relation avec les ventes donnent lieu à la modélisation suivante (avec une contrainte d’inclusion) :

Pièce jointe 569418

Merci à Paprick de vérifier si je ne raisonne pas comme un tambour...

Code SQL généré par Looping (SGBD cible : SQL Server), avec suppression de ma part de la clé étrangère LIGNE_FACTURE_ARTICLE_FK et ajout en contrepartie de la clé étrangère LIGNE_FACTURE_LIGNE_VENTE_FK, histoire de garantir la contrainte d’inclusion :

CREATE TABLE ARTICLE(
   articleId INT IDENTITY,
   articleRef VARCHAR(12) NOT NULL UNIQUE,
   articleNom VARCHAR(48) NOT NULL,
   CONSTRAINT ARTICLE_PK PRIMARY KEY(articleId)
);

CREATE TABLE CLIENT(
   clientId INT IDENTITY,
   clientRef VARCHAR(12) NOT NULL UNIQUE,
   clientNom VARCHAR(48) NOT NULL,
   CONSTRAINT CLIENT_PK PRIMARY KEY(clientId)
);

CREATE TABLE VENTE(
   venteId INT IDENTITY,
   noTicket INT NOT NULL UNIQUE,
   venteDate DATE NOT NULL,
   clientId INT NOT NULL NOT NULL,
   CONSTRAINT VENTE_PK PRIMARY KEY(venteId),
   CONSTRAINT VENTE_CLIENT_FK FOREIGN KEY(clientId) REFERENCES CLIENT(clientId)
);

CREATE TABLE FACTURE(
   venteId INT,
   factureNo INT NOT NULL UNIQUE,
   factureDate DATE NOT NULL,
   CONSTRAINT FACTURE_PK PRIMARY KEY(venteId),
   CONSTRAINT FACTURE_VENTE_FK FOREIGN KEY(venteId) REFERENCES VENTE(venteId)
);

CREATE TABLE LIGNE_FACTURE(
   venteId INT,
   ligneFactureId INT IDENTITY,
   ligneFactureQte INT NOT NULL,
   articleId INT NOT NULL NOT NULL,
   CONSTRAINT LIGNE_FACTURE_PK PRIMARY KEY(venteId, ligneFactureId),
   CONSTRAINT LIGNE_FACTURE_FACTURE_FK FOREIGN KEY(venteId) REFERENCES FACTURE(venteId),
   CONSTRAINT LIGNE_FACTURE_ARTICLE_FK FOREIGN KEY(articleId) REFERENCES ARTICLE(articleId)
);

CREATE TABLE LIGNE_VENTE(
   venteId INT,
   articleId INT,
   ligneVenteQte INT NOT NULL,
   CONSTRAINT LIGNE_VENTE_PK PRIMARY KEY(venteId, articleId),
   CONSTRAINT LIGNE_VENTE_VENTE_FK FOREIGN KEY(venteId) REFERENCES VENTE(venteId)
   CONSTRAINT LIGNE_VENTE_ARTICLE_FK FOREIGN KEY(articleId) REFERENCES ARTICLE(articleId),
);

DROP CONSTRAINT LIGNE_FACTURE_ARTICLE_FK ;

ADD CONSTRAINT LIGNE_FACTURE_LIGNE_VENTE_FK 
    FOREIGN KEY (venteId, articleId)
        REFERENCES LIGNE_VENTE (venteId, articleId) ;

02/06/2020, 16h15
fsmrel

Bonjour,

Au sujet des livraisons.

L’association EXISTE présente dans votre MCD met en relation les articles, les lignes de vente et les lignes de livraison, en conséquence de quoi EXISTE est une association ternaire. Paprick vous a mis en garde, et pour abonder dans son sens, de mon côté je vous ai suggéré de décomposer la ternaire en deux binaires. En conséquence de quoi il n’y a plus aucun lien entre les lignes de vente et les lignes de livraison.

(Q7) Confirmez-vous qu’il n’y a aucun lien entre les lignes de vente et les lignes de livraison ? Sinon s’agit-il d’établir une sorte de système de lettrage entre livraisons et ventes ? Autre motif ?
02/06/2020, 20h49
nino04

2 pièce(s) jointe(s)

bonjour encore une fois je vous remercie pour vos réponses,

alors effectivement la réponse apportée en rapport a la Q6 est exactement ce qui m'a permis d'y voir plus clair, et j'ai ainsi procédé aux changement proposé, qui étais de scinder l'association ternaire en deux binaire.

Ainsi je me suis penché sur la Q7:

Citation:

Confirmez-vous qu’il n’y a aucun lien entre les lignes de vente et les lignes de livraison ? Sinon s’agit-il d’établir une sorte de système de lettrage entre livraisons et ventes ?

Alors oui effectivement il n'a pas de lien entre les deux. les modifications que j'ai faites vont dans ce sens également.
Pour ce résultat:
Pièce jointe 569730
et
Pièce jointe 569736

voila je pense que les modification apporté a la partie catalogue sont juste j'ai enlevé l'id catalogue et la clé est bien crée sur base de l'id_Fournisseur et de l'id_article.
J'espère avoir appliqué vos conseils de la bonne manière et merci pour l'ouvrage je m'y suis plongé a corps perdu car effectivement ayant peu d'expérience dans le domaine, il me faut et me faudra certainement du temps pour en comprendre toutes les subtilités de la méthode merise.

Voila il me semble avoir fait tous les changements cité plus haut en espérant ne pas avoir fait de bêtise :aie:
j'ai en plus de cela rajouté quelque chose d'important concernant un historique des prix de vente et comme celui ci est susceptible de changer j'ai décider de le faire en essayant d’éviter les erreurs que j'ai réalisées plus haut dites moi si cela vous semble juste ?
A présent il me semble que cela est correct
03/06/2020, 01h49
nino04

Citation:

Envoyé par fsmrel

Bonjour,

Au sujet des livraisons.

L’association EXISTE présente dans votre MCD met en relation les articles, les lignes de vente et les lignes de livraison, en conséquence de quoi EXISTE est une association ternaire. Paprick vous a mis en garde, et pour abonder dans son sens, de mon côté je vous ai suggéré de décomposer la ternaire en deux binaires. En conséquence de quoi il n’y a plus aucun lien entre les lignes de vente et les lignes de livraison.

(Q7) Confirmez-vous qu’il n’y a aucun lien entre les lignes de vente et les lignes de livraison ? Sinon s’agit-il d’établir une sorte de système de lettrage entre livraisons et ventes ? Autre motif ?

oui je confirme, pour l'instant les lignes de livraison et les lignes de ventes n'ont aucun lien et je ne pense pas que çà change. les lignes de livraison ne concerne que les livraison de commande au fournisseur.
j'ai quand même un doute rassuré moi, si jamais un client achète et veux se faire livrer? je pense que dans ce cas une entité livraison_domicile et ses propriété propre serait plus approprié une fois en relation avec l'entité client.
03/06/2020, 04h19
fsmrel

Bonsoir nino,

Partie Ventes :

Comme je l’ai écrit dans le post #6, l’association ACHETER devient redondante et doit disparaître.

La pointe de la flèche entre EXISTE et LIGNE_VENTE devrait atteindre LIGNE_VENTE, mais bon...

A propos du MLD : ça ne va pas. Dans le MCD, il y a une association entre FACTURE et VENTE, et dans le MLD, elle est entre FACTURE et CLIENT ! Bug !

Je ne sais pas si WinDesign sait traduire correctement les contraintes d’inclusion, quoi qu’il en soit dans le MLD, LIGNE_FACTURE ne doit pas faire référence à ARTICLE mais à LIGNE_VENTE...

Bref, avez-vous utilisé le dernier MCD pour produire le MLD ?

De toutes façons, c’est au stade SQL qu’on veillera à que tout soit bien en place. Les CREATE TABLE du post #7 sont conformes.

Citation:

Envoyé par nino04

les lignes de livraison ne concernent que les livraison de commande au fournisseur.

D’accord, je regarderai ça plus tard. Mais a priori, il y a une sorte de système de lettrage entre les commandes et les livraisons, puisqu’il s’agit des livraisons effectuées par les fournisseurs. Là encore, il faut éviter de mélanger les commandes faites au fournisseur F1 avec le livraisons faites par le fournisseur F2...

Les livraisons aux clients : on en reparlera quand on en aura terminé avec les livraisons faites par les fournisseurs.

Pour l’historique des prix de en-tête, on en reparlera aussi.

En passant, n’oubliez pas à liker les posts qui vous ont apporté quelque chose...
03/06/2020, 18h34
nino04

2 pièce(s) jointe(s)
Citation:

Envoyé par fsmrel

Bonsoir nino,

Partie Ventes :

Comme je l’ai écrit dans le post #6, l’association ACHETER devient redondante et doit disparaître.

La pointe de la flèche entre EXISTE et LIGNE_VENTE devrait atteindre LIGNE_VENTE, mais bon...

Pièce jointe 569950

Citation:

A propos du MLD : ça ne va pas. Dans le MCD, il y a une association entre FACTURE et VENTE, et dans le MLD, elle est entre FACTURE et CLIENT ! Bug !

Pièce jointe 569954

Voila j'ai appliquer les changement a présent je pense qu'il serait bien de faire un petit résumé des données présentes:

le but de ce mcd est bien de faire un site de vente en ligne des produit disponible en magasin.
Les articles proposé sont des chaussures ou du textile et rien d'autre n'est vendu dans le magasin.
Le magasin est capable de faire des commandes auprès de fournisseurs et de se faire livrer les articles commandés.

Concernant les ventes :
un article vendu fait l'objet d'une ligne de vente et l'ensemble de ces lignes de vente représente une vente ( ligne de vente * quantité ligne de vente)
le client peux recevoir soit un ticket soit une facture pr chaque vente effectué.
chaque vente est suivie d'un paiement ( bancontact, paypal)==>Q1: pas encore fait mais il faudrait surement cree une entité mode de paiement en relation a Client

concernant client:

le client peut posséder une carte de fidélité exclusivement réservé a une personne.
cette carte fournit a son détenteur un réduction de 2% sur le prix totale. ==> Q2: ceci peut être calculé donc pas d'entité dédié a la réduction il me semble?
un client peux recevoir pour ces achats une facture ou un ticket, si il prend le ticket il n'a pas besoin de facture et inversement ==>Q3: peut etre changer VENTE en TICKET_VENTE pour plus de compréhension?

concernant les mouvement des articles :

si un article est acheté diminution du nombre_produit dans les stock et inversement si commandé X article auprès du fournisseur +X article dans les stocks.
Pour cela je pense pouvoir récupérer les données du catalogue et des lignes de commandes pour le prix totale ou alors rajouter la propriété prix_total dans commandes?

vu que l'association acheter à été supprimé pour cause de redondance, je ne suis pas sur de pouvoir dire qu'un article est acheté par un ou plusieurs client ==>Q4: comment traduire cela

une vente peut etre effectué a un ou plusieu client?

il reste a faire :
- livraison au client suite a l'achat
- historique des ventes par le biais d'une entité identifée relative à ARTICLES pour savoir quel a été le prix de vente de l'article pdt une certaine periode et aussi une autre entité identifiée relativement a ARTICLE permettant de savoir quel était le taux de TVA applicable pendant une telle periode
  ARTICLE---0,N---(x)---(1,1)---HISTO_PRIX_VENTE_ART
  ARTICLE---0,N---(x)---(1,1)---HISTO_TVA_VENTE_ART je pense que c'est bon mais a vérifier
- mode de paiement par carte ou paypal
je cesserais jamais de le dire un grand merci pour l'aide apportée
bien a vous fsmrel et paprick
04/06/2020, 03h50
fsmrel
Bonsoir nino,

Citation:

Envoyé par nino04

Q1: pas encore fait mais il faudrait surement cree une entité mode de paiement en relation a Client

De fait, c’est ce qui se fait traditionnellement.

Citation:

Envoyé par nino04

Q2: ceci peut être calculé donc pas d'entité dédié a la réduction il me semble?

Non, pas d’entité-type à mettre en oeuvre. On peut par exemple créer une vue permettant de récapituler le total des ventes par client :
```
CREATE VIEW TotalParClient (clientId, totalVente)
AS 
SELECT clientId, SUM(prixTotal) AS prixTotal
FROM 
   (SELECT x.clientId, w.articleId, SUM(w.prixVenteHtva*z.ligneVenteQte) AS prixTotal    
    FROM   CLIENT AS x
      JOIN VENTE AS y ON x.clientId = y.clientId
      JOIN LIGNE_VENTE as z ON y.venteId = z.venteId
      JOIN ARTICLE as w ON z.articleId = w.articleId
    GROUP BY x.clientId, w.articleId
   ) AS t
GROUP BY clientId
;
```
Pour interroger cette vue :
```
SELECT clientId, totalVente FROM TotalParClient
```
(Je n’ai pas appliqué les 2% de réduction, mais ça n’est pas compliqué).

Citation:

Envoyé par nino04

le client peux recevoir soit un ticket soit une facture pr chaque vente effectué.

En toute rigueur, il faudrait mettre en oeuvre une entité-type TICKET_VENTE (ou plus simplement TICKET) :

[VENTE]---0,1---(X)---1,1(R)---[TICKET_VENTE]

Et, à cause du « soit, soit », mettre en oeuvre une contrainte d’exclusion entre TICKET_VENTE et FACTURE. Cela dit, je ne voudrais pas vous traumatiser pour ça...

Citation:

Envoyé par nino04

Q3: peut etre changer VENTE en TICKET_VENTE pour plus de compréhension?

Au vu de ce qui précède, la réponse est négative, VENTE reste VENTE.

Citation:

Envoyé par nino04

Pour cela je pense pouvoir récupérer les données du catalogue et des lignes de commandes pour le prix totale ou alors rajouter la propriété prix_total dans commandes?

Ajouter la propriété prix_total engendrerait une redondance, auquel cas il faudrait une contrainte vérifiant que la valeur de prix_total est bien la somme des valeurs du niveau détail. En revanche, la mise en oeuvre d’une vue permettrait de faire « comme si ».

Citation:

Envoyé par nino04

vu que l'association acheter à été supprimé pour cause de redondance, je ne suis pas sur de pouvoir dire qu'un article est acheté par un ou plusieurs client ==>Q4: comment traduire cela

Par une requête SQL, par exemple :
```
SELECT DISTINCT clientNom, articleRef      
    FROM   CLIENT AS x
      JOIN VENTE AS y ON x.clientId = y.clientId
      JOIN LIGNE_VENTE as z ON y.venteId = z.venteId
      JOIN ARTICLE as w ON z.articleId = w.articleId
;
```
ACHETER peut être définie sous la forme d’une vue :
```
CREATE VIEW ACHETER (clientNom, articleRef)
AS
SELECT DISTINCT clientNom, articleRef    
    FROM   CLIENT AS x
      JOIN VENTE AS y ON x.clientId = y.clientId
      JOIN LIGNE_VENTE as z ON y.venteId = z.venteId
      JOIN ARTICLE as w ON z.articleId = w.articleId
;
```
Pour interroger cette vue :
```
SELECT clientNom, articleRef FROM ACHETER ;
```
Citation:

Envoyé par nino04

une vente peut etre effectué a un ou plusieu client?

Pour le moment, une vente donnée est faite à un client donné. Que voulez-vous dire exactement ?

Pour l’historique des ventes, c’est a priori correct, dans la mesure où on a la période, laquelle participera à la clé primaire de la table historique, en conjugaison avec l’attribut id_article.

J’ai quelques remarques à faire concernant le MCD et le MLD, on verra ça un peu plus tard.

Bonne journée !
04/06/2020, 17h29
nino04

1 pièce(s) jointe(s)
Bien le bonjour fsmrel,

voici le résultat des changements appliqué:
- je ne suis vraiment pas sur pour le mode de paiement ac paypal et carte bancaire qui hérite de mode de paiement peut être qu'une simple relation aurais suffit avec les bonnes cardinalités et le bonne propriété dans MODE_PAIEMENT?
- est ce que j'ai bien applique la contrainte entre facture et ticket ?
Pièce jointe 570285

il ne me reste plus qu'une chose a faire:
- le client une fois le paiement effectué ( d’où le rajout de propriété payé_bool dans MODE_PAIEMENT), peut venir chercher les articles de la vente effectuée en magasin ou se faire livrer à l'adresse fournie par le client?
je pense que dans ce cas une entité livraison devrait être en relation avec client simplement puisque la propriété payé_BOOL peut être utilisé
==> CLIENT---0,n ---(livrer)---0,n ---LIVRAISON

exemple si le paiement est paypal et que la propriété payé_bool est Vrai, alors livraison de la vente

je ne vous remercierais jamais assez pour l'aide apporté,:oops:
Portez vous bien
04/06/2020, 20h02
fsmrel

Bonsoir Nino,

J'ai jeté un coup d'œil rapide au MCD, ça a l'air pas mal. J'ai plein de fers au feu, aussi regarderai-je plus attentivement dimanche ou lundi Désolé pour le délai…

Profitez-en pour une lecture approfondie de l'ouvrage de D. Nanci (RIP).
06/06/2020, 18h19
nino04

5 pièce(s) jointe(s)

Bonjour,

Alors voila après une analyse plus approfondie et beaucoup de lecture, j'ai décidé de remanié le mcd afin qu'il soit plus simple a la lecture,en effet j'avais oublier les commande client et surement d'autres choses. l'ancien mcd me semblait complexe et destiné plutot a un usage client en magasin ( borne de magasin ou le client paye les article de la vente seul ) est ce que je me trompe?

Cependant le but de l'application étais bien a l'usage du gérant de magasin.

Ceci dit, voila le dernier MCD auquel j'ai abouti présenté en différentes sections afin d'avoir un meilleur aperçu

MCD ANALYSE CLIENT

Pièce jointe 570812

MCD ANALYSE ARTICLE

Pièce jointe 570814

MCD ANALYSE TRANSACTION client/fournisseur

Pièce jointe 570818

MCD Complet

Pièce jointe 570820

MLD Complet

Pièce jointe 570824

voila j’attends vos remarques avec impatience dites moi ce que vous en pensez ?
Est ce plus lisible et plus simple a voir ainsi ?

Bien a vous,

ps: merci pour vos conseils
06/06/2020, 20h19
fsmrel

Bonjour Nino,

Comme annoncé, je suis très pris, normalement je regarderai tout ça lundi.

Bonne fin de semaine
08/06/2020, 19h56
fsmrel
Bonsoir Nino,

Vous avez bossé ! ;) Le MCD est effectivement plus orienté gérant du magasin (exeunt les ventes et naissent les commandes et les livraisons).

Quelques remarques concernant la partie Clients.

Entité-type ARTICLE

Vous n’avez toujours pas défini d’attribut pour la référence de l’article. Je vous engage vivement à le faire.

Les attributs prix_vente_htva et prix_vente_htva_depuis sont redondants : n’en conserver qu’un. Même remarque concernant les attributs taux_tva et taux_tva_depuis.

Attribut marque_article : Les marques devraient faire l’objet d’une entité-type :

[MARQUE_ARTICLE]---0,N---(X)---1,1---[ARTICLE]

Historique des prix de vente des articles et des taux tva :

D’accord. Je vois que vous avez de saines lectures ! :P
Si vous utilisez PostgreSQL comme SGBD, vous pouvez avantageusement utiliser le type daterange, et remplacer par exemple les attributs date_debut_prix_vente_htva et date_fin_prix_vente_htva par l’attribut periode_prix_vente_htva de type daterange, phagocytant la date de début et la date de fin. Voyez par exemple ici.

(Q8) Quel est votre SGBD cible ?

Entité-type CLIENT

Même remarque que pour ARTICLE : mettez en oeuvre le référencement des clients (attribut clientRef).

Entité-type REGLEMENT_CLIENT

(Q9) Cette entité-type ne fait référence à aucun client. Est-ce bien normal ?

L’attribut date_reglement ne devrait pas faire partie de l’identifiant de l’entité-type.
(Q9) Quel rôle joue l’attribut montant_paiement_fournisseur ?

Entité-type FACTURE_VENTE

Il devrait y avoir un attribut pour le numéro de facture. Une facture sans numéro ça n’est pas possible.
(Q10) Ce numéro est-il calculé à partir d’autres attributs ?

Il devrait y avoir un attribut pour la date de facture. Une facture sans date ça n’est pas possible.
(Q11) Cette date est-elle celle de la date de livraison, ou autre ?

Les lignes de facture ne sont pas modélisées.
(Q12) Comment les obtenez-vous ? A partir des lignes de livraison ? Tout ça paraît suspect et mérite des explications.

Entité-type LIVRAISON_CLIENT

(Q13) Pour une paire (commande, facture), peut-on avoir plus d’une livraison ?

Il manque la contrainte d’inclusion signifiant qu’il ne faut pas mélanger les factures du client C1 avec les livraisons du client C2 (mais ne perdez pas trop de temps avec ça, au stade SQL, ça ne se règle guère que manuellement).

Pour éviter les mélanges, il suffit d’identifier COMMANDE_CLIENT relativement à CLIENT, même chose pour FACTURE_VENTE, et au stade SQL ne conserver qu’un unique attribut id_client dans l’instruction CREATE TABLE LIVRAISON_CLIENT :
```
CREATE TABLE COMMANDE_CLIENT
(
        clientId               INTEGER        NOT NULL
      , commandeClientId       INTEGER        NOT NULL  IDENTITY(1,1)
      , commandeClientDate     DATE           NOT NULL     
      , commandeLivraisonDate  DATE           NOT NULL     
    , CONSTRAINT COMMANDE_CLIENT_PK PRIMARY KEY (clientId, commandeClientId)
    , CONSTRAINT COMMANDE_CLIENT_CLIENT_FK FOREIGN KEY (clientId)
          REFERENCES CLIENT (clientId)  
) ;

CREATE TABLE FACTURE_VENTE
(
        clientId           INTEGER        NOT NULL 
      , factureVenteId     INTEGER        NOT NULL  IDENTITY(1,1)
      , factureNo          INTEGER        NOT NULL     
      , factureDate        DATE           NOT NULL
      , factureMtHt        DECIMAL(7,2)   NOT NULL    
      , factureMtTva       DECIMAL(7,2)   NOT NULL    
      , factureMtTtc       DECIMAL(7,2)   NOT NULL    
    , CONSTRAINT FACTURE_VENTE_PK PRIMARY KEY (clientId, factureVenteId)
    , CONSTRAINT FACTURE_VENTE_AK UNIQUE (factureNo)
    , CONSTRAINT FACTURE_VENTE_CLIENT_FK FOREIGN KEY (clientId)
          REFERENCES CLIENT (clientId)  
) ;
CREATE TABLE LIVRAISON_CLIENT
(
        livraisonClientId  INTEGER        NOT NULL
      , clientId           INTEGER        NOT NULL
      , commandeClientId   INTEGER        NOT NULL
      , factureVenteId     INTEGER        NOT NULL 
      , client_bl_date     DATE           NOT NULL 
      , client_bl_total    DECIMAL(7,2)   NOT NULL
    , CONSTRAINT LIVRAISON_CLIENT_PK PRIMARY KEY (livraisonClientId)    
    , CONSTRAINT LIVRAISON_CLIENT_COMMANDE_FK FOREIGN KEY (clientId, commandeClientId)
          REFERENCES COMMANDE_CLIENT (clientId, commandeClientId)  
    , CONSTRAINT LIVRAISON_CLIENT_FACTURE_FK FOREIGN KEY (clientId, factureVenteId)
          REFERENCES FACTURE_VENTE (clientId, factureVenteId)  
) ;
```
Association LIGNE_LIVRAISON_CLIENT

(Q14) Pourquoi les deux attributs quantite_livree_client et nombre_piece_livree_client ? N’y a-t-il pas redondance ?

Attribut Total_prix_quantite_livree : la valeur est calculable puisqu’on a la date de livraison et de là on sait retrouver le prix de vente d’un article dans ARTICLE (ou HISTORIQUE_PRIX_VENTE et HISTORIQUE_TAUX_TVA_VENTE).

Entité-type CARTE_FIDELITE

Supprimer l’attribut id_carte puisque, du fait de l’identification relative, l’identifiant est hérité de celui de CLIENT.
Si vous utilisez PostgreSQL, alors vous pouvez remplacer la date de début et la date de fin par la période (type daterange).

Dans les noms des objets SQL (tables, attributs, ...) évitez les lettres avec accent (é, è, ê, etc.)

Ne pas écrire Quantité_Commandée_Client , mais Quantite_Commandee_Client.

Bonsoir Nino,

Vu la similitude de la partie ACHATS et de la partie VENTES, mes remarques concernant les ventes valent évidemment pour les achats, toutes choses égales.

Entité-type FOURNISSEUR

Même remarque que pour ARTICLE : mettez en oeuvre le référencement des fournisseurs (attribut fournisseurRef).

Entité-type REGLEMENT_FOURNISSEUR

(Q15) Cette entité-type ne fait référence à aucun fournisseur. Est-ce bien normal ?

Entité-type FACTURE_ACHAT

Il devrait y avoir un attribut pour le numéro de facture fourni par le fournisseur. Une facture sans numéro ça ne se fait pas...

Les lignes de facture ne sont pas modélisées.
(Q16) Est-ce voulu ?

Là aussi il manque la contrainte d’inclusion signifiant qu’il ne faut pas mélanger les factures du fournisseur F1 avec les livraisons du fournisseur F2 (là non plus ne perdez pas trop de temps avec ça, au stade SQL, une fois de plus ça ne se règle guère que manuellement).

Pour éviter les mélanges, il suffit d’identifier COMMANDE_FOURNISSEUR relativement à _FOURNISSEUR, même chose pour FACTURE_ACHAT, et au stade SQL ne conserver qu’un unique attribut id_fournisseur dans l’instruction CREATE TABLE LIVRAISON_FOURNISSEUR :
CREATE TABLE COMMANDE_FOURNISSEUR
(
        fournisseurId               INTEGER        NOT NULL
      , commandefournisseurId       INTEGER        NOT NULL  IDENTITY(1,1)
      , commandefournisseurDate     DATE           NOT NULL     
      , commandeLivraisonDate       DATE           NOT NULL     
    , CONSTRAINT COMMANDE_FOURNISSEUR_PK PRIMARY KEY (fournisseurId, commandefournisseurId)
    , CONSTRAINT COMMANDE_FOURNISSEUR_FOURNISSEUR_FK FOREIGN KEY (fournisseurId)
          REFERENCES FOURNISSEUR (fournisseurId)  
) ;
CREATE TABLE FACTURE_ACHAT
(
        fournisseurId      INTEGER        NOT NULL 
      , factureVenteId     INTEGER        NOT NULL  IDENTITY(1,1)
      , factureNo          INTEGER        NOT NULL     
      , factureDate        DATE           NOT NULL
      , factureMtHt        DECIMAL(7,2)   NOT NULL    
      , factureMtTva       DECIMAL(7,2)   NOT NULL    
      , factureMtTtc       DECIMAL(7,2)   NOT NULL    
    , CONSTRAINT FACTURE_ACHAT_PK PRIMARY KEY (fournisseurId, factureVenteId)
    , CONSTRAINT FACTURE_ACHAT_AK UNIQUE (factureNo)
    , CONSTRAINT FACTURE_ACHAT_FOURNISSEUR_FK FOREIGN KEY (fournisseurId)
          REFERENCES FOURNISSEUR (fournisseurId)  
) ;
CREATE TABLE LIVRAISON_FOURNISSEUR
(
        livraisonfournisseurId  INTEGER        NOT NULL
      , fournisseurId           INTEGER        NOT NULL
      , commandefournisseurId   INTEGER        NOT NULL
      , factureVenteId          INTEGER        NOT NULL 
      , fournisseur_bl_date     DATE           NOT NULL 
      , fournisseur_bl_total    DECIMAL(7,2)   NOT NULL
    , CONSTRAINT LIVRAISON_FOURNISSEUR_PK PRIMARY KEY (livraisonfournisseurId)    
    , CONSTRAINT LIVRAISON_FOURNISSEUR_COMMANDE_FK FOREIGN KEY (fournisseurId, commandefournisseurId)
          REFERENCES COMMANDE_FOURNISSEUR (fournisseurId, commandefournisseurId)  
    , CONSTRAINT LIVRAISON_FOURNISSEUR_FACTURE_FK FOREIGN KEY (fournisseurId, factureVenteId)
          REFERENCES FACTURE_ACHAT (fournisseurId, factureVenteId)  
) ;

10/06/2020, 18h52
nino04

2 pièce(s) jointe(s)

Bonjour, fsmrel

Voila j'ai appliquer les changements, je dois encore vérifier votre dernier message.
Et Je vous fournirais ensuite les infos concernant le mld, Mpd, je fais cela dans le cadres de mon cours d'ing logiciel ainsi une fois mon examen terminer (12/06/20). je ne pense pas retoucher a winDesign pr un bon moment ^^.
Ceci dit je pense que mon prof aurait fait un infarctus en lisant mon rapport sans votre aide donc MERCI 1000 fois pour moi d'abord et pour mon professeur ensuite.:mouarf:

Citation:

(Q8) Quel est votre SGBD cible ?

SQL Server

Citation:

Entité-type REGLEMENT_CLIENT

(Q9) Cette entité-type ne fait référence à aucun client. Est-ce bien normal ?

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 et que celle ci faisant également référence a un ou plusieurs clients je pensais cela suffisant.

Citation:

(Q9) Quel rôle joue l’attribut montant_paiement_fournisseur ?

Alors concernant le montant_payement fournisseur ou client c'est pour éviter de le recalculer. je m'explique ce montant peut être calculer mais je me suis dit qu'il serait peut être mieux de faire une variable montant afin de faire le calcul une fois et l'enregistrer dans règlement client ou payement_fournisseur afin d’éviter de recalculer a chaque fois que le gérant de magasin demande une liste des règlement effectué par exemple.
je ne sais pas si cela est clair ainsi ?

Citation:

Entité-type FACTURE_VENTE

Il devrait y avoir un attribut pour le numéro de facture. Une facture sans numéro ça n’est pas possible.
(Q10) Ce numéro est-il calculé à partir d’autres attributs ?

Il devrait y avoir un attribut pour la date de facture. Une facture sans date ça n’est pas possible.
(Q11) Cette date est-elle celle de la date de livraison, ou autre ?

non effectivement un oubli de ma part j'a rajouté num_factur_vente et date_facture_vente dans facture_vente

Citation:

Les lignes de facture ne sont pas modélisées.
(Q12) Comment les obtenez-vous ? A partir des lignes de livraison ? Tout ça paraît suspect et mérite des explications.

:calim2: headShot :aie:
==> ben la pour le coup j'ai pas vraiment de réponse a fournir pour ça, je pensais effectivment passe par livraison c
j'ai rajouter ligne facture de cette manière pour les client je devrais surement refaire la même chose pour facture_achat

Citation:

Entité-type LIVRAISON_CLIENT
(Q13) Pour une paire (commande, facture), peut-on avoir plus d’une livraison ?

oui si le fournisseur n'a pas tout en stock il m'envoie la commande en 2 fois par exemple.

Citation:

Association LIGNE_LIVRAISON_CLIENT

(Q14) Pourquoi les deux attributs quantite_livree_client et nombre_piece_livree_client ? N’y a-t-il pas redondance ?

Attribut Total_prix_quantite_livree : la valeur est calculable puisqu’on a la date de livraison et de là on sait retrouver le prix de vente d’un article dans ARTICLE (ou HISTORIQUE_PRIX_VENTE et HISTORIQUE_TAUX_TVA_VENTE).

j'ai supprimé un des deux

même chose que tantot pour Total_prix_qté_livree j'ai rajouter cela malgré qu'il soit calculable pour éviter de refaire le calcul a chaque fois comme ca lorsque je demande de charger les factures il ne calcul pas le montant a chaque fois mais une fois calculé l'enregistre pour accélérer le processus de recherche.

Pièce jointe 572021

Pièce jointe 572025
10/06/2020, 21h59
Paprick

Bonsoir,
Je trouve bizarre la façon dont Win'Design a généré le MLD au niveau de l'héritage... :koi:
Autant je suis d'accord pour "Accessoire", autant "Chaussure" et "Textile" me posent problème : je sais que Win'Design propose la reprise dans les classes filles des rubriques de la classe mère, mais je trouve ça peu judicieux ; de plus la clé primaire ainsi proposée ne me parait pas justifiée (et représente en plus une surclé...).
A mon avis, pour une modélisation propre et adéquat, toutes les classes filles devraient être comme "Accessoire".
11/06/2020, 04h29
fsmrel

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 ? :D

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.:fessee:

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).

Citation:

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 !

Citation:

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...

Citation:

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...
11/06/2020, 04h48
Paprick

Bonsoir,

Citation:

Envoyé par fsmrel

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.

J'abonde effectivement en ce sens ! D'ailleurs, malgré tout le respect que j'ai pour l'ouvrage de référence de Nanci, je ne comprends pas que cette possibilité de dupliquer les rubriques soit offerte, provoquant une redondance pour moi inacceptable...
Il est vrai que Win'Design, PowerAMC, et peut-être d'autres, laissent le choix... Looping, pour sa part, ne le proposera jamais ! :nono: Si le concepteur souhaite cette duplication, qu'il la modélise au niveau du MCD ! :boulet:

Fuseau horaire GMT +2. Il est actuellement 05h20.