Discussion :

[razily]

Bonjour à tous ,
voilà je débute , et ne vous étonnez pas si ma question semble évidente mais voilà je souhaite créé un site de vente de chaussures dans un premier temps :
d'abord j'ai commencé à réflechir sur les attibuts que peuvent prendre l'objet Chaussure : bon la syntaxe c juste pour simplifier

Table Chaussure {
- reference (identifiant )
- Pointures (36 , 37 ,..)
- Couleurs (marron , noir etc )
-Marques (Gucci etc )
-Type (homme /femme)
- images (type jpeg pour les photos )
-prix

}

après pour chaque chaussure y a des détails sur le produit genre bon je dirai des informations aditionnelles sur le produit ( vous pouvez jettez un coup d'oeil sur le site de zalando et c à peu prêt le même principe sauf que je souhaite afficher les infos essentielles

Tables détails {

#reference chaussure

- Forme du talon: Talon large
- Hauteur du talon: 5 cm
- Informations additionnelles: bout fleuri, boucle
- Système de fixation: Fermeture éclair
- Bout de la chaussure: Rond
- Semelle: Synthétique de haute qualité
- Dessus / Tige: Cuir




}

au départ je pensais créer 2 tables , mais après je pensais que s'il n'y a qu'une seule réference pour chaque chaussure , comme je dois gérér dans la base si pour une paire de chaussure X(avec réference 001) il y a plusieurs couleurs (gris , noir ) et disponible en plusieurs (pointures 35 - 37 etc )

je ne sais pas si vous avez saisi mon problème comment dois je procéder pour bien organiser sa base afin d'éviter les doublons dans ce genre de cas

merci

[Derek Corgan]

Je suppose que Chaussure identifie un modèle de chaussure.

Remarque 1 :
Chaussure et détail n'ont pas lieu d'être scindées vu que la relation est 1,1 entre les deux (détail d'un modèle de chaussures)

Une chaussure est commercialisée en plusieurs coloris et en plusieurs tailles.
Il faut donc une table permettant de stocker les informations relatives aux coloris dans lesquels un modèle de chaussure est commercialisés (relation 1-n).
Idem pour taille d'un modèle(1-n).
En tout cela fait 3 tables.

[CinePhil]

Ces problèmes de chaussures avec des attributs multiples sont de la même sorte que les vêtements et il y a déjà eu plusieurs discussions sur ce sujet dans le présent forum.
Utilise l'outil de recherche.

Pour te mettre sur la bonne voie, puisque tu débutes, commence par lire mon billet de blog sur les règles de gestion puis l'article de SQLPro sur la modélisation conceptuelle de données de la méthode Merise.

En prime, voici un début de réflexion qui raccrocheras ce que tu auras lu du domaine que tu souhaites modéliser.

Règle de gestion :
Une marque propose de un à plusieurs modèles et un modèle est proposé par une seule marque.

MCD :
marque -1,n----proposer----1,1- modele

Tables :
marque (mrq_id, mrq_nom...)
modele (mod_id, mod_id_marque, mod_nom...)

Si une référence correspond à un modèle, quelle que soit sa taille, tu peux inclure la référence dans la table modele.
modele (mod_id, mod_id_marque, mod_reference, mod_nom...)

Si par contre la référence change selon les caractéristiques du modèle (couleur, taille...), alors il faut compléter le MCD. Je te laisse chercher comment.

Tu remarqueras que dans les tables, j'ai utilisé un identifiant (mrq_id et mod_id) qui n'a aucune signification. On n'utilise pas une référence signifiante, susceptible de changer, alphanumérique, comme identifiant d'une table mais toujours des identifiants anonymes de type entier.

Bon courage et n'hésite pas à venir nous proposer ton schéma.

[razily]

Ces problèmes de chaussures avec des attributs multiples sont de la même sorte que les vêtements et il y a déjà eu plusieurs discussions sur ce sujet dans le présent forum.
Utilise l'outil de recherche.

Pour te mettre sur la bonne voie, puisque tu débutes, commence par lire mon billet de blog sur les règles de gestion puis l'article de SQLPro sur la modélisation conceptuelle de données de la méthode Merise.

En prime, voici un début de réflexion qui raccrocheras ce que tu auras lu du domaine que tu souhaites modéliser.

Règle de gestion :
Une marque propose de un à plusieurs modèles et un modèle est proposé par une seule marque.

MCD :
marque -1,n----proposer----1,1- modele

Tables :
marque (mrq_id, mrq_nom...)
modele (mod_id, mod_id_marque, mod_nom...)

Si une référence correspond à un modèle, quelle que soit sa taille, tu peux inclure la référence dans la table modele.
modele (mod_id, mod_id_marque, mod_reference, mod_nom...)

Si par contre la référence change selon les caractéristiques du modèle (couleur, taille...), alors il faut compléter le MCD. Je te laisse chercher comment.

Tu remarqueras que dans les tables, j'ai utilisé un identifiant (mrq_id et mod_id) qui n'a aucune signification. On n'utilise pas une référence signifiante, susceptible de changer, alphanumérique, comme identifiant d'une table mais toujours des identifiants anonymes de type entier.

Bon courage et n'hésite pas à venir nous proposer ton schéma.

oui , c'est ce que je vais faire avant tout car je dois commencer par me renseigner là dessus merci pour vos liens
je vous tiens au courant des évolutions

merci

[razily]

Je suppose que Chaussure identifie un modèle de chaussure.

Remarque 1 :
Chaussure et détail n'ont pas lieu d'être scindées vu que la relation est 1,1 entre les deux (détail d'un modèle de chaussures)

Une chaussure est commercialisée en plusieurs coloris et en plusieurs tailles.
Il faut donc une table permettant de stocker les informations relatives aux coloris dans lesquels un modèle de chaussure est commercialisés (relation 1-n).
Idem pour taille d'un modèle(1-n).
En tout cela fait 3 tables.

merci pour cette éclaircissement mais justement je souhaite savoir quand il faut créer une table selon les types de cardinalité ??
y a til une règle ???

[CinePhil]

je souhaite savoir quand il faut créer une table selon les types de cardinalité ??
y a til une règle ???

Réponse dans mon blog.

[razily]

Réponse dans mon blog.

très bon article que je vais moi même imprimé mais il faut que je m'habitue à interpréter les cardinalités (min,max) car c la la base i-e quelle question il faut se poser pour déterminer dans les relation la valeur (min,max)
par exemple :
A (min,max )------ associe --- B (min,max)
car c à partir de çà que je pourrai déterminer s'il faudrait créer une table ou pas ??
Autre question sur ce blog dans le deuxième processus pourquoi a t on supprimer les autres lignes , quand on a expliqué par exemple que que les cardinalités de l'association 02 sont inversées par rapport à l'association 05
et après on a supprimé le 05 ???
----------------------------------------------
mais bon après quelque réflexion sur le sujet voici ce que je propose :
les règles :
1- chaque chaussure est réferencée par une clé (id)
2 à chaque chaussure donnée on peut l'avoir sous différentes pointures et couleurs
3 - chaque chaussure a sa propre description

ceci dit j'ai créé 3 tables comme vous le préconisez :
comme vous pouvez le voir sur l'image (pièces jointe)
chaque table est identifiée par une clé et reliés par un clé secondaire qui est la clé de chaussure .
comme je n'ai pas d'outil simple pour Merise ou UML j'ai utilisé Access qui me met directement le type de relation .
j'ai essayé aussi de remplir des données et elles semblent logiques

[CinePhil]

très bon article que je vais moi même imprimé mais il faut que je m'habitue à interpréter les cardinalités (min,max) car c la la base i-e quelle question il faut se poser pour déterminer dans les relation la valeur (min,max)

J'ai répondu à ta question dans le blog.
D'une manière générale, on se pose la question : "Combien de fois une entité peut ou doit-elle participer à l'association ?"

par exemple :
A (min,max )------ associe --- B (min,max)

Je vais l'écrire un peu différemment :
A minA,maxA----associe----minB,max B

car c à partir de çà que je pourrai déterminer s'il faudrait créer une table ou pas ??

À partir des règles de gestion, on établi les cardinalités et les cardinalités déterminent s'il faut une table associative ou pas.

Autre question sur ce blog dans le deuxième processus pourquoi a t on supprimer les autres lignes , quand on a expliqué par exemple que que les cardinalités de l'association 02 sont inversées par rapport à l'association 05
et après on a supprimé le 05 ???

Je reprends ci-dessous les deux cas :

02) A -0,1----associer----1,1- B
05) A -1,1----associer----0,1- B

Ce sont bien les deux mêmes inversés non ?
Inutile de décrire deux fois le même cas !

[razily]

Je reprends ci-dessous les deux cas :

Ce sont bien les deux mêmes inversés non ?
Inutile de décrire deux fois le même cas ![/QUOTE]

Code :

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

1
2
3
02) A -0,1----associer----1,1- B
05) A -1,1----associer----0,1- B

Ici si j'interprète la ligen 02

Code :

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

1
2
02) A -0,1----associer----1,1- B

ici il se peut qu'un A n'est pas associé à B donc c vide
comme si dire qu'une personne ne travaille à aucun projet
alors que dans la ligne 05

Code :

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

1
2
05) A -1,1----associer----0,1- B

au moins 1 dans A est associé donc pour chaque A il devra y avoir un lien
comme si dire qu'une personne est forcément lié à un projet !!
----------------------
et votre avis sur la table ??? concernant les chaussures ??
merci

[CinePhil]

Ne mélange pas la théorie et la pratique !

personne 0,1----associer----1,1- projet

n'est évidemment pas pareil que

personne 1,1----associer----0,1- projet

Mais c'est pareil que

projet 1,1----associer----0,1- personne

Dans mon article, il faut considérer A et B comme des entités types quelconques pouvant être permutées. Si tu remplaces A par B et B par A dans la 02, tu obtiens la 05, et vice-versa. {(0,1), (1,1)} est le même ensemble de cardinalités que {(1,1), (0,1)} car un ensemble mathématique n'est pas ordonné.

[Richard_35]

Bonjour Razily et CinePhil,

Je me permets de m'immiscer, CinePhil...

@Razily :

Code :

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

1
2
02) A -0,1----associer----1,1- B
05) A -1,1----associer----0,1- B

Ce sont bien les deux mêmes inversés non ?
Inutile de décrire deux fois le même cas !

==> dans le billet de CinePhil, il ne faut retenir (et garder sous le coude) que les 10 derniers cas restants : la redondance que tu as repérée est déjà épurée dans ces 10 cas restants :

.../... On remarque que les cardinalités de l'association 02 sont inversées par rapport à l'association 05 .../...

[CinePhil]

Richard, c'est moi qui avait signalé que les deux cas sont inversés ; il y a eu une erreur de QUOTE dans le message de Razily.

[razily]

et qu'en pensez vous de ma proposition sur la base des données des chaussures , y a t il des points à améliorer !!ou cela suffit largement .
bon dans un premier temps je tiens à simplifier les chose

[CinePhil]

Je n'avais pas vu ton schéma.

1) Externaliser les marques.
Règle de gestion :
Une chaussure est vendue sous une seule marque et une marque peut vendre plusieurs chaussures.

MCD :
marque -0,n----vendre----1,1- chaussure

2) Pourquoi la colonne "images" est-elle au pluriel ?
Si tu veux associer plusieurs images à une chaussure, externalise les images.
Règle de gestion :
Une chaussure peut être représentée par plusieurs images et une image ne représente qu'une chaussure.

MCD :
image -1,1----représenter----0,n- chaussure

3) Externalise les types
Règle de gestion :
Une chaussure est qualifiée d'un seul type et un type peut qualifier plusieurs chaussures.

MCD :
type -0,n----qualifier----1,1- chaussure

4) Les détails semblent être des caractéristiques.
Règle de gestion :
Une chaussure possède de une à plusieurs caractéristiques et une caractéristique peut s'appliquer à plusieurs chaussures.
caracteristique -0,n----appliquer----1,n- chaussure


Tu as voulu modéliser directement avec des tables, tu vois que tu aurais dû commencer par un MCD ; tout est à revoir !

Et réfléchis bien à la distinction entre "modèle de chaussures" et "paire de chaussures". Un modèle existe en plusieurs pointures, voire en plusieurs couleurs, mais des mocassins de modèle X auront toujours les mêmes caractéristiques (tout cuir ou pas) quelles que soient la pointure ou la couleur.

Je pense que les colonnes de ta table "Details" sont en fait différentes caractéristiques et que tes caractéristiques sont des particularités qui devraient constituer chacune une table.

Règles de gestion :
Une chaussure existe en une à plusieurs tailles et une taille peut être disponible pour plusieurs chaussures.

Une chaussure peut exister en plusieurs couleurs et une couleur peut être disponible pour plusieurs chaussures.

Dans tous les schémas de ce message, l'entité "chaussure" signifie pour moi "modèle de chaussures".

MCD :
taille -0,n----existe----1,n- chaussure -1,n----existe----0,n- couleur

[razily]

Bonjour ;

j'ai repris un par un les attributs en suivant les règles et le MCD et cela se résume comme suit / à la fin je mettrai en pièces jointes la nouvelle table :

1)

Code :

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

1
2
3
1 chaussure possède 1 seul nom unique 
1 nom unique est attribué à 1 chaussure

MCD:

Code :

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

1
2
chassure --1,1----possède---1,1---nom

2)

Code :

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

1
2
3
1 chaussure est fabriquée par 1 marque 
1 marque peut fabriquer plusieurs chaussures

MCD:

Code :

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

1
2
chassure --1,n----est fabriquée---0,n---marques

3)

Code :

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

1
2
3
1 chaussure est liée  par 1 type (homme ou femmes ) ou les deux (mixtes) 
1 type  peut concerner  plusieurs chaussures

MCD:

Code :

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

1
2
chassure --1,n----est liée ---1,n---type

4)

Code :

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

1
2
3
1 chaussure possède  1 ou plusieurs images  
1 image   est forcément liée à 1 chaussure

MCD:

Code :

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

1
2
chassure --1,n----est liée ---1,n---image

5)

Code :

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

1
2
3
1 chaussure est rattachée à 1 ou plusieurs pointures 
1 pointure est liée à 1 chaussure

MCD:

Code :

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

1
2
chassure --1,n----est liée ---1,n---pointure

6)

Code :

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

1
2
3
1 chaussure est rattachée à 1 ou plusieurs couleur
1 couleur est liée à 1 chaussure

MCD:

Code :

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

1
2
chassure --1,n----est liée ---1,n---couleur

on crée une nouvelle table pour les règles MCD ayant des cardinalités n dans les 2 parties

c'est le cas de marques , types , images , couleurs et pointures :
couleur et pointure peut être remises dans une même table car
à chaque couleur on a une pointure

les 3 tables restantes doivent être créées à part : pour faciliter les requêtes aussi
table marques
tables types
tables images

donc au final voici le schéma que je propose :

donc au final y a 6 tables à proposer

(pièce jointe)

à travers cette image j'ai une question ou une remarque :
remarquez l'association entre
- les tables chaussures et images
- et chaussures et les autres

avec chaussure et image , j'ai pris l'identifiant de l'image et je l'insère dans la table chaussure : chaussure (id, nom, ..., image_path ) - image (id, nom_path)

mais avec les autres tables j'ai justé inséré l'identifiant de la table chaussure !!
et ma question y a t il une différence ??? et quel est selon vous la solution appropriée car je sais que même dans les 2 cas je dois faire une jointure .

merci

[CinePhil]

1)

Code :

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

1
2
3
1 chaussure possède 1 seul nom unique 
1 nom unique est attribué à 1 chaussure

MCD:

Code :

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

1
2
chaussure --1,1----possède---1,1---nom

Tu n'as pas l'impression que le nom est plutôt une propriété de la chaussure au lieu d'une entité type ?
D'ailleurs, des cardinalités (1,1 - 1,1) sont généralement l'indice d'une mauvaise modélisation.

2)

Code :

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

1
2
3
1 chaussure est fabriquée par 1 marque 
1 marque peut fabriquer plusieurs chaussures

MCD:

Code :

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

1
2
chaussure --1,n----est fabriquée---0,n---marques

Là tu as modélisé ceci :
Une chaussure est fabriquée par une à plusieurs marques et une marque peut fabriquer plusieurs chaussures.

3)

Code :

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

1
2
3
1 chaussure est liée  par 1 type (homme ou femmes ) ou les deux (mixtes) 
1 type  peut concerner  plusieurs chaussures

MCD:

Code :

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

1
2
chaussure --1,n----est liée ---1,n---type

Presque !
Là tu as modélisé un type lie une à plusieurs chaussures.

4)

Code :

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

1
2
3
1 chaussure possède  1 ou plusieurs images  
1 image   est forcément liée à 1 chaussure

MCD:

Code :

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

1
2
chaussure --1,n----est liée ---1,n---image

Règle mal écrite ou mauvaises cardinalités ?
Tu as modélisé :
Une chaussure est liée à une à plusieurs images et une image lie une à plusieurs chaussures.

5)

Code :

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

1
2
3
1 chaussure est rattachée à 1 ou plusieurs pointures 
1 pointure est liée à 1 chaussure

MCD:

Code :

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

1
2
chassure --1,n----est liée ---1,n---pointure

Idem !
En plus tu changes de verbe dans les règles de gestion mais tu ne changes pas le nom de l'association dans le MCD.
Et de préférence, utilise un verbe à l'infinitif pour les associations.

6)

Code :

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

1
2
3
1 chaussure est rattachée à 1 ou plusieurs couleur
1 couleur est liée à 1 chaussure

MCD:

Code :

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

1
2
chassure --1,n----est liée ---1,n---couleur

Idem !
Tes règles de gestions ne sont pas assez précises pour vérifier si le MCD est juste ou pas.
Il semble juste mais "est liée à 1 chaussure" est insuffisant dans la règle de gestion. C'est "1 seule" ou, comme tu l'as modélisé et qui seble logique, "une à plusieurs" ?

on crée une nouvelle table pour les règles MCD ayant des cardinalités n dans les 2 parties

MCD = Modèle conceptuel de données. C'est un schéma qui modélise l'ensemble des données et qui contient des associations entre entités types.

Chaque entité type deviendra une table de la BDD et chaque associations ayant les deux cardinalités maximales à n entraîneront la création de tables associatives supplémentaires. Mais ce n'est pas le seul cas où il en faut. Voir mon article de blog que tu connais déjà.

c'est le cas de marques , types , images , couleurs et pointures

Dans tes morceaux de MCD, ce sont des entités types. Ce n'est donc pas à cause des cardinalités que tu créeras des tables pour ces données.

couleur et pointure peut être remises dans une même table car
à chaque couleur on a une pointure

Non ! Rien dans tes règles de gestion ne te permet de conclure à cette opération.
Une paire de chaussure de référence AB123 a pour couleur "noir" et existe en pointures 37, 38, 39, 40, 41, 42, 43, 44, 45.
=> 1 association entre chaussure et couleur et 9 associations entre chaussure et pointure.
Une autre paire de chaussure de référence AC4521 a pour couleurs brun et noir et n'existe dans ton magasin qu'en pointures 40, 41, 42, 43, 44, 45.
=> 2 associations entre chaussure et couleur et 6 associations entre chaussure et pointure.
Toutes les combinaisons couleur + pointure peuvent potentiellement exister mais elles n'existent probablement pas toutes réellement.

les 3 tables restantes doivent être créées à part

Pourquoi à part ?
Elles font partie du modèle de données

: pour faciliter les requêtes aussi

Rien à voir avec la facilité des requêtes qui n'a pas à entrer en compte lors de la conception. Ni même après d'ailleurs !

donc au final voici le schéma que je propose :

Et il est toujours aussi faux !

Reprenons à partir de la règle de gestion 2, que je récris.
2) 1 chaussure est fabriquée par 1 marque et 1 marque peut fabriquer plusieurs chaussures.

MCD 2) :
marque -0,n----fabriquer----1,1- chaussure

Tables :
marque (mrq_id, mrq_nom)
chaussure (chs_id, chs_id_marque, chs_nom...)

3) 1 chaussure convient à un à deux genres (homme ou femmes ) et un genre peut convenir à plusieurs chaussures.

MCD 3) :
genre -0,n----convenir----1,2- chaussure

Tables supplémentaires :
genre (gnr_id, gnr_libelle)
gnr_convenir_chs (gcc_id_chaussure, gcc_id_genre)

4) 1 chaussure possède 1 ou plusieurs images et 1 image est liée à 1 seule chaussure.

MCD 4) :
chaussure -1,n----posséder----1,1- image

Table supplémentaire :
image (img_id, img_id_chaussure, img_fichier...)

On pourrait même ici faire une identification relative puisque une image est fonctionnellement dépendante de la chaussure. Mais ça va t'embrouiller alors laissons tomber.

5) 1 chaussure existe en 1 à plusieurs pointures et 1 pointure peut être disponible pour plusieurs chaussures.

MCD 5) :
chaussure -1,n----exister----0,n- pointure

Tables supplémentaires :
pointure (ptr_id, ptr_libelle)
chs_exister_ptr (cep_id_chaussure, cep_id_pointure)

6) 1 chaussure est disponible en 1 à plusieurs couleurs et 1 couleur peut exister pour plusieurs chaussures

MCD 6) :
chaussure -1,n----exister----0,n- couleur

Tables supplémentaires :
couleur (clr_id, clr_libelle)
chs_exister_clr (cec_id_chaussure, cec_id_couleur)

Au total, voilà les 9 tables qui correspondent à tes règles de gestion améliorées :
marque (mrq_id, mrq_nom)
chaussure (chs_id, chs_id_marque, chs_nom...)
genre (gnr_id, gnr_libelle)
gnr_convenir_chs (gcc_id_chaussure, gcc_id_genre)
image (img_id, img_id_chaussure, img_fichier...)
pointure (ptr_id, ptr_libelle)
chs_exister_ptr (cep_id_chaussure, cep_id_pointure)
couleur (clr_id, clr_libelle)
chs_exister_clr (cec_id_chaussure, cec_id_couleur)


Mais peut-être que les règles de gestions sont encore incomplètes !
Impossible par exemple ici de traiter le cas où une chaussure existerait en noir et en brun dans les pointures 40 à 43 et aussi en jaune dans les pointures 44 et 45. Ce modèle permettrait seulement de savoir que cette chaussure existe d'une part dans les 3 couleurs et d'autre part dans toutes les pointures citées, sans pouvoir marier couleur et pointure.

C'est peut-être ce à quoi tu faisais allusion en disant :

couleur et pointure peut être remises dans une même table car
à chaque couleur on a une pointure

Auquel cas il faut prévoir non pas deux associations binaires mais une association ternaire :
chaussure -1,n----exister----0,n- couleur
pointure -0,n---------|

Ce qui peut se traduire par cette règle de gestion :
Une chaussure existe dans un à plusieurs couples {couleur, pointure} et un couple {couleur, pointure} peut exister pour plusieurs chaussures.

Et on aurait alors la table associative suivante :
chs_exister_clr_ptr (cecp_id_chaussure, cecp_id_couleur, cecp_id_pointure)

Cette table associative remplacerait les tables chs_exister_clr et chs_exister_ptr.

[razily]

Bonjour ;

MErci beaucoup , j'ai pris du temps pour assimiler tout et retenir l'essentiel . j'ai également aussi modifié en grande partie mes tables en rajoutant certaines tables associatives notament pour les entités .
Ceci dit , il y a 10 tables avec la table Détail !!

merci bcp
voici le résultat final je vais me baser sur cette base pour coder les requêtes

encore merci

mais en parlant de couleur et de pointure :

1) une couleur (rouge) doit être liée à une pointure (36)
2) une couleur (rouge) peut être liée à plusieurs pointures (36 ,40 etc )
3) une couleur (rouge ) peut ne pas être lié à aucune pointure (n'existe pas )
4)1 pointure s'il existe doit être liée à une couleur
5)1 pointure s'il existe doit peut être liée à une ou plusieurs couleurs
6) 1 pointure peut ne pas être liée à une couleur s'il n'existe pas

Code :

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

1
2
3

Couleur  -- 0,n----lier -------0,n----Pointure

dans ce genre de cas je me demande s'il préferable de créer une table associative genre afin

Code :

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

1
2
lier (id , id_couleur , id_pointure)

ou mieux encore

Code :

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

1
2
lier (id , id_couleur , id_pointure,id_pointure)

permettant de connaître toutes les pointures 36 de couleur rouge par exemple

[CinePhil]

Quelques remarques encore...

1) Tables associatives
Inutile d'ajouter un identifiant artificiel dans les tables associatives. La clé primaire d'une table associative est composée des identifiants des impliquées dans l'association.
Relis bien la composition de mes tables ! Par exemple :

chs_exister_ptr (cep_id_chaussure, cep_id_pointure)

2) Table Details
Presque tous ces détails devraient aussi être des tables de référence associées à la table Chaussure, selon le même principe que pour les pointures, couleurs...

Par exemple...
Règle de gestion :
Une chaussure est équipée d'un seul type de fermeture et un type de fermeture peut équiper plusieurs chaussures.

MCD :
fermeture -0,n----equiper----1,1- chaussure

Table supplémentaire :
fermeture (frm_id, frm_libelle)

Modification de la table chaussure :
chaussure (chs_id, chs_id_marque, id_fermeture, chs_nom...)

Idem pour style, type de talon, dessus, doublure, matériau de semelle.

On peut considérer par contre que semelle intérieure amovible est une propriété booléenne qui peut aller directement dans la table chaussure.

Quant à la quantité, c'est une propriété de la chaussure si tu ne gères qu'un seul magasin de chaussures.

Bref, ta table Details n'a pas lieu d'être !

[razily]

Quelques remarques encore...

1) Tables associatives
Inutile d'ajouter un identifiant artificiel dans les tables associatives. La clé primaire d'une table associative est composée des identifiants des impliquées dans l'association.
Relis bien la composition de mes tables ! Par exemple :


2) Table Details
Presque tous ces détails devraient aussi être des tables de référence associées à la table Chaussure, selon le même principe que pour les pointures, couleurs...

Par exemple...
Règle de gestion :
Une chaussure est équipée d'un seul type de fermeture et un type de fermeture peut équiper plusieurs chaussures.

MCD :
fermeture -0,n----equiper----1,1- chaussure

Table supplémentaire :
fermeture (frm_id, frm_libelle)

Modification de la table chaussure :
chaussure (chs_id, chs_id_marque, id_fermeture, chs_nom...)

Idem pour style, type de talon, dessus, doublure, matériau de semelle.

On peut considérer par contre que semelle intérieure amovible est une propriété booléenne qui peut aller directement dans la table chaussure.

Quant à la quantité, c'est une propriété de la chaussure si tu ne gères qu'un seul magasin de chaussures.

Bref, ta table Details n'a pas lieu d'être !

Merci ,
bon sans doute une meilleure idée car cela me permet de gerer facilement certaines tables qui ne necessitent pas d'être mise à jour comme fermeture style etc .. car leur valeur sont déjà définie à l'avance .
donc si je résume pour les associations ayant n comme valeur maximale dans les 2 côtés doivent être mis avec des tables associatives gardant juste
les identifiants des 2 entités :

pour les entités dont le type de relation a au moins 1,1
on crée une table en mettant un clé secondaire dan l'autre table (ou c pas 1,1)

encore merci :

voici la version corrigée , je pense que je pourrai entamer la suite

[CinePhil]

Si semelle_interieure est une colonne de type booléen, c'est bon.

donc si je résume pour les associations ayant n comme valeur maximale dans les 2 côtés doivent être mis avec des tables associatives gardant juste
les identifiants des 2 entités :

pour les entités dont le type de relation a au moins 1,1
on crée une table en mettant un clé secondaire dan l'autre table (ou c pas 1,1)

Attention à tes interprétations de ce qui a été dit dans la discussion !
Réfère toi à mon article de blog qui explique clairement ce qu'il faut faire selon les cardinalités que l'on rencontre.