Discussion :

[razily]

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


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.

merci , en verité voici ce que çà représente ces champs :

Code :

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

1
2
3
4
5
6
7
8
9
10
Marque:	Caterpillar
Style:	A bout rond
Couleur:	Noir
Fermeture:	Lacets
Type de talons:	Compensé
Dessus:	Cuir
Doublure:	Textile
Matériau de semelle:	Caoutchouc
semelle interieure : oui/non

Encore une question , comment procède t on pour le requêtes si je dois faire une jointure entre chaussure et genre par exemple ou chaussure et couleur

je passe directement par exister_clr
en faisant

Code :

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

1
2
3
select id_dentifiant_couleur 
from exister_clr  
where id = identifiant_chaussure

et apres je cree une autre requete pour recuperer la valeur de la couleur ??

en fait la nécessité de ces tables exister_clr et même ici
y a pas un risque de doublon dans cette table (exister_clr)

1 chaussure (01) de couleur rouge (identifian_couleur :02)
1 chaussure (01) de couleur noir(identifian_couleur :03)
etc ....

voilà , encore merci

[CinePhil]

comment procède t on pour le requêtes si je dois faire une jointure entre chaussure et genre par exemple ou chaussure et couleur

Si tu veux connaître en quelles couleurs est disponible la chaussure d'identifiant 1, tu fais cette requête :

Code SQL :

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

1
2
3
4
SELECT cl.coul_libelle
FROM couleur cl
INNER JOIN exister_clr ec ON ec.identifiant_couleur = cl.id_couleur
WHERE ec.identifiant_chaussure = 1

Si tu ne connais pas l'identifiant de la chaussure mais seulement son nom, tu fais une double jointure :

Code SQL :

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

1
2
3
4
5
SELECT cl.coul_libelle
FROM couleur cl
INNER JOIN exister_clr ec ON ec.identifiant_couleur = cl.id_couleur
	INNER JOIN Chaussure ch ON ch.id = ec.identifiant_chaussure
WHERE ch.nom = 'nom de la chaussure'

Par contre, comme tu sembles vouloir utiliser Access, je te recommande de créer les requêtes en mode graphique car Access à la fâcheuse manie de mettre une forêt de parenthèses dans les requêtes, notamment dans les jointures, et il n'est pas sûr qu'il accepte les requêtes normalisées comme je les ai écrites.

Pour la construction des requêtes, passe dans le forum adéquat correspondant à ton SGBD ou dans le forum Langage SQL si tu veux du SQL normatif en principe applicable sur tout bon SGBD.

Si tu en as fini avec la modélisation des données, n'oublie pas le bouton !

[razily]

justemet , j'utilise PhpMyAdmin comme gestionnaire de base donc MySQL

voici le diagramme final ; juste une petite question sur l'attribut : prix dans chaussure , comme le prix peut être sus forme de virgule (DECIMAL) , workbench refuse
et du coup j'ai mis varchar(45) je pense que cela ne change pas grand chose ???

Autre remarque quand je fais les associations Workbench me rajoute des lignes dans la table est ce normal !!
par exemple entre un lien : couleur et exister_clr

dans exister_clr il me rajoute une ligne couleur_id couleur
cela veut dire que je dois completer cette ligne ou il le fait automatiquement ??
bon il a mis par défaut autoincrement et not null

voici le diagramme avec les types :

non c'est bon ja'i dû changer le type de relation chez workbench !

merci

[CinePhil]

sur l'attribut : prix dans chaussure , comme le prix peut être sus forme de virgule (DECIMAL) , workbench refuse

Comment ça il refuse ?
Le type DECIMAL existe et convient très bien pour un prix, plus précisément un DECIMAL avec 2 chiffres après la virgule.

Les types NUMERIC et DECIMAL sont considérés comme identiques par MySQL, comme l'autorise le standard SQL92. Ils sont utilisées par des valeurs dont il est primordial de conserver la précision exacte, comme pour des données financières. Lorsque vous déclarez des colonnes avec l'un de ces types, vous pouvez indiquer la précision et l'échelle comme ceci :

salaire DECIMAL(5,2)

Dans cet exemple, 5 (précision) représente le nombre de décimales signifiantes qui seront stockées pour les valeurs, et 2 (échelle) représente le nombre de chiffres qui seront stockés après le point des décimales.

et du coup j'ai mis varchar(45) je pense que cela ne change pas grand chose ???

Non ! Utilise le type DECIMAL comme indiqué dans la doc MySQL.

Autre remarque quand je fais les associations Workbench me rajoute des lignes dans la table est ce normal !!

Oui car il ajoute automatiquement les clés étrangères alors qu'elles figuraient déjà dans ton schéma initial.
Pour une association (n-n) entre Chaussure et Couleur par exemple, tu ne dois pas créer toi-même la table associative mais tu dois utiliser le bouton "Place a New n:m Identifying Relationship" et tu tires l'association entre les deux tables Chaussure et Couleur. MySQL Workbench crée alors la table associative lui même avec les clés étrangères. Tu peux ensuite renommer la table associative et les colonnes si tu le souhaites.

D'une manière générale, Dessine un MCD, donc sans les clés étrangères puis quand tu passes sur Workbench, crée les tables issues des entités types, toujours sans clé étrangère et enfin crée les associations. Workbench créera les clés étrangères lui-même et tu pourras changer les noms qui ne te conviennent pas.

Cette méthode permet entre autres de vérifier si tu as bien tracé les associations dans le bon sens en regardant si la clé étrangère est créée dans la bonne table.

bon il a mis par défaut autoincrement et not null

Ça c'est bon pour les clés primaires issues des entités types du MCD mais inutile pour les tables associatives.

Vérifie bien toutes les associations créées par Workbench ; j'ai l'impression qu'il y a quelques détails à régler.

quand on débute, c'est un peu délicat de modéliser directement avec Workbench. Même moi il m'arrive de faire des erreurs dans les cardinalités affichées car je ne suis pas habitué à cette symbolique et je ne modélise pas en schéma E/R très souvent.

Bon courage pour la suite.

[razily]

Comment ça il refuse ?
Le type DECIMAL existe et convient très bien pour un prix, plus précisément un DECIMAL avec 2 chiffres après la virgule.


Non ! Utilise le type DECIMAL comme indiqué dans la doc MySQL.


Oui car il ajoute automatiquement les clés étrangères alors qu'elles figuraient déjà dans ton schéma initial.
Pour une association (n-n) entre Chaussure et Couleur par exemple, tu ne dois pas créer toi-même la table associative mais tu dois utiliser le bouton "Place a New n:m Identifying Relationship" et tu tires l'association entre les deux tables Chaussure et Couleur. MySQL Workbench crée alors la table associative lui même avec les clés étrangères. Tu peux ensuite renommer la table associative et les colonnes si tu le souhaites.

D'une manière générale, Dessine un MCD, donc sans les clés étrangères puis quand tu passes sur Workbench, crée les tables issues des entités types, toujours sans clé étrangère et enfin crée les associations. Workbench créera les clés étrangères lui-même et tu pourras changer les noms qui ne te conviennent pas.

Cette méthode permet entre autres de vérifier si tu as bien tracé les associations dans le bon sens en regardant si la clé étrangère est créée dans la bonne table.


Ça c'est bon pour les clés primaires issues des entités types du MCD mais inutile pour les tables associatives.

Vérifie bien toutes les associations créées par Workbench ; j'ai l'impression qu'il y a quelques détails à régler.

quand on débute, c'est un peu délicat de modéliser directement avec Workbench. Même moi il m'arrive de faire des erreurs dans les cardinalités affichées car je ne suis pas habitué à cette symbolique et je ne modélise pas en schéma E/R très souvent.

Bon courage pour la suite.

Merci , ce petit genre de cas m'a vraiment aidé et à comprendre pour la suite