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 :

Avis / suggestions MCD e-commerce


Sujet :

Schéma

  1. #1
    Membre régulier
    Avis / suggestions MCD e-commerce
    Bonjour à tous,

    Je me lance dans la création d'un site de e-commerce avec Laravel.
    Il s'agira d'un petit site, une partie vitrine pour de chaussures modèle unique et fait main, une autre partie e-commerce qui n'aura dans un premier temps que des sacs en cuir à vendre, mais devra plus tard, pouvoir accueillir d'autre produits.

    Voici le MCD auquel j'arrive après une première réflexion.



    Si vous avez d'autre idées ou suggestions, elles sont les bienvenue, vu que c'est la première fois que je fais une base de données pour un e-commerce.

  2. #2
    Expert éminent sénior
    Bonjour,

    Dans le modèle conceptuel, on modélise des types d'entité et des associations avec des cardinalités sur les "pattes" de ces associations.
    Là, vous avez modélisé des tables, il s'agit d'un MLD et non pas d'un MCD.

    Etablir le MCD préalablement au MLD est nettement préférable. Ca évite bien des erreurs.

    Mais avant tout ça il faut collecter les règles de gestion, par exemple, d'après votre schéma, on peut supposer les règles de gestion suivantes (mais à confirmer et faire valider par votre client) :

    R001a : un client peut passer zéro à plusieurs commandes (vous considérez donc les prospects comme des clients)
    R001b : une commande est passée par un et un seul client

    Quand ce sera fait, on pourra discuter du détail, comme par exemple du choix des types de données, pas toujours opportun dans votre MLD.
    Mais chaque chose en son temps, voyons déjà les règles de gestion

  3. #3
    Membre régulier
    Citation Envoyé par escartefigue Voir le message
    Dans le modèle conceptuel, on modélise des types d'entité et des associations avec des cardinalités sur les "pattes" de ces associations.
    Là, vous avez modélisé des tables, il s'agit d'un MLD et non pas d'un MCD.

    Etablir le MCD préalablement au MLD est nettement préférable. Ca évite bien des erreurs.
    Lorsque je choisis MCD dans Visual Paradigm, voilà ce que ça donne. la seul différence, c'est le type de donnée qui n'apparait plus.
    Un autre logiciel pour modéliser des bases de données à conseiller?



    Citation Envoyé par escartefigue Voir le message
    R001b : une commande est passée par un et un seul client
    oui, une commande est passée par un client à la fois.

  4. #4
    Expert éminent sénior
    Oui : Looping, à télécharger ici https://www.looping-mcd.fr

  5. #5
    Membre régulier
    Je suis sur Mac, je vais essayer avec Wine.

  6. #6
    Membre éprouvé
    Citation Envoyé par Cisman Voir le message
    Je suis sur Mac, je vais essayer avec Wine.
    Looping marche parfaitement avec les dernières versions de Wine.
    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

  7. #7
    Membre régulier
    Bonsoir,
    avec quelle version de Wine?
    Pour le moment, je n'arrive pas à lancer looping avec Wine.

  8. #8
    Membre éprouvé
    Bonsoir,
    Citation Envoyé par Cisman Voir le message
    Bonsoir,
    avec quelle version de Wine?
    Pour le moment, je n'arrive pas à lancer looping avec Wine.
    La version de Wine que j'utilise sur le Mac de mon épouse est la 5.0
    Par contre, prendre la version capable d'exécuter des applications Windows 32 bits.
    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

  9. #9
    Membre régulier
    à priori, la dernière version n'est pas compatible avec mon Mac.
    Je vais utiliser looping en virtualisant Windows.

  10. #10
    Membre éprouvé
    Citation Envoyé par Cisman Voir le message
    à priori, la dernière version n'est pas compatible avec mon Mac.
    Je vais utiliser looping en virtualisant Windows.
    C'est sûr que c'est la solution la plus efficace
    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

  11. #11
    Membre régulier
    Bonsoir,

    voici mon MCD fait avec Looping.

    J'y ai déjà apporté quelques changements.


  12. #12
    Expert éminent sénior
    Bonjour,

    Dans l'entité-type "customer" comme dans toute entité-type, n'utilisez jamais d'identifiant fonctionnel en tant qu'id primaire !

    L'id primaire doit être invariant car il se propage dans d'autres tables via les clef étrangères. L'adresse courriel d'une personne peut changer, un identifiant technique dépourvu de sens ne changera jamais.
    De plus, la norme prévoit qu'une adresse courriel peut faire jusqu'à 255 caractères ! C'est très très encombrant pour une PK
    Enfin, le varchar est ce qu'on fait de pire en terme de performances.
    Bref, type de données à fuir pour un identifiant primaire, comme identifiant de remplacement, oui, pourquoi pas, mais primaire, non !

    Sinon, pour toutes les typologies, prévoyez une cardinalité minimale de zéro de la typologie vers l'autre entité-type.
    Par exemple 0 de "status" vers "shopping cart" et de "payment" vers "shopping cart"

    Dans "article", il serait bon de préciser s'il s'agit du prix de vente ou d'achat.
    Et le prix n'a de sens que s'il est unique pour tous les fournisseurs (^prix d'achat) ou pour tous les clients (prix de vente). à confirmer.
    La quantité en stock n'a de sens que si l'article est stocké dans un et un seul entrepôt ou magasin, sinon, il faut gérer par entrepôt.

    Sinon : pourquoi avoir choisi des termes en anglais ? Si votre projet est international ok, sinon, simplifiez vous la vie et utilisez des termes en français

    Enfin et surtout : vous n'avez toujours pas précisé vos règles de gestion impossible donc de valider véritablement le modèle.

  13. #13
    Membre régulier
    Ce message n'a pas pu être affiché car il comporte des erreurs.

  14. #14
    Expert éminent sénior
    Citation Envoyé par Cisman Voir le message

    Citation Envoyé par escartefigue Voir le message
    Dans l'entité-type "customer" comme dans toute entité-type, n'utilisez jamais d'identifiant fonctionnel en tant qu'id primaire !
    L'id primaire doit être invariant car il se propage dans d'autres tables via les clef étrangères. L'adresse courriel d'une personne peut changer, un identifiant technique dépourvu de sens ne changera jamais.
    De plus, la norme prévoit qu'une adresse courriel peut faire jusqu'à 255 caractères ! C'est très très encombrant pour une PK
    Enfin, le varchar est ce qu'on fait de pire en terme de performances.
    Bref, type de données à fuir pour un identifiant primaire, comme identifiant de remplacement, oui, pourquoi pas, mais primaire, non !
    Vous avez remplacé l'adresse courriel par le pseudo, donc un attribut fonctionnel par une autre attribut fonctionnel...
    Si le pseudonyme du client change, vous tombez dans le même travers des mises à jour en cascade dans les tables filles.
    Je le répète, pour l'identifiant primaire, choisissez un identifiant technique comme vous l'avez fait dans les autres types d'entité !


    Citation Envoyé par Cisman Voir le message

    Citation Envoyé par escartefigue Voir le message

    Sinon, pour toutes les typologies, prévoyez une cardinalité minimale de zéro de la typologie vers l'autre entité-type.
    Par exemple 0 de "status" vers "shopping cart" et de "payment" vers "shopping cart"
    J'ai corrigé pour le Status, Payement et Carrier, mais j'avoue ne pas trop comprendre pourquoi.
    Prenons l'exemple des statuts, imaginons que vous ayez prévu "ouvert", "annulé", "validé" et "livré"
    ces 4 statuts sont possibles, mais à un instant "t" rien n'indique que vous aurez au moins un "shopping cart" pour chacun de ces statuts
    Il faut donc prévoir une cardinalité minimale de zéro.
    De plus, pour les typologies, prévoyez également un code de type char court (char(4) par exemple).
    Pour certains codes, il est conseillé d'utiliser les codifications ISO (par exemple codes pays, codes devises, codes langues, unités de mesure...). La plupart sont accessibles sur le web gratuitement.



    Citation Envoyé par Cisman Voir le message

    Citation Envoyé par escartefigue Voir le message

    Enfin et surtout : vous n'avez toujours pas précisé vos règles de gestion impossible donc de valider véritablement le modèle.
    Que voulez-vous dire par règles de gestion? Je dois encore faire des Use case, diagramme de classe etc...
    Les règles de gestion c'est par exemple
    R001a : un client possède au moins une adresse
    R001b : une adresse est possédée par un et un seul client

    R002a : un article est contenu dans au moins un panier
    R002b : un panier contient au moins un article

    R002a est conforme à votre MCD mais très suspect : en l'état, vous ne pouvez enregistrer aucun article tant qu'il n'a jamais été réservé au moins une fois dans un panier

  15. #15
    Membre régulier
    Citation Envoyé par escartefigue Voir le message
    Vous avez remplacé l'adresse courriel par le pseudo, donc un attribut fonctionnel par une autre attribut fonctionnel...
    Si le pseudonyme du client change, vous tombez dans le même travers des mises à jour en cascade dans les tables filles.
    Je le répète, pour l'identifiant primaire, choisissez un identifiant technique comme vous l'avez fait dans les autres types d'entité !
    J'imaginais un pseudo invariable. j'ai mis un identifiant technique comme dans mes autres entités.



    Prenons l'exemple des statuts, imaginons que vous ayez prévu "ouvert", "annulé", "validé" et "livré"
    ces 4 statuts sont possibles, mais à un instant "t" rien n'indique que vous aurez au moins un "shopping cart" pour chacun de ces statuts
    Il faut donc prévoir une cardinalité minimale de zéro.
    De plus, pour les typologies, prévoyez également un code de type char court (char(4) par exemple).
    Pour certains codes, il est conseillé d'utiliser les codifications ISO (par exemple codes pays, codes devises, codes langues, unités de mesure...). La plupart sont accessibles sur le web gratuitement.
    Ok, bien compris




    Les règles de gestion c'est par exemple
    R001a : un client possède au moins une adresse
    R001b : une adresse est possédée par un et un seul client

    R002a : un article est contenu dans au moins un panier
    R002b : un panier contient au moins un article

    R002a est conforme à votre MCD mais très suspect : en l'état, vous ne pouvez enregistrer aucun article tant qu'il n'a jamais été réservé au moins une fois dans un panier
    Vous voulez dire, que mon entités article devrait être relié à mon entité Administrator, qui lui pourrait enregistrer des articles sur le site?

    Y aurai t'il quelque part, des exemples, ou des questions type a se poser avec le client pour bien définir ces règles de gestion?
    Je viens de trouvez ça comme exemple, je vois avec mon frère et je reviens dans quelques jours avec des règles de gestion.
    https://blog.developpez.com/cinephil...te_g_modelisat

  16. #16
    Expert éminent sénior
    Citation Envoyé par Cisman Voir le message
    Vous voulez dire, que mon entités article devrait être relié à mon entité Administrator, qui lui pourrait enregistrer des articles sur le site?
    Non je veux dire que pour permettre de créer une ligne article dans la base de données même si cet article n'a jamais été commandé dans un panier il faut modéliser une cardinalité mini de zéro coté article

    [ARTICLE] 0,n --- (contenir) --- 1,n [SHOPPING_CART]

    De [CATEGORY] vers (appartient) il faut également mettre 0,n, car la catégorie est également une typologie pour laquelle, à un instant "t", il peut y avoir des catégories sans articles.

    Je reviens sur le choix de la langue : si vous nommez les types d'entité et les attributs en anglais, alors les associations doivent aussi être nommées en anglais, en tout cas au moins celles dont la cardinalité maxi est "n" sur chaque patte, car ces associations deviendront des tables et ce serait ballot d'avoir des tables nommées en anglais (celles issues des types d'entités) et d'autres en français...

  17. #17
    Membre régulier
    Bonsoir,

    me revoilà avec les règles de gestion.
    Mon frère ayant été hospitalisé, ça à pris un peu de temps.

    Règles de gestion
    Est-ce qu’un utilisateur possède obligatoirement un adresse? Non, si l’utilisateur est un des admin du site (rôle=1) alors pas besoin d’adresse.
    Est-qu’un utilisateur peut posséder plusieurs adresse? NON
    La même adresse peut appartenir à plusieurs personnes. OUI

    Est-ce qu’une catégorie peut ne posséder aucuns articles? OUI
    Est-ce qu’une catégorie peut posséder plusieurs articles? OUI exemple bureau = porte lunette, tapis souris, etc
    Est-ce qu’un article peut n’appartenir à aucune catégorie? NON
    Est-ce que un article doit appartenir à au moins une catégorie? OUI
    Est-ce que un article peut appartenir à plusieurs catégories? NON

    Une commande peut ne pas avoir de status? NON AU DÉBUT UN FOIS VALIDÉE, EN PRÉPARATION, ENVOYÉE.
    Une commande doit avoir un status? OUI
    Une commande peut avoir plusieurs status simultanément? NON
    Un status peut n’appartenir à aucun commande? OUI
    Un status peut appartenir à plusieurs commande? OUI

    Une commande peut ne pas avoir de méthode de paiement? NON
    Une commande peut avoir plusieurs méthode de paiement simultanément? NON
    Une commande doit avoir une méthode de paiement? OUI
    Une méthode de paiement peut n’avoir été choisi par aucune commande? OUI
    Une méthode de paiement peut être choisie par plusieurs commandes? OUI

    Une commande peut ne pas avoir de transporteur? NON
    Une commande peut avoir plusieurs transporteur simultanément? NON
    Une commande doit avoir un transporteur? OUI
    Un transporteur peut na pas avoir été sélectionné par aucuns des commandes? OUI
    Un transporteur peut être sélectionné par plusieurs commandes? OUI

    Une commande peut contenir aucun article? NON
    Une commande doit contenir au moins un article? OUI
    Une commande peut contenir plusieurs articles? OUI
    Un article peut n’appartenir à aucun commande? OUI
    Un article doit appartenir à au moins une commande? NON
    Un article peut appartenir à plusieurs commandes? OUI

    Un utilisateur peut passer 0 commande? OUI
    Un utilisateur doit passer au minimum 1 commande? NON
    Un utilisateur peut passer plusieurs commande? OUI
    Une commande peut être passée par aucun utilisateur? NON
    Une commande doit être passée par au moins 1 utilisateur? OUI
    Une commande peut être passée par plusieurs utilisateurs? NON

    Et voici mon MLD selon les règles de gestion.
    Cela vous semble correct?


###raw>template_hook.ano_emploi###