Discussion :

[Lasurprise]

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 :



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

[escartefigue]

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 ?

[Lasurprise]

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 !

[escartefigue]

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

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

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