Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

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


Sujet :

Schéma

  1. #1
    Candidat au Club
    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é:



    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é:


    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



    MCD FINAL:


    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

    bien a vous,

  2. #2
    Expert éminent sénior
    Bonsoir nino04,


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

    Citation Envoyé par nino04 Voir le message
    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 Voir le message
    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.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #3
    Membre éclairé
    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...
    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...
    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 , 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 !
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  4. #4
    Candidat au Club
    bonjour à vous,
    et merci de vos réponse,

    Citation Envoyé par fsmrel Voir le message

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

    Q2 our 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 !

    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 également


    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.



  5. #5
    Membre éclairé
    Bonsoir,
    Citation Envoyé par nino04 Voir le message
    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 : 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...
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  6. #6
    Expert éminent sénior
    Bonsoir nino et Paprik,


    Citation Envoyé par Paprick Voir le message
    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…


    Citation Envoyé par nino04 Voir le message
    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 ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  7. #7
    Expert éminent sénior
    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) :



    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) ;
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  8. #8
    Expert éminent sénior
    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 ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  9. #9
    Candidat au Club
    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:

    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:

    et


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

  10. #10
    Candidat au Club
    Citation Envoyé par fsmrel Voir le message
    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.

  11. #11
    Expert éminent sénior
    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 Voir le message
    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...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  12. #12
    Candidat au Club
    Citation Envoyé par fsmrel Voir le message
    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 !


    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

  13. #13
    Expert éminent sénior
    Bonsoir nino,


    Citation Envoyé par nino04 Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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 !
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  14. #14
    Candidat au Club
    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 ?





    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é,
    Portez vous bien

  15. #15
    Expert éminent sénior
    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).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  16. #16
    Candidat au Club
    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



    MCD ANALYSE ARTICLE



    MCD ANALYSE TRANSACTION client/fournisseur



    MCD Complet



    MLD Complet



    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

  17. #17
    Expert éminent sénior
    Bonjour Nino,

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

    Bonne fin de semaine
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  18. #18
    Expert éminent sénior
    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 !
    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.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  19. #19
    Expert éminent sénior
    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)  
    ) ;
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  20. #20
    Candidat au Club
    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.


    (Q8) Quel est votre SGBD cible ?
    SQL Server


    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.


    (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 ?


    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



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


    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.


    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.