Discussion :

[beyo]

Bonjiour,

je suis en train de créer un cms de vente en ligne et j'ai un souci au niveau de la gestion des options pour les produits. Voici mon système :

* = clé primaire

je définis :
des critères :
(ex : couleur, taille...)
=> table Critere
id_crit *
nom_crit

des options pour chaque critère
(rouge,vert, bleu, L, XL...)
=> table Options
id_opt *
id_crit
nom_opt

pour des produit
(ex: Tshirt)
=> table Produit
id_prod *
nom_prod


je veux pouvoir, par exemple pour les exemples donnés), avoir les combinaisons parmi :
Tshirt rouge L
Tshirt vert L
Tshirt bleu L
Tshirt rouge XL
Tshirt vert XL
Tshirt bleu XL

mais évidemment pas :
Tshirt bleu rouge
Tshirt bleu vert
Tshirt rouge vert
Tshirt L XL

il me manque donc ma(mes ?) table(s) de croisement dans la(les)quelle(s) j'aurais toutes les combinaisons choisies parmi celles possibles.
je ne pense pas qu'un table avec une liste de type texte de chaque combinaisons soit une bonne solution pour des raisons de "requétage"
Table Combi_option
id_prod *
combinaison * (ex: rouge,L )

je ne peux pas non plus définir une table avec un nombre prédéfini d'option pour une combinaison
il peux y avoir 1, 2...n critères qui entrent en compte selon le produit.

Pouvez vous me suggérer une structure pour ma ou mes tables intermédiaires de croisement ?

merci d'avance.

[Richard_35]

Bonjour Beyo,

Hum... un peu compliqué... et tu vas trop vite.

Suggestion :
Produit
- id_prod (PK)
- nom_prod
...

Taille
- id_taille (PK)
- nom_taille
...

Couleur
- id_couleur (PK)
- nom_couleur
...

A ce stade, nous avons les relations suivantes :
Produit ---(0,n)---[est disponible en]---(0,n)--- Taille ;
Produit ---(0,n)---[est disponible en]---(0,n)--- Couleur.

Il faut donc une entité association :
Produit_Taille_Couleur
- id_prod (PK)
- id_taille (PK)
- id_couleur (PK)
- qté (par exemple)
...

Relations finales
Produit ---(0,n)---[est disponible en]---(1,1)--- Produit_Taille_Couleur ;
Taille ---(0,n)---[est présente]---(1,1)--- Produit_Taille_Couleur ;
Couleur ---(0,n)---[est présente]---(1,1)--- Produit_Taille_Couleur.

A moins que tu n'aies une raison particulière d'utiliser ta structure de données.

[beyo]

merci pour la réponse qui est très claire, mais effectivement la solution proposée ne me convient pas : comme je l'ai indiqué à la fin de mon message, je ne peux pas présupposer combien de critères (taille, couleur, ...) ni d'option pour chaque critère va devoir être utilisée par un type de produit (ex: pour un produit tshirt : couleur et taille, mais aussi porquoi pas "marque", type d'encolure, et pour un bonnet, la couleur et marque seulement ..., avec un nombre type de produit indéfini et qui pourrait évoluer, de même que les critères et options )
Peut-^tre est-ce que je me leurre en pensant pouvoir avoir une structure assez "générique" (critère, option) pour pouvoir gérer les relations. C'est juste que si je définis en dur ces critères : table taille, table couleur... et en créant les associations qui vont bien, je ne vois pas comment au niveau de la programmation je pourrais généraliser. Dans l'exemple que vous proposer je serais obligé de coder "en dur" les noms des tables, et d'utiliser un script différent à chaque fois que je change de type de produit...

je ne sais pas si je suis assez clair dans ma demande et mes explications, car j'avoue que je ne suis pas un pro de la partie conception "stricte"

[Richard_35]

OK, je m'en doutais...

Mais, il me semble que tu y étais presque.

Critere
- id_crit (PK)
- nom_crit
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
1   couleur
2   taille
...

Critere_Option
- id_crit (PK)
- id_opt (PK)
- nom_opt
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
1   1   rouge
1   2   vert
...
2   1   L
2   2   XL
...

Produit
- id_prod (PK)
- nom_prod
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
1   TShirt TOTO
2   TShirt TITI
3   Pantalon TATA
...

Combi_Critere_Option
- id_prod (PK)
- id_crit (PK)
- id_opt (PK)
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
1   1   1
1   1   2
3   1   2
...

Relations
Critere ---(1,n)---[possède les options]---(1,1)--- Option ;
Critere_Option ---(0,n)---[est associé à]---(1,1)--- Combi_option (via id_crit/ id_opt) ;
Produit ---(1,n)---[possède les critères/options]---(1,1)--- Combi_option.

Concrètement
- choix du produit ;
- liste déroulante pour choix du critère ;
- liste déroulante pour choix de l'option pour le critère choisi.

Peut-être faut-il prévoir des familles de produits pour établir une cohérence entre une famille de produits et un critère (pas de taille XL pour les chaussures, par exemple).

[beyo]

Avant tout, merci de prendre le temps de te pencher sur mon problème.

je ne suis pas sur de tout comprendre dans la conception proposée :
Pourquoi dans Critere_Option id_crit est est PK ? Ne devrait-elle pas être une FK ?
Pourquoi la première relation associe critère à option, car il n'y a pas de Option dans la conception que vous proposez ?
Dans Combi_Critere_Option, il y a
1 1 1 => TShirt TOTO couleur rouge
1 1 2 => TShirt TOTO couleur vert
3 1 2 => Pantalon TATA couleur rouge.

mais ça ne fonctionne pas car je souhaite avoir comme combinaison quelque chose du type
TShirt TOTO couleur rouge ET taille XL
TShirt TOTO couleur vert ET taille L
Pantalon TATA couleur rouge ET marque Levis ET coupe droite
les combinaisons d'options n'allant pas les une sans les autres (ex il faut une taille ET une couleur pour définir un Tshirt, il faut une couleur, une marque et un type de coupe pour un pantalon)

C'est justement sur cette façon de regrouper que je sèche.

PS: La remarque sur les familles de produits est judicieuse. Je vais réfléchir à ce que ça implique comme ajout/modification.

[Richard_35]

Il est un peu tard... nous voyons cela demain, si tu veux.
Bonne nuit.

[beyo]

Bonjour,
j'ai repensé à tout et je pense avoir une bonne piste :

Produit
id_prod (PK)
nom_prod

Produit_Combi
id_prod (PK)
id_combi (PK)

Combi_Critere
id_combi (PK)
id_crit (PK)

Critere
id_crit (PK)
nom_crit

Option
id_opt (PK)
id_crit (PK)
nom_opt

Ainsi pour une combinaison :
par exemple couleur rouge ET taille XL

Produit_Combi permet d'associer une combinaison à un produit (couleur rouge ET taille XL)

et

Combi_Critere permet de définir le contenu de la combinaison (avec id_crit et non id_opt pour ne pas avoir de combinaison impossible (couleur rouge et couleur verte)

par contre ce qui me gèene c'est qu'il faut définir sans doute une table combinaison
Combinaison
id_combi (PK)

qui ne sert qu'à générer des id unique de combi... mais je ne vois pas comment l'intégrer autrement. Que pensez-vous de ce système ?

[souviron34]

moi ce qui me dérange ce sont les appellations.. et du coup la structure sous-jacente..


Pour moi, ce que tu appelles "options" ne sont que des valeurs des critères, et ce que tu appelles "critères" ne sont que des propriétés des produits..

[Richard_35]

Bonjour Souviron34 et Beyo,

Souviron34 n'a pas tord... mais bon, restons, pour l'instant, dans ta terminologie, Beyo.

Ton MCD me semble correct : en fait, il ajoute "une couche" de paramètre. C'est une très bonne idée.

Pour reprendre, dans l'ordre :

Pourquoi dans Critere_Option id_crit est est PK ? Ne devrait-elle pas être une FK ?

==> C'est vrai, id_crit est aussi une FK. C'est le couple id_crit/id_opt qui est PK. Mais tu sembles l'avoir pris en compte dans ton dernier MCD.

Pourquoi la première relation associe critère à option, car il n'y a pas de Option dans la conception que vous proposez ?

==> id_opt "ne vit" que via id_crit : c'est le couple id_crit/id_opt qui donne le nom de l'option.

mais ça ne fonctionne pas car je souhaite avoir comme combinaison quelque chose du type
TShirt TOTO couleur rouge ET taille XL
TShirt TOTO couleur vert ET taille L
Pantalon TATA couleur rouge ET marque Levis ET coupe droite

==> Attention, il ne faut pas confondre structure des données (MCD) et artifice de présentation de ces données. Il faut s'occuper, d'abord, de la structure des tables (en "vertical") ; la présentation "horizontale" en découlera avec des requêtes et/ou code.

par contre ce qui me gèene c'est qu'il faut définir sans doute une table combinaison
Combinaison
id_combi (PK)

==> Exact. Tu pourrais même donner un nom à ta combinaison (combinaison pour pantalon, pour chemise, etc...).

Que pensez-vous de ce système ?

==> Pour résumer, cela me paraît pas mal. Penses à établir, concrètement, les relations avant de développer.

[beyo]

Tu pourrais même donner un nom à ta combinaison (combinaison pour pantalon, pour chemise, etc...).

Ok, Richard_35 tel que tu le présentes, la Combinaison a un sens en elle même :
Combinaison
id_combi (PK)
nom_combi

et pour ce que j'en comprends ma structure aussi a un sens et je pourrais peut-être faire mon développement à partir de là.

MAIS, je ne suis pas un expert en conception (loin de là).
C'est pourquoi le message de souviron34 , ainsi que ta remarque me laissent penser que même si l'idée est "bonne", elle est encore bancale et pourrait être rigidifiée

Or, par ignorance, je ne comprends pas trop les remarques de souviron34 :

ce que tu appelles "options" ne sont que des valeurs des critères

est-ce que cela signifie qu'il n'est pas cohérent d'avoir une table Option à part entière ? Dans ce cas, comment peut on ranger les valeurs nécessaires ? A moins que la remarque suggère un nom plus en relation avec les critère, comme renommer la table Option en Critere_Option ?
Même remarque pour :

ce que tu appelles "critères" ne sont que des propriétés des produits..

Qaunt à la remarque

il ne faut pas confondre structure des données (MCD) et artifice de présentation de ces données

ma remarque indiquait qu'un produit pouvait avoir des combinaisons de PLUSIEURS "critères" à la fois, c'est pourquoi je ne suis pas sûr de comprendre non plus votre remarque.

En tout cas, merci de m'aider à progresser à affiner ma "logique"

PS:
mon ajour de la table Combi_Produit répond-elle du même coup à la suggestion :

Peut-être faut-il prévoir des familles de produits pour établir une cohérence entre une famille de produits et un critère

[Richard_35]

Souviron34 pourrait, peut-être, confirmer ou infirmer, mais il 'agit plus de terminologie que de fond (si j'ai bien compris). Malgré tout, un produit possède un ou plusieurs critères (donc table des critères/propriétés) et un critère possède une ou plusieurs options (donc table des options/valeurs de critère).

***

Quant à la remarque

il ne faut pas confondre structure des données (MCD) et artifice de présentation de ces données

ma remarque indiquait qu'un produit pouvait avoir des combinaisons de PLUSIEURS "critères" à la fois, c'est pourquoi je ne suis pas sûr de comprendre non plus votre remarque.

==> ma remarque était suite à ta présentation "en horizontal" :

TShirt TOTO couleur rouge ET taille XL
TShirt TOTO couleur vert ET taille L
Pantalon TATA couleur rouge ET marque Levis ET coupe droite

==> pour obtenir ce que tu dis, il faut une structure de données en table, donc, en "vertical", en quelque sorte.
***
***

PS:
mon ajout de la table Combi_Produit répond-elle du même coup à la suggestion :

Peut-être faut-il prévoir des familles de produits pour établir une cohérence entre une famille de produits et un critère

==> eh non. Pour cela, il faudrait associer une famille de produit (chemise, pantalon) à une combinaison, et non un produit à une combinaison.
***

[Richard_35]

Pour information, je pars en congés demain matin : tu trouveras, sans doute, une bonne âme pour finaliser ce fil.

[tatayo]

Bonjour,
Si ça peut aider, voici comment est organisé l'ERP que nous utilisons:
Dimension
IdDim, NomDim
Une dimension peut être la taille, le poids, la couleur, la longueur...

Occurrence de dimension
IdDim, IdOcc, Nom
Pour la couleur par exemple, chaque occurrence représente une couleur.

Groupe de dimension
IdGrp, NomGroupe

Une table croisée qui indique la liste des dimensions dans un groupe. On peut par exemple créer un groupe taille/couleur pour les vetements:
Dim_Grp_Dim:
IdGrp
IdDim
Rang

Ensuite on a l'article:
IdArt, IdGrp,...

Pour chaque article, on affecte un groupe de dimension.

Et l'uvc
IdUvc, IdArt,...

Pour un article donné, une uvc est une déclinaison, dans notre exemple une taille et une couleur données. Pour celà on a une table fille pour chaque uvc/dimension, avec l'occurrence qui va bien:
uvc_occ:
IdUvc,IdDim,IdOcc


Ainsi ou peut affecter autant de dimension que nécessaire à un article, et créer toutes les déclinaisons (uvc) souhaitées.

Tatayo.

[CinePhil]

J'ai parcouru la discussion un peu en diagonale parce que ce qui m'a géné, c'est qu'on part des tables avant de parler du modèle des données (MCD Merisien).

Ce domaine étant complexe à modéliser, et il a déjà été abordé dans le forum Schéma, il faut vraiment y aller pas à pas en partant du MCD.

Admettons que nous ayons les produits finaux, mais décris succinctement, suivant, en restant dans le domaine vestimentaire :
Produit
prd_id / prd_description
1 / T-Shirt rouge de taille XL
2 / T-shirt rouge de taille L
3 / T-shirt vert de taille M
4 / T-shirt blanc de taille S
5 / Pantalon noir de taille 40
6 / Pantalon gris de taille 45
7 / Chaussures noires de pointure 38
8 / Chaussures beiges de pointure 40

On constate :
1) qu'il y a des familles de produits : T-shirt, Pantalon, Chaussures ;
2) que le critère "couleur" s'applique à toutes les familles de produits ;
3) que la taille s'exprime de deux manières différentes (40 ou XL) selon la famille de produit ;
4) que la taille des chaussures s'appelle "pointure" et que c'est différent de la taille des pantalons.

1) Il faut commencer par répartir les produits finaux en familles (ou catégories, types... l'appellation qui vous convient).

Règle de gestion :
Un produit est classé dans une seule famille et une famille peut classer plusieurs produits.

MCD 1 :
produit -1,1----classer----0,n- famille

Tables :
famille (fam_id, fam_libelle)
1 / 'T-shirt'
2 / 'Pantalon'
3 / 'Chaussures'

produit (prd_id, prd_id_famille, prd_description...)
1 / 1 / T-Shirt rouge de taille XL
2 / 1 / T-shirt rouge de taille L
3 / 1 / T-shirt vert de taille M
4 / 1 / T-shirt blanc de taille S
5 / 2 / Pantalon noir de taille 40
6 / 2 / Pantalon gris de taille 45
7 / 3 / Chaussures noires de pointure 38
8 / 3 / Chaussures beiges de pointure 40

2) Ensuite on va définir l'association entre les familles et les critères pour interdire à des T-shirts d'avoir une pointure.

Règle de gestion :
Une famille de produits est caractérisé un à plusieurs critères et un critère caractérise de une à plusieurs familles de produits.

MCD 2 :
famille -1,n----caractériser----1,n- critere

Tables :
famille (fam_id, fam_libelle) => sans changement
1 / 'T-shirt'
2 / 'Pantalon'
3 / 'Chaussures'

critere (crt_id, crt_libelle)
1 / 'Couleur'
2 / 'Taille'
3 / 'Pointure'

crt_caracteriser_fam (ccf_id_critere, ccf_id_famille)
1 / 1 => Couleur / T-shirt
1 / 2 => Couleur / Pantalon
1 / 3 => Couleur / Chaussures
2 / 1 => Taille / T-shirt
2 / 2 => Taille / Pantalon
3 / 3 => Pointure / Chaussures

3) La difficulté commence pour interdire aux pantalons d'avoir une taille XL !
Il faut modéliser le fait que le couple {critere, famille} ne peut prendre que certaines valeurs.

On va d'abord modifier le MCD 2 pour transformer l'association en entité.
MCD 3 :
famille -1,n----posséder----(1,1)- caracteristique -(1,1)----référer----1,n- critere

=> Les cardinalités entre parenthèses signifient qu'il s'agit d'une identification relative.

Cela ne change rien aux tables, si ce n'est le nom de la table associative crt_caracteriser_fam qu'on peut remplacer par caracteristique et, par voie de conséquence, le préfixe des colonnes.
caracteristique (car_id_critere, car_id_famille)
1 / 1 => Couleur / T-shirt
1 / 2 => Couleur / Pantalon
1 / 3 => Couleur / Chaussures
2 / 1 => Taille / T-shirt
2 / 2 => Taille / Pantalon
3 / 3 => Pointure / Chaussures

4) Maintenant, nous pouvons ajouter au MCD 3 les valeurs possibles pour les caractéristiques.

Règle de gestion :
Une caractéristique accepte de une à plusieurs valeurs et une valeur s'applique à une à plusieurs caractéristiques.

MCD 4 :
famille -1,n----posséder----(1,1)- caracteristique -(1,1)----référer----1,n- critere
valeur -1,n----appliquer----1,n------------------|

Tables :
famille (fam_id, fam_libelle) => sans changement
critere (crt_id, crt_libelle) => sans changement
caracteristique (car_id_critere, car_id_famille) => sans changement
valeur (val_id, val_libelle...)
1 / 'rouge'
2 / 'vert'
3 / 'blanc'
4 / 'noir'
5 / 'gris'
6 / 'beige'
7 / 'XL'
8 / 'L'
9 / 'M'
10 / 'S'
11 / '38'
12 / '40'
13 / '45'

car_appliquer_val (cav_car_id_critere, cav_car_id_famille, cav_id_valeur)
1 / 1 / 1 => Couleur / T-shirt / rouge
1 / 1 / 2 => Couleur / T-shirt / vert
1 / 1 / 3 => Couleur / T-shirt / blanc
1 / 2 / 4 => Couleur / Pantalon / noir
1 / 2 / 5 => Couleur / Pantalon / gris
1 / 3 / 4 => Couleur / Chaussures / noir
1 / 3 / 6 => Couleur / Chaussures / beige
2 / 1 / 7 => Taille / T-shirt / XL
2 / 1 / 8 => Taille / T-shirt / L
2 / 1 / 9 => Taille / T-shirt / M
2 / 1 / 10 => Taille / T-shirt / S
2 / 2 / 12 => Taille / Pantalon / 40
2 / 2 / 13 => Taille / Pantalon / 45
3 / 3 / 11 => Pointure / Chaussures / 38
3 / 3 / 12 => Pointure / Chaussures / 40

5) Maintenant, il faut associer les produits finis aux triplets {critère, famille, valeur} par le même mécanisme que précédemment en transformant l'association appliquer du MCD 4 en entité et en associant cette nouvelle entité au produit.

MCD 5 :
valeur -1,n--------(1,1)- propriete -(1,1)---1,n- caracteristique
produit -1,n----avoir----1,n---|

Tables :
caracteristique (car_id_critere, car_id_famille) => sans changement
valeur (val_id, val_libelle...) => sans changement
produit (prd_id, prd_id_famille, prd_description...) => sans changement
propriete (prp_car_id_critere, prp_car_id_famille, prp_id_valeur) => ex-table car_appliquer_val
prd_avoir_prp (pap_id_produit, pap_prp_car_id_critere, pap_prp_cr_id_famille, pap_prp_id_valeur)
1 / 1 / 1 / 1 => Couleur / T-shirt / rouge
1 / 2 / 1 / 7 => Taille / T-shirt / XL
2 / 1 / 1 / 1 => Couleur / T-shirt / rouge
2 / 2 / 1 / 8 => Taille / T-shirt / L
3 / 1 / 1 / 2 => Couleur / T-shirt / vert
3 / 2 / 1 / 9 => Taille / T-shirt / M
4 / 1 / 1 / 3 => Couleur / T-shirt / blanc
4 / 2 / 1 / 10 => Taille / T-shirt / S
5 / 1 / 2 / 4 => Couleur / Pantalon / noir
5 / 2 / 2 / 12 => Taille / Pantalon / 40
6 / 1 / 2 / 5 => Couleur / Pantalon / gris
6 / 2 / 2 / 13 => Taille / Pantalon / 45
7 / 1 / 3 / 4 => Couleur / Chaussures / noir
7 / 3 / 3 / 11 => Pointure / Chaussures / 38
8 / 1 / 3 / 6 => Couleur / Chaussures / beige
8 / 3 / 3 / 12 => Pointure / Chaussures / 40

EDIT : Comme on a la famille dans la dernière table, on peut supprimer l'association du MCD 1 et la clé étrangère dans la table produit.

C'est au niveau du processus (du logiciel) qu'il faudra bien jouer avec tout ça pour ne pas associer un produit T-shirt à la famille chaussures !

[souviron34]

J'ai parcouru la discussion un peu en diagonale parce que ce qui m'a géné, c'est qu'on part des tables avant de parler du modèle des données (MCD Merisien).

Tu as fourni l'explication qui était sous-jacente sous mes remarques..





Comme je ne suis pas un grand fan (ni praticien) des BD relatonnelles, l'expression et le découpage me dérangeait dans la partie "conception"...

Maintenant, je n'étais pas plus intervenu que ça car pas de la partie...

[JPhi33]

Bonjour à tous,

Je vous conseille de lire cette discussion dans laquelle une problématique similaire est abordée.

[Redlox]

Bonjour à tous,
Tout d'abord merci à tous et surtout à JPhi33 pour ce sujet qui m'as permis d'éclaircir pas mal de zones d'ombres sur mon projet même si je n'utilise pas exactement ce modèle.

J'avais juste une question mais peut-être ai-je mal compris quelque chose.
Comment fait on pour sélectionner un article (donc combinaison d'attributs) en fonction de ses attributs via une requête?

Par exemple, je cherche dans ma base le Tee-shirt : Noir - Taille S - Coton pour récupérer sa référence et le manipuler.

Je ne suis pas un expert en conception de BDD, peut-être que cette question devrait être dans un autre forum, si c'eest le cas, désolé.



la réponse à ma question :

Il suffit de faire des jointures avec la même table chose que je viens d'apprendre grâce à cette page.

Salut à tous.