Discussion :

[fsmrel]

Je suppose que je dois donc me séparer du panier et qu'il aurait plus sa place en tant qu'attribut.

Hum... Un client peut-il posséder plus d’un panier au fil du temps ?

Si oui, il n’y a plus bijection...

[keustip]

Hum... Je dirais que non, je pense qu'un panier peux contenir 0 , 1 ou plusieurs produits au fil du temp, par contre un client n'as qu'un seul et unique panier.

[fsmrel]

je pense qu'un panier peux contenir 0 , 1 ou plusieurs produits au fil du temp, par contre un client n'a qu'un seul et unique panier.

Ce qui revient à dire que la bijection est de retour, donc que comme vous l’évoquiez, le panier est phagocyté et devient un attribut de la classe d'entités CLIENT. Dans ces conditions, que deviennent les attributs quantitty et total_price hébergés par l’actuelle classe d'entités PANIER ?

[keustip]

Dans ces conditions, que deviennent les attributs quantitty et total_price hébergés par l’actuelle classe d'entités PANIER ?

C'est une bonne question, mais du coup je suis un peu perdu car les attributs me semblent être nécessaire au bon fonctionnement d'un panier.

[escartefigue]

Bonjour Keustip, bonjour François


Je me permets d'intervenir dans cette discussion pour revenir sur cette question structurante soulevée un peu plus haut.
En effet, les réponses qui ont suivi ne sont pas suffisamment précises pour lever toute ambiguïté.

Hum... Un client peut-il posséder plus d’un panier au fil du temps ?

Si oui, il n’y a plus bijection...

Si l'on veut pouvoir connaitre l'historique des paniers du client, alors on a bel et bien plusieurs paniers pour un même client.
Auquel cas pas de bijection
Si l'on veut conserver les informations relatives au client une fois que son panier est soldé (livré, facturé et réglé en totalité), là encore, pas de bijection

Selon vos réponses aux deux points ci-dessus, on y verra plus clair

@Keustip : pensez à remercier Fsmrel en votant pour les réponses qui vous on mis sur la voie

[fsmrel]

Bonjour à vous deux,

Merci à escartefigue qui est le bienvenu !

Dans ces conditions, que deviennent les attributs quantity et total_price hébergés par l’actuelle classe d'entités PANIER ?

C'est une bonne question, mais du coup je suis un peu perdu car les attributs me semblent être nécessaire au bon fonctionnement d'un panier.

Un panier contient un ou plusieurs produits et on sait les compter (fonction COUNT de SQL) pour chaque panier (client), ce qui fait que l’attribut quantity de PANIER est à considérer comme redondant, donc inutile. Pour chaque produit dans le panier (client) on a le prix du produit, donc on sait calculer le montant total, ce qui fzit que l’attribut total_price est lui aussi redondant et peut disparaître, non ?

[keustip]

Tout d'abord je tiens encore a vous remercier pour l'attention porter a mon MCD.
Je pense que je ne vais pas inclure le panier directement dans la base.
J'ai essayer de simplifier celui-ci afin de commencer plus rapidement le développement de mon site.

Voici donc ce que j'en conclue :




Je reviendrais faire un retour un peu plus tard dans la journée !

[escartefigue]

Bonjour,

Panier ou commande, n'est-ce pas la même chose ?

Quoi qu'il en soit, la cardinalité 1,n côté [COMMANDE] implique qu'une commande peut être passée par plusieurs utilisateurs...
À corriger en [UTILISATEUR] 0,n --- (passer) --- 1,1 [COMMANDE]

Ensuite, le montant de la commande ne doit pas être un attribut de [COMMANDE], il faut le calculer en multipliant le prix unitaire de chaque produit ou prestation par la quantité respective de chaque produit ou prestation.

Plus encore, l'identifiant client ne doit pas apparaitre au niveau conceptuel dans l'entité-type [COMMANDE], c'est seulement au niveau tabulaire (MLD et MPD) que cet identifiant devenu foreign key sera recopié dans la table [COMMANDE]

Attention aussi au typage des données et à leur longueur.
Par exemple, id_produit en varchar(n) est un mauvais choix. Pour les identifiants, privilégiez un type entier (integer), et simplifiez-vous la vie en laissant le SGBD l'attribuer.
Dans Looping, ça se traduit par le choix d'un type compteur qui deviendra "identity", "auto_increment", "number" ou "serial" selon le choix du SGBD.

[fsmrel]

Bonsoir,


Le mcd que vous proposez est raisonnable, il est en effet plus sage de partir sur quelque chose de simple, quitte à enrichir au fur et à mesure.

Dans ce qui suit je n’ai pas tenu compte des commentaires d’escartefigue qi va trop vite


Un premier lot remarques :

– Pour le bien de la vie de la base de données, les identifiants doivent de préférence être invariants donc ne doivent être porteurs d’aucune sémantique. Combien s’en sont mordu les doigts de n’avoir pas procédé ainsi et ont utilisé des codes sortant de leur imagination ou récupérés à gauche et à droite, susceptibles d’être modifiés dans le temps, même quand il s’agit de choses prétendument invariantes, telles que les numéros de SIRET (histoire vécue par votre serviteur, qui heureusement avait veillé au grain...)

Ainsi, vous pouvez laisser le soin au SGBD d’affecter les valeurs de l’attribut principal id_client et gérer vos propres identifiants alternatifs (codes), permettant d’accéder à chaque utilisateur grâce à son code, tout en laissant au SGBD le soin de prendre le relais, retrouver les commandes de cet utilisateur au moyen de l’identifiant principal (clé primaire en SQL) pour naviguer. Si la valeur d’un identifiant est à modifier (par exemple un numéro de Siret quand l’administration s’est trompée et ça lui arrive souvent...), une seule ligne de la table CLIENT est à modifier, au lieu de N lignes si la table COMMANDE fait N fois référence à la table CLIENT.

- La classe d'entités Commande doit être débarrassée de l’attribut id_client. En effet c’est le SGBD qui l’ajoutera automatiquement à la structure de la table (SQL) générée, vous vous en rendrez compte en examinant le contenu de la fenêtre « Script SQL » de Looping, après avoir remplacé la cardinalité 1,n côté Commande par 1,1, car normalement une commande n’est effectuée que par un et un seul utilisateur, alors que selon votre MCD, une commande est effectuée par au moins un utilisateur.

Bon courage !

[keustip]

Je vous fais un retour pour vous dire merci a tout les deux pour toute vos indications, cette fois je vais prendre un peu plus de temps pour tout remettre en ordre !

[fsmrel]

Bonjour,

Juste un mot en passant.

Une commande est composée de produits et ça n’est pas elle qui achète.
L’association Achat pourrait donc être renommée en Composer.
Cette association est à doter d’un attribut Quantité car elle correspond en réalité à la ligne de commande.
Par ailleurs du point de vue de la base de données dans Looping, vous pourriez lui affecter le nom logique LigneDeCommande (nom de la table en SQL).

[fsmrel]

Bonjour,

En complément,

Dans le MCD ci-dessous, vous noterez que l’identifiant principal de la classe d'entités Utilisateur est l’attribut UtilisateurId, tandis que l’identifiant alternatif est UtilisateurCode. Même principe pour les autres classes d'entités. Je rappelle que la gestion de l’identifiant principal est à sous-traiter à SQL, tandis que nous, les utilisateurs, créons et utilisons à notre convenance l’identifiant alternatif.



A propos du nom logique

Je joins une image pour illustrer ce que j’ai écrit hier :

[keustip]

J'ai encore un peu de mal à saisir la connexion entre produit et commande, et pourquoi celle-ci s'appelle "logiquement" Ligne_de_commande, mais je m'en vais réapprendre un peu de théorie sur le fait de passer du MCD au MLD grâce aux cardinalité car il me semble que ce soit a ce niveau que je trouverais mes réponses.


Je re-soumet mon MCD actuel :



Je vois aussi que j'ai 2 cardinalités "0,n" (entre catégorie->produit et utilisateur->Commande) , qui diffère du MCD proposé par fsmrel.
Alors je préfère demander si ma logique est bonne, car pour moi :
-Une catégorie peut ne contenir aucun produit.
-Un utilisateur peut ne pas effectuer de commande.

[fsmrel]

Bonsoir keustip,

J'ai encore un peu de mal à saisir la connexion entre produit et commande, et pourquoi celle-ci s'appelle "logiquement" Ligne_de_commande

Ce que vous désignez par connexion est une association entre classes d’entités. Conceptuellement, il est logique de dire que la commande passée par un client auprès d’un fournisseur fait référence aux produits de celui-ci, donc dire qu’une commande est composée de noms de produits est un raccourci qui n’est pas aberrant.  

Cela dit, si je passe une commande, je nomme les N produits que je souhaite acheter, donc ma commande va comporter N lignes, tout comme la facture transmise par le fournisseur sera composée à son tour de N lignes de facture, chacune faisant référence elle aussi à un produit. Cela vous choque-t-il ? Le nom logique permet au niveau MLD (modèle logique des données) puis au niveau MPD (Modèle physique des données, c’est-à-dire SQL), d’utiliser un nom plus facile à interpréter, alors que COMPOSER (qui va bien au niveau MCD) est vague, ambigu au stade SQL, mais si des noms comme LigneDeCommande et LigneDeFacture ne vous conviennent pas, utilisez des noms avec lesquels vou vous sentez à l’aise. L’important est que la sémantique y trouve son compte.

Je resoumets mon MCD actuel

Petit souci : il ne s’affiche pas...

Une catégorie peut ne contenir aucun produit.

Dans un MCD on modélise la finalité, d’où 1,N. Je suis d’accord que dans la base de données en production il puisse y avoir (à un instant t) des catégories non référencées par des produits, mais là encore faisons le distinguo entre MCD et SQL.

Un utilisateur peut ne pas effectuer de commande.

D’accord, va pour 0,N.