Discussion :

[Rizen]

Bonjour,

Je suis actuellement en train de modéliser un MCD pour un un site (fictif) de ventes et d'achats. Chaque client doit pouvoir gérer un panier d'articles qui une fois valider permet de générer une facture finalisant l'achat.

En soit le problème est des plus classiques. Ce qui me tracasse en revanche c'est le caractère "temporaire" des articles du panier. En effet un panier est associé à un client qui doit le conserver.

Voici une ébauche (certaines entités comme le client ont été retirées) du MCD :



En faisant comment ça on devra toujours gérer l'ajout à la suppression des couple article-panier. Je doute vraiment que ça soit la solution :/
De même cette façon de faire ne permet pas de conserver les articles dans la facture.

Le panier doit-il rester une entité liés directement aux articles ? S'il faut attendre une validation du panier avant d'éditer la facture un simple attribut suffit-il et on gère le reste dans l'implémentation ou alors le contrôle peut-il se faire directement dans la base ?

J'aimerais également savoir si c'est une bonne chose de mettre directement le prix dans les articles. Je pense que c'est un problème dans le sens où on ne peut pas gérer l'historisation.

Merci de votre aide.

[Richard_35]

Bonjour Rizen,

Commençons par le début.
Ton schéma me semble incorrect : habituellement, dans les sites marchands, 1 panier n'appartient qu'à un seul client, donc :

Client -0,1---[Posséder]---(1,1)- Panier-0,n---[Contenir]---0,n- Article

[Rizen]

Exacte. C'est une bête erreur d'innatention lorsque j'ai refait un micro-mcd pour les besoin du posts. Je suis désolé.

Si on garde donc cette version, est-ce un problème de devoir insérer et supprimer en permanence les couples panier - article d'un point de vue de la conception ?

Le gros problème qui se pose cependant c'est que si on fait ça on ne saura pas historiser les articles achetés une fois la facture éditée. Et c'est à ce niveau que je coince.

[Richard_35]

Bonjour Rizen,

Si on garde donc cette version, est-ce un problème de devoir insérer et supprimer en permanence les couples panier - article d'un point de vue de la conception ?

==> non, aucun problème car (en rouge) :

Client -0,1---[Posséder]---(1,1)- Panier -0,n---[Contenir]---0,n- Article

Le gros problème qui se pose cependant c'est que si on fait ça on ne saura pas historiser les articles achetés une fois la facture éditée.

==> l'historisation des articles achetés n'a rien à voir avec le panier. Voyons ce que pourraient être les tables générées :

Client(IdClient, Nom, ...) ;
Article(IdArticle, Libelle, ...) ;

PanierEntete(IdPanier, #IdClient, Date, ...) ==> index unique sur #IdClient ;
PanierDetail(#IdPanier, #IdArticle, Qté, Prix, ...) ;

FactureEntete(IdFacture, #IdClient, Date, ...) ;
FactureDetail(#IdFacture, #IdArticle, Qté, Prix, ...).

[Rizen]

Très bien donc pour mettre à jour notre panier il suffira d'agir directement sur les couples de la table PanierDetail.

En revanche je ne comprends pas comment sont générées les tables factures.
Selon mes (maigres ?) connaissances on aurait plutôt obtenu :

FactureEntete(IdFacture, Date, ...) ;
FactureDetail(#IdFacture, #IdPanier, Qté, Prix, ...)

En effet on a deux 0.n entre facture et panier et aucune association entre facture et article. Enfin ça c'est selon mon modèle, après peut-être vous êtes-vous sur un autre schéma MCD.
De même vous avez placé l'idClient en tant que client étrangère de facture.

En conclusion cela veut dire qu'il faut rajouter des associations entre client et facture ainsi qu'entre facture et article (avec éventuellement une contrainte d'exclusion) ? Ou je fais complètement fausse route ?

[Richard_35]

Les paniers sont temporaires : ils sont donc supprimés, dès leur facturation (à moins que tu souhaites historiser les paniers, ce que les sites marchands habituels ne font pas).

La facture est donc liés à un client, pour un panier existant au moment où le client valide ce panier (bouton : "Commander" ou "Poursuivre la commande", en général). Il ne faut donc pas stocker IdPanier mais IdClient (qui avait un panier temporaire au moment de la commande définitive).