Discussion :

[nrgizgun]

Bonjour à vous,
Je suis actuellement en stage de fin de formation de DUT, et je travaille actuellement sur un projet de site de vente de costumes sur mesures.

Je suis donc en train de m’intéresser à la méthode merise que grâce à la spécialisation du dernier semestre de mon DUT je n’ai pas pu étudier (woopie ;( ).

Mon problème est le suivant, en espérant que vous pourrez m’aider :



Sur le site on pourra commander soit un pack (costume cravate chemise) soit une chemise ou une cravate au détail.

La première commande est donc obligatoirement un pack, pour les suivantes on peut choisir entre un pack ou bien la vente au détail.

Jusqu'à la ce n’est pas trop compliqué, la ou ça se corse c’est que c’est du sur mesure, et qu’il y a de nombreux paramètres possibles pour chaque groupes d’articles (veste, pantalon, chemise, cravate).

Concrètement pour une veste de costume il y a 15 points de personnalisation différents (type de col, allure générale de la veste, emplacement de la poche, etc.), et pour une cravate il y en a 5 qui n’ont rien à voir avec les précédents.





Bref avec ma faible formation en base de données et étant dans une entreprise absolument pas spécialisée dans le domaine de l’informatique, je galère un peu ;o


Si vous pouvez m’éclairer, merci d’avance

[nrgizgun]

Je vais essayer d'expliciter un peu mieux la chose, ça sera sans doute plus facile à comprendre.

Voila le schéma de base en pièce jointe, je précise de base car les attributs ne sont pas encore tous indiqués, les cardinalités non plus.
Il y a eu quelques modifications de structure depuis hier, tout cela n'est que le début pour moi.

Mon problème se pose donc au niveau produit.
On a donc une partition entre les costumes, les chemises, et les cravates.

A partir de la comment modéliser ceci:
Au cours du processus de commande, le client va passer par les différentes parties du costume:

Costume
|- Veste
| |- Tissu
| |- Type col
| |- Type bouton
|
|- Pantalon
| |- Coupe
| |- Plis
Chemise
|- Couleur
|- Style

Le mieux est de pouvoir avoir tout ceci lié afin de pouvoir faire des modifications au cours de la commande.

Enfin je continue à plancher dessus, merci d'avance



edit:
2 eme miniature = Première idée ( ne pas tenir compte des cardinalités/relations)

[nrgizgun]

Bon je ne sais pas si le triple-posting est bien vu par ici, mais même sans réponse, il me faut bien continuer mon travail !

Bref après lecture des cours, des tutoriaux j’arrive à un modèle se présentant sous cette forme qu’il va me falloir sans doute encore modifier. ;(

Pour se faire une idée de la chose :

• Un client s’enregistre, à partir de ce moment il ajouter ses mesures au système et passer une commande.
• On va oublier pour le moment la gestion du panier qu’il faut que je revoie
• Une commande porte sur des produits classés en 3 catégories :
  Costume Chemise Cravate.
• Chacun de ces produits à différents éléments personnalisables, (un nombre fini que je ne connais pas encore) et chaque élément à une caractéristique choisie parmi 3 ou 4.
• Chaque caractéristique est liée à un seul élément de produit.

Je pense qu’il y a un problème au niveau des cardinalités element -> caractElem sans savoir vraiment quoi faire.

Toute idée est la bienvenue

[ylarvor]

salut,

personnellement, je pense que je representerais le pack en parallele du costume, chemise, cravate.
Un pack comprend
id_pack
id_costume
id_chemise
id_cravate

un produit comprend
id pack 0-1
id costume 0-1
id chemise 0-1
id cravate 0-1

qu'en penses les autres ?

[nrgizgun]

Merci de ta réponse,

Après réflexion, j'ai pensé à supprimer de la bdd le principe de pack et de gérer cela sur un plan plutôt logiciel: permettre la commande d'un produit de chaque uniquement. (cf. schéma du dernier post)

Cela viens du fait que étant donné le nombre important de produits, chacun ayant des caractéristiques différentes; référencer toutes les combinaisons de produit passées va prendre énormément de place au fil des commandes.

Je ne suis pas un pro en BDD, il y a peut être moyen de faire mieux !

[Vladislav IV]

Voici ce que je propose :

Un client passe des commandes. Chaque commande concerne des éléments (cravates, chemise sur mesure, etc.), en une certaine quantité (on peut commander plusieurs exemplaires d'une même chemise).

Un élément (sur mesure, donc) appartient à un type (chemise, costume, cravate, pantalon, etc.) qui dispose de paramètres (type de col, taille...).

Un élément possède donc des paramètres valués (col "amidonné", taille "M").

L'inclusion (I) signifie que pour qu'un élément possède un paramètre, le type de l'élément doit également disposer de ce paramètre (une chemise sur mesure ne peut posséder le paramètre "poche poitrine" que si le type "chemise" dispose du paramètre "poche poitrine").

En espérant être utile

Au fait, les mesures du client peuvent faire partie de celui-ci, pas besoin de faire une entité MESURE.

[nrgizgun]

Cela m'a l'air sympathique, je regarderais plus en détail demain matin (gtm+7)

A propos de:

Au fait, les mesures du client peuvent faire partie de celui-ci, pas besoin de faire une entité MESURE.

J'ai utilisé cette méthode car lors de la création du client, on ne prend pas directement ses mesures, il faut donc les creer par la suite non?
Des mesures à initialisées a NULL ça fait pas très bien dans une base de données (surtout qu'il y en aura une 20aine).

Merci en tout cas, je me pencherais sur ces réponses le plus rapidement possible

[nrgizgun]

J’ai donc étudié et développé plus en détail la solution de Vladislav IV, et j’arrive au schéma ci-joint

Au niveau des modifications apportées, j’ai un peu changé les noms

Un produit est concerné par une commande, étant donné qu'il est a peu pret unique; mais ne serais il pas mieux de permettre au produit d’être lié à plusieurs commandes ? (afin d’éviter les redondances, si deux clients arrivent à commander le même produit, ou qu’un client veut recommander un produit qu’il a déjà acheté.)

Un paramètre est lié à un seul type, pour l’exemple, le PARAMETRE « Type de col » avec l’id 1 ne pourra être lié qu’avec le TYPE « chemise » d’id 3.

Au niveau de la valeur du paramètre l’idée que tu avais proposée me semblait intéressante, mais il nous faut pouvoir stocker dans une table ces valeurs, et je ne crois pas que ça soit possible en tant que simple propriété d’une relation :
Par exemple le paramètre boutonVeste aura pour valeurs: (1,’’Position1’’), (2,’’Position2’’), (3,’’Position3’’), il faudra en choisir une uniquement parmi ces 3 la.
J’ai pensé d’abord à ajouter l’entité à la relation posséder, mais ça allait poser problème pour l’inclusion. Je ne sais pas vraiment si je l’ai mis à la bonne place (ça suis la logique que j’avais mise en place précédemment).

Enfin merci grâce à ces réponses j’y vois un peu plus clair au fil des jours mais il va me falloir bientôt finaliser ; / !

Toutes remarques complémentaires pouvant m’aider est bien sûr bienvenue


ps: si un modérateur peut, et que ça ne le dérange pas, pourrait il changer le titre de ce sujet en "[MCD] Conception Web: Vente de costume sur mesure", plus explicite je pense pour les recherches futures

[Vladislav IV]

ne serais il pas mieux de permettre au produit d’être lié à plusieurs commandes ?

Pourquoi pas !

Concernant les valeurs : un élément possède des valeurs. Chaque valeur n'appartient qu'à un seul paramètre (les valeurs "Position1", "Position2", "Position3" sont des valeurs possibles du paramètre boutonVeste).

Inclusion : quant on associe une valeur à un élément, il faut reprendre le paramètre associé à cette valeur, et veiller à ce que le type de l'élément dispose bien de ce paramètre.

En ce qui concerne le panier, pourquoi un 0,1 ? Vous avez des paniers qui ne sont utilisés par personne ? Vous devriez peut-être mettre un 1,1, et supprimer les paniers non utilisés...

[Vladislav IV]

ne serais il pas mieux de permettre au produit d’être lié à plusieurs commandes ?

Après réflexion, non ! Car pour chaque nouvel élément commandé, il faudrait passer en revue toutes les valeurs de ses paramètres, et voir s'il n'y a pas déjà un élément avec exactement les mêmes valeurs... Ca risque d'être un joyeux bazar !!

[nrgizgun]

Bonjour, merci pour cette aide, et désolé pour cette réponse tardive.
Mais le décalage horaire et une réunion on fait que je n’ai pu répondre plus tôt.

Afin d’être plus en adéquation avec les futurs administrateurs du site, j’ai rajouté quelques éléments au schéma, et après quelques test des différentes requêtes à effectuer, je pense qu’on n’est pas loin d’un résultat qui marche (Pour le moment 6 cas d’utilisation qui marchent : p)

Tout d’abord, j’ai remis à l’ordre du jour l’idée de pack inclus à la base de données, il est toujours bon d’avoir deux sécurités, une logicielle, et une dans la bdd.

Un produit (pack1, pack2, pack3, chemise) a un prix, et un nom de tissu (70%soie, 30% laine, 100% synthétique) est composé de soit 1, soit 4 éléments (je pense que c’est gérable avec des triggers), la gestion des éléments étant identique à la dernière version de Vladislav IV.

La ou il y des petites modifications, c’est au niveau du panier qui est maintenant lié obligatoirement a un client, un client habite maintenant dans un pays et tout les textes auront maintenant un identifiant et seront liés à une table de traduction en anglais et français.

La relation "concerner" a été modifiée aussi, on ne peut pas ajouter de paramètres à une relation 1,1 (enfin Win'design me bip et me dis qu'il y a erreur )

Merci à vous, si vous voyez d'énormes fautes, merci de m'en faire part