IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Merise Discussion :

Site d'e-commerce modèle MCD.


Sujet :

Merise

  1. #1
    Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juin 2024
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2024
    Messages : 2
    Points : 2
    Points
    2
    Par défaut Site d'e-commerce modèle MCD.
    Bonjour à toutes et à tous !

    Je vous pose le contexte, je suis en train de valider un titre RNCP Concepteur Développeur d'Applications et, pour cela, je dois valider des compétences auprès d'un jury. Parmi ces compétences, je dois modéliser une base de données relationnelle.

    Mon projet est un site d'e-commerce qui est composé de 12 entités :

    Rôle --> Utilisateur : Un utilisateur doit avoir un rôle, mais un rôle n'a pas besoin d'un utilisateur pour exister.
    Utilisateur --> UserDeliveryInfo : Un utilisateur peut avoir 0 ou plusieurs adresses, et une adresse peut appartenir à un ou plusieurs utilisateurs.
    Utilisateur --> PaimentCard : Un utilisateur peut avoir plusieurs cartes de paiement, et une carte de paiement peut appartenir à plusieurs utilisateurs.
    PaimentCard --> CardType : Une carte de paiement doit avoir un type de carte, mais un type de carte peut avoir plusieurs cartes de paiement.
    Utilisateur --> Produit : Un utilisateur peut créer 0 ou plusieurs produits, et un produit doit être créé par un utilisateur.
    Utilisateur --> Notice (commentaire) : Un utilisateur peut créer 0 ou plusieurs commentaires, et un commentaire doit être créé par un seul utilisateur.
    Notice --> Produit : Un produit peut avoir 0 ou plusieurs commentaires, et un commentaire appartient à un produit.
    Produit --> Catégorie : Un produit doit avoir une catégorie, mais une catégorie peut exister sans produit.
    Produit --> ProductPicture : Un produit peut avoir 0 ou plusieurs photos, et une photo appartient à un seul produit.
    Produit --> Panier (commande) : Un panier peut avoir 0 ou plusieurs produits (et un produit peut exister sans panier ?).
    Panier --> Statut : Un panier peut avoir 1 ou plusieurs statuts, mais un statut n'a pas besoin de panier pour exister.
    Facture --> Panier : Une facture appartient à une commande, et une commande peut générer 0 ou plusieurs factures.
    Facture --> Utilisateur : Une facture appartient à un utilisateur, et un utilisateur peut avoir 0 ou plusieurs factures.
    Facture --> PaimentCard : Une facture doit avoir une carte de paiement, mais une carte de paiement peut appartenir à plusieurs factures.
    Voici la logique que j'ai essayé de mettre en place :

    Nom : Capture d'écran 2024-06-03 212929.png
Affichages : 75
Taille : 67,0 Ko

    Est-ce que vous pouvez me donner vos avis sur ce modèle et me donner des conseils afin que je puisse l'améliorer et me corriger sur d'éventuelles erreurs que j'ai pu faire lors de sa conception ?

    Si vous pouvez détailler votre logique et votre vision, cela m'aiderait à comprendre pourquoi je n'ai pas la bonne logique !

    En vous remerciant d'avance !

    Lasurprise

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 240
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 240
    Points : 39 273
    Points
    39 273
    Billets dans le blog
    9
    Par défaut
    Bonjour Lasurprise, bienvenue dans ce forum

    Il semble que vous ayez choisi d'utiliser Looping pour réaliser votre modèle, excellent choix
    Vous avez énuméré les règles de gestion, c'est parfait aussi

    On part donc sur de très bonnes bases

    Quelques remarques tout de même, sinon ce ne serait pas drôle

    Un petit regret : les règles de gestion ne sont pas numérotées, c'est moins facile de parler de "la règle qui stipule que un produit peut avoir 0 ou plusieurs commentaires, et un commentaire appartient à un produit" que de parler de "la règle RG018" par exemple

    Concernant le choix de la langue : les règles de gestion sont rédigées en français, mais les types d'entité et leurs attributs sont en anglais. Du coup il faut traduire l'un vers l'autre pour s'en sortir. Pas très pratique.
    Pour ma part, quand je travaille dans un contexte francophone, je rédige et modélise en français, c'est plus simple pour tout le monde. Ce n'est que si le contexte l'exige que j'utilise l'anglais.
    Donc, sauf si votre jury exige un travail en anglais, simplifiez-vous la tâche.
    Autre avantage : il y a moins de risque de percussion avec des mots réservés SQL si on utilise le français. Par exemple, "user" est un mot réservé SQL alors que "utilisateur" ne l'est pas. Du coup, dans vos requêtes, vous devrez encadrer "user" de doubles quotes.

    Concernant les noms d'associations, il n'est pas utile d'utiliser "can" ou "peut" pour préciser le caractère facultatif. Préférez un verbe à l'infinitif, sans accent ou autre caractères spéciaux, là aussi pour ne pas être embêté au stade SQL.
    Par exemple :
    [UTILISATEUR] 0,n --- (posseder) --- 1,1 [CARTE_PAIEMENT]
    [UTILISATEUR] 0,n --- (ecrire) --- 1,1 [NOTICE]

    Concernant les noms des attributs : "id" est équivoque (identifiant de quoi ?) et un nom d'objet ne doit être présent qu'une seule fois. Utilisez des noms parlants : iduser si l'anglais s'avère indispensable, ou, de préférence, idutilisateur, idproduit etc. . Comme un nom d'objet ne doit être présent qu'une seule fois, il faudra faire de même pour "name" à préciser : produit_libelle et categorie_libelle par exemple.

    Le fait qu'un panier puisse avoir plusieurs statuts m'intrigue, pouvez-vous donner des exemples ?

  3. #3
    Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juin 2024
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2024
    Messages : 2
    Points : 2
    Points
    2
    Par défaut
    Bonjour Escartefigue et merci

    J'ai bien lu vos conseils et je vais passer mon MCD en français dans un premier temps pour me faciliter la tâche . Ensuite, je numéroterai les règles de gestion afin de donner une meilleure lisibilité à mes lecteurs. (Je n'avais jamais pensé à le faire donc merci !)

    Pour les IDs des tables du modèle MCD, j'ai délibérément fait le choix de les laisser ainsi car, dans le modèle MLD, je stipule à quoi les IDs des tables correspondent, par exemple : "id_user, id_product...", afin que les relations soient facilement compréhensibles. En tout cas merci du conseil je vais corriger ça !

    Étant donné que le panier est une commande, le statut serait un élément permettant de savoir si le panier est payé, en cours de validation, sauvegardé ou annulé.
    Il fonctionnerait sous forme d'update afin de créer à étape à chaque stade jusqu'au paiement.

    Je ferais un poste avec les corrections afin de voir si c'est mieux ainsi !

    En tout cas merci pour vos conseils !

    A très vite !

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 240
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 240
    Points : 39 273
    Points
    39 273
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Lasurprise Voir le message
    Étant donné que le panier est une commande, le statut serait un élément permettant de savoir si le panier est payé, en cours de validation, sauvegardé ou annulé.
    Il fonctionnerait sous forme d'update afin de créer à étape à chaque stade jusqu'au paiement.
    Ce faisant, à un instant "t" un panier n'a qu'un et un seul statut. La cardinalité maximale de n ne se justifie donc pas.
    Sauf si l'on veut suivre les statuts à date, auquel cas il faut une relation ternaire entre [PANIER], [STATUT] et une entité-type fictive [DATE] qui ne deviendra pas une table mais permettra de créer cette ternaire.

    À défaut de besoin d'historique des statuts, il n'est sans doute pas utile de créer un type d'entité [STATUT] sauf si un libellé en clair et d'autres attributs relatifs aux statuts vous intéressent. À priori, un attribut dans l'entité-type [PANIER] doit suffire, en lui positionnant une contrainte CHECK pour contrôler les valeurs autorisées.

    Pour le formalisme des règles de gestion, je copie-colle ici un exemple donné dans un autre fil de discussion :

    Citation Envoyé par escartefigue Voir le message
    Bonjour Tokyrn
    un MCD c'est la traduction sous forme de schéma et selon un formalisme particulier de règles de gestion
    [. . .]
    Idéalement, chaque règle porte un identifiant distinct et comporte un sujet, un verbe et un complément
    Exemple :
    R001 : un client est une personne qui passe au moins une commande
    R002 : une commande est passée par un et un seul client
    R003 : une commande se compose d'une à plusieurs lignes de commande
    R004 : une ligne de commande compose une et une seule commande
    etc.
    [. . .]
    Dans l'exemple ci-dessus, on nommera les associations (passer) et (composer), puisque l'usage est de reprendre les mêmes verbes, à l'infinitif, que dans les règles de gestion


    Citation Envoyé par Lasurprise Voir le message
    Pour les IDs des tables du modèle MCD, j'ai délibérément fait le choix de les laisser ainsi car, dans le modèle MLD, je stipule à quoi les IDs des tables correspondent, par exemple : "id_user, id_product...", afin que les relations soient facilement compréhensibles. En tout cas merci du conseil je vais corriger ça !
    C'est bien évidemment plus simple quand les noms sont complets dès le MCD, même si l'on ne peut pas toujours conserver le même nom au stade SQL qu'au stade conceptuel, ce que Looping gère très bien puisqu'on peut coder en plus du nom conceptuel, le nom logique de chaque objet.
    Quoi qu'il en soit, parler de "table" dans le MCD est un abus de langage, au stade conceptuel, on a affaire à des types d'entités, des associations et des contraintes. Les tables n'existent qu'à partir du modèle logique (MLD) et physique (MPD).

Discussions similaires

  1. [MCD] Avis sur MCD site de e-commerce
    Par Rom360 dans le forum Schéma
    Réponses: 9
    Dernier message: 12/07/2021, 15h23
  2. Réponses: 3
    Dernier message: 26/03/2008, 21h15
  3. Réponses: 2
    Dernier message: 31/10/2007, 12h46
  4. [eCommerce] Cherche script de statistiques sur les ventes d'un site d'e-commerce
    Par pimpmyride dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 3
    Dernier message: 23/03/2007, 11h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo