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.

[escartefigue]

Bonjour François

Concernant ceci

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.

Ce qui vaut pour les utilisateurs vis à vis des commandes, vaut aussi pour les catégories vis à vis des produits.
Si une catégorie peut ne concerner aucun produit, alors 0,n s'impose :

[CATEGORIE] 0,n --- (appartenir) --- 1,n [PRODUIT]

D'une façon générale, pour les typologies (catégories, codes devises, codes langues...), on privilégie 0,n plutôt que 1,n : il est fréquent qu'à un instant "t" on ne connaisse aucune correspondance dans telle ou telle typologie.

@Keustip
De plus, je suis surpris par la cardinalité maximale n coté [PRODUIT], si un produit peut appartenir à plusieurs catégories, c'est peut-être que la notion de catégorie est un peu fourre-tout et qu'il conviendrait de séparer cette notion unique en plusieurs distinctes.
Pouvez-vous donner des exemples de produits ayant plusieurs caractéristiques, et les valeurs (libellés) de ces caractéristiques, histoire d'éclairer ma lanterne. Ou plus simplement, la liste des caractéristiques (ou un extrait). Merci

[keustip]

@fsmrel
Aucun problème pour ce qui est du nom a proprement parler, mais j'avoue que le concept n'est pas encore très clair pour moi , j'essaierais de prendre le temps de potasser tout ça.

@escartefigue
Tout bien réfléchis vous avez raison il me semble plus logique qu'un produit n'est qu'une seule catégorie.
Je ne pourrais même pas vous citer un exemple de produit en ayant plusieurs !

[fsmrel]

Bonjour à vous deux,

Si une catégorie peut ne concerner aucun produit, alors 0,n s'impose :

[CATEGORIE] 0,n --- (appartenir) --- 1,n [PRODUIT]

Je reprends le thème de la finalité : du strict point de vue conceptuel, si les catégories s’appliquent exclusivement aux produits, la cardinalité 1,N est la seule possible. En effet, ce serait un contre-sens de prétendre qu’une catégorie peut ne concerner aucun produit : une telle catégorie ne peut légitimement pas exister. Comme je l’ai écrit dans mon précédent message, quand on quitte le niveau conceptuel pour passer au niveau SQL, les choses sont différentes, puisque, par exemple, on peut y créer une catégorie de façon anticipée, en attente plus ou moins longue de la connaissance des produits qui lui seront rattachés un jour.

D'une façon générale, pour les typologies (catégories, codes devises, codes langues...), on privilégie 0,n plutôt que 1,n : il est fréquent qu'à un instant "t" on ne connaisse aucune correspondance dans telle ou telle typologie.

Là encore, ceci ne vaut qu’une fois sorti du niveau conceptuel. C’est comme si dans la logique d’Aristote ou celle de Frege un syllogisme pouvait ne pas valoir à un instant "t". 

Quand tu évoques par exemple les codes devises, il est évident que dans la table SQL correspondante, on peut engranger tous les codes possibles et imaginables, mais conceptuellement, logiquement, philosophiquement, bref, dans le monde des idées, quel sens donner à cela ?

[escartefigue]

François, j'ai du mal à te suivre, pourquoi en ce cas la commande, qui ne concerne bien que l'utilisateur dans le présent contexte, ne serait-elle pas soumise à la même règle ?
Et ce faisant on aurait aussi [UTILISATEUR] 1,n ---(passer) --- 1,1 [COMMANDE]

De plus, comme le MCD doit être le reflet exact des règles de gestion, si celles-ci stipulent
"Rxxxx : une catégorie peut catégoriser zéro à plusieurs articles", alors tout va bien

[fsmrel]

pourquoi en ce cas la commande, qui ne concerne bien que l'utilisateur dans le présent contexte, ne serait-elle pas soumise à la même règle ?
Et ce faisant on aurait aussi [UTILISATEUR] 1,n ---(passer) --- 1,1 [COMMANDE]

Si l’utilisateur n'a le droit de ne rien faire d’autre que passer des commandes, effectivement c’est 1,N. S’il est concerné par un autre rôle (par exemple celui de modérateur ), alors c’est 0,N, n’est-il pas ?

De plus, comme le MCD doit être le reflet exact des règles de gestion, si celles-ci stipulent
"Rxxxx : une catégorie peut catégoriser zéro à plusieurs articles", alors tout va bien

Si les catégories servent non seulement pour les articles mais aussi pour d’autres types d’objets (façon big mac), d’accord.
Si les catégories sont exclusivement dévolues aux articles, la règle de gestion est à réécrire, la quantification existentielle (0,N) est à remplacer par la quantification universelle (1,N).

J'espère que keustip n'est pas trop déboussolé par nos échanges...

[fsmrel]

Bonsoir,

Aucun problème pour ce qui est du nom a proprement parler, mais j'avoue que le concept n'est pas encore très clair pour moi , j'essaierais de prendre le temps de potasser tout ça.

Avez-vous pu trouver un peu de temps ?