Ventes à distance

Bonjour,


je dois réaliser un MCD dont le sujet est une société réalisant des ventes à distance.


Voici les contraintes présentes :

Chaque produit possède des caractéristiques techniques variables. Il faut par exemple pouvoir décrire une TV par son constructeur, sa taille d’écran, sa couleur, ses connexions, sa consommation en mode marche, sa consommation en mode veille, …. Pour un lecteur Blu-ray, constructeur, couleur, connexions et consommation sont également des caractéristiques à définir mais la taille d’écran n’est pas pertinente. De plus, d’un produit à l’autre, au sein d’une même catégorie, toutes les caractéristiques ne sont pas forcément décrites. Il sera donc nécessaire :

* De prévoir une liste globale des caractéristiques techniques,
* D’associer ces caractéristiques à chaque catégorie de produits,
* De permettre aux utilisateurs de fournir les valeurs des caractéristiques d’un produit uniquement sur les critères correspondant à sa catégorie et sans rendre leur saisie obligatoire.

- Un historique complet des prix (standard et remisé) de chaque produit doit être conservé.

- Une commande peut donner lieu à plusieurs livraisons, en fonction de la disponibilité des produits commandés. Toutefois, les frais de livraison ne dépendent que des articles à livrer et non du nombre de livraisons effectuées pour une commande.

- Une commande peut également donner lieu à plusieurs règlements (par exemple un règlement partiel par bon cadeau et un autre par carte bancaire).
- Une livraison ne sera effectuée que lorsque l’intégralité de la commande aura été réglée.


J'ai réalisé un début de modélisation pour ce cas.
Est-ce que la gestion des caractéristiques des produits ainsi que de l'historique des prix peut fonctionner comme cela ?
J'hésite également sur la manière de gérer la facturation/règlements et les livraisons.


En pièces jointes des annexes et le début de modélisation.


Merci d'avance pour votre aide :)

Ca a l'air plutot pas mal, avez-vous fini votre MCD ?

Merci

Bonjour,

Etes-vous sur que Caractéristique Technique est associé à Catégorie de Produit et non pas Produit ? Pour ne pas dire inclus dans celui-ci. Les éléments de description commun à une catégorie seront inclus dans ce dernier.
Si j'ai bien suivi , au même titre qu'une commande présente plusieurs lignes de produit commandé, la livraison (Objet) doit associer le produit livré pour une commande.
Je ne comprends pas trop la cardinalité 1/1 de Historique de Prix ; n'est-ce pas plutôt une association entre un Objet date( période début-fin) et le produit?
Je reprendrai plus posément votre post à un autre moment.

En attendant de vous lire bon courage

Bonjour,

Je place mes réponses sur le plan MCD uniquement, sans tenir compte de votre approche physique du modèle. Donc votre seul souci est de vous assurer que vous pouvez répondre à votre cahier des charges.

1) Caractéristiques technique : dans l'absolue ces informations sont seulement complémentaires ; les unes se rapportant à une catégorie (celle de l'entreprise) et l'autre au produit (le fournisseur); donc 2 Objets de dénomination différente et comme conséquence des cardinalités plus simple : un Produit une fiche technique, une Catégorie un descriptif complementaire. Mais il ne serait pas faux d'inclure ces informations dans leur Objet respectif : il faut y réfléchir.

2° la gestion livraison commande est toujours délicate à reprendre sous MCD. Pour le MLD MPD il est évident que vous ferez un suivi du livré (comme sur vos documents joints). Mais l'objectif du MCD est de s'assurer que ce suivi est possible.
Donc une mise en place de l'objet Livraison (ou plusieurs) avec des lignes pour chaque Produit livré. Ce dispositif vous permettra de reprendre plus tard les dates de livraison successive si nécessaire. Mais il manque la référence commande. Une association Commande Livraison est suffisante pour gérer votre ensemble Commande-Livraison.
Les frais de livraison sont inscrits dans la Commande. Le prix remisé (on ne tient toujours pas compte du chemin à parcourir) pourra être déduit en tenant compte de la date de Commande et de la période de validité de la remise.
3° Facturation/Réglement est correctement posé selon moi à ceci près : L'unicité est assurée que si la date est désignée comme clé complémentaire (je ne mets que très rarement l'objet Date dans le MCD ).
Maintenir la description de chaque entité au niveau du diagramme est un travail fastidieux ; le plus simple est d'établir un document à part pour chaque entité de votre MCD.
Les identifiant-1 etc sont plutôt du MLD (?)
L'établissement du MCD est diamétralement opposé à la démarche de l'informaticien ce qui en fait une de ses difficultés. Mais une fois tout en place, la phase suivante sera plus facile.
En reprenant votre cahier des charges tout me semble OK. Reste le positionnement de toutes des données élémentaires et de valider chaque point de votre cahier.

Merci pour votre réponse.

Vous vous êtes basé sur la première version du MCD, ou celle que je vous ai communiquée en MP pour formuler vos remarques ?

1) Donc pour ce qui est des caractéristiques techniques, il faudrait 2 entités ? Une liée à catégorie, et l'autre à produit ?

2) Livraison doit également être une entité ? Avec seulement une association livraison - commande ? Dans ce cas comment sont gérées les lignes de commandes livrées ?

3) "Facturation/Réglement est correctement posé selon moi à ceci près : L'unicité est assurée que si la date est désignée comme clé complémentaire" ? Je ne comprends pas bien.. Il faudrait une entité règlement avec une date de règlement faisant partie de la clé primaire ?

Bonjour,

Je me suis basé sur le modèle envoyé en MP

Caractéristique technique : Produit ou Catégorie ? Le domaine fonctionnel est différent donc l'identifiant des informations. Pour le MCD je choisirai l'option qui facilite la lecture : 2 objets différents ou fusionner les informations avec les Objets de référence.

Livraison : C'est un Objet. Dans la réalité de l'entreprise il comprend un entête (date de livraison, client, référence commande, transporteur, etc..) puis des lignes par produits livrés et en bas de page des informations complémentaire (à voir). Donc comme je le suggérai la Livraison comprend de une à n association "produit livré" avec l'Objet Produit en plus de celle Livraison-Commande. Et bien sur une association Client-Livraison

Règlement est une association entre Client et Commande. Mais une commande peut donner lieu à plusieurs règlement . Donc il faut prendre la date de règlement en compte en lui associant un objet "Date" (représentation standard) ou en insérant la date dans l'association et la signaler comme clé complémentaire (concaténé) de toutes les clés primaires des objets qui participe à l'association. Le cahier des charges prévoit-il une gestion des modes de paiement acceptés? auquel cas un Objet de plus dans votre modèle.

Bonjour,

Je préfère la dernière version de votre MCD qu'il faudrait afficher sur le forum par égard pour tous les participants.

Juste un point concernant les cardinalités :

Un Client peut compter de 0 à N commandes
Pour Caractéristique Produit et Catégorie la cardinalité est 1/1 ; c'est la raison pour laquelle je vous conseillais de fusionner Caractéristique technique et Catégorie Produit d'une part et Caractéristique Produit et Produit d'autre part.

Voilà il me semble correct et à vous de le valider avant de passer aux phases suivantes.

Bonne soirée

Ok pour le client.

Par contre, pourquoi 1,1 au niveau des caractéristiques ? Pourtant une caractéristique peut décrire plusieurs produits, et un produit peut avoir plusieurs caractéristiques. Et idem pour les catégories. Et si je mets un champ caractéristique dans catégorie et dans produit le problème est le même. Non ?

Et au niveau du règlement, si on choisit l'association règlement, et non pas une entité règlement, la cardinalité 0,n pour commande ne pose pas de problème sachant qu'une commande correspond à un seul client ?

Bonjour Skilly,

Cardinalité 1/1 pour les caractéristique Produit et Catégorie parce que dans la réalité cela n'aurait aucun sens. La similitude entre deux occurrences ne serait que pur hasard et impossible à gérer d'autant plus que les fournisseurs ne le font pas.

Les cardinalités permettent de prendre en compte une évolution dans le temps. A un moment donné le Client n'a fait aucune commande, Une commande n' a pas encore été réglée partiellement ou totalement. Un Client peut avoir plusieurs Commandes en cours.
Cela répond-il à votre question?

Je ne comprends toujours pas la logique pour les caractéristiques de cette façon..
Par exemple une caractéristique "17 pouces" peut être associé à plusieurs écrans (plusieurs produits).
Il me semble plus logique d'associer une entité caractéristique à catégorie, et d'associer cette même entité caractéristique à produit avec une association porteuse d'une valeur (comme fait dans l'une de mes propositions de mcd). Mais peut être que je me trompe.

Sinon ok pour l'association règlement dans ce cas, comme une commande peut ne pas avoir encore été réglée partiellement ou totalement.

Bonjour,

D'accord, mais vous ne considérez qu'une seule donnée parmi d'autres et comment gérer les autres? Avec un SQL (SGBDR) vous aurez la faculté de sélectionner une Catégorie ou un Produit répondant à un ou plusieurs critères souhaités. Vous pourriez envisager cette solution pour une approche de critères plus simple (typlologique) : Moniteur,GSM, Radio, Télévision, PC etc. Mais ce n'aurait qu'un intérêt limité.
Ce que vous proposez dans votre dernière réponse est de reporter les caractéristiques Produit et Catégorie dans l'association Produit/Catégorie et Caractéristique?Les fiches technique Catégorie et Produit ne portent sûrement pas les mêmes éléments de description? Si oui, alors une seule association est suffisante.

Mes connaissances en la matière sont limités. Mais visitez quelques sites Internet de Vente pour vous faire une idée.

Bonjour,

MP par SKillyl

D'après ce que je comprends dans l'énoncé il n'y a pas de caractéristiques différentes entre les catégories et les produits :

"Chaque produit possède des caractéristiques techniques variables. Il faut par exemple pouvoir décrire une TV par son constructeur, sa taille d’écran, sa couleur, ses connexions, sa consommation en mode marche, sa consommation en mode veille, …. Pour un lecteur Blu-ray, constructeur, couleur, connexions et consommation sont également des caractéristiques à définir mais la taille d’écran n’est pas pertinente. De plus, d’un produit à l’autre, au sein d’une même catégorie, toutes les caractéristiques ne sont pas forcément décrites. Il sera donc nécessaire :

* De prévoir une liste globale des caractéristiques techniques,
* D’associer ces caractéristiques à chaque catégorie de produits,
* De permettre aux utilisateurs de fournir les valeurs des caractéristiques d’un produit uniquement sur les critères correspondant à sa catégorie et sans rendre leur saisie obligatoire."


Un cahier des charges doit-être respecté. Mais comment?

Le modèle que vous proposez peut satisfaire à cette obligation. Il faut le valider.
Une catégorie regroupe plusieurs produits de fournisseurs différents ou non. Chacun d'eux est accompagné ou non de caractéristiques technique qui lui est propre. Donc à une Catégorie vous associez de 0 à n produits et donc autant de caractéristiques technique Produit. La cardinalité de l'association Produit-Caractéristique est 0/1
Pour pallier à des manques d'informations vous prévoyez une fiche technique au niveau de la Catégorie : cardinalité 1/1 ou 0/1 . Mais quelles informations prendre puisque chaque produit est différent par nature? A vous de voir.

Bonne journée