Discussion :

[Chumbatta]

Bonjour,

Lors de la création d'une bdd d'articles de vêtement, on m'a spécifié que je devais créer 3 types de tables : unisexe, homme, femme, et, pour chacune d'elle, une table en fonction de la zone de couverture anatomique (jambes, torse, tête, ...), etc. Je n'ai pas compris pourquoi...

N'est-il donc pas possible et plus efficace de créer, dans SQL, une seule table regroupant tous les types d'articles et d'ajouter des colonnes de "gestion", comme par exemple : celle du sexe (si le vêtement est plutôt pour homme, femme ou les deux), celle de la tranche d'âge (enfant, ado, adulte, vieillard), celle de la saison (printemps, été, automne, hiver), celle de la zone de couverture anatomique (torses,jambes, tête, etc.), et ainsi de suite ? Bien entendu, les valeurs de chaque colonne seraient reliées, elles, à leur propre table, comme : une table de tranche d'âge où bébé signiferait de 0 à 2 ans, enfant de 3 à 11, ado de 12 à 17, etc. J'aurais donc dans la table vêtements, la colonne âge, et pour chaque article, seraient indiquées les tranches d'âge concernées (ou laissées vides si ça concerne toutes les tranches d'âges), idem pour le sexe et les autres attributs. De cette façon, je n'aurais qu'une table de vêtements et non pas plusieurs car actuellement j'ai des tables comme : torse_feminin_ete, jambes_masculin_printemps, ...

J'espère que mon dilemme est clairement expliqué, ne tenez pas trop compte toutefois de l'intitulé des tables, c'est juste pour me faire comprendre, il ne reflète en rien celui qui est utilisé dans la bdd.

[CinePhil]

Effectivement, dans les grandes lignes, ta modélisation me semble meilleure.

[Chumbatta]

Ok, ça me rassure un peu...

J'aurais une autre question : peut-on indiquer dans une colonne une "force" ou un "poids" à chaque donnée d'une table ? Si je souhaite, par exemple, attribuer et déterminer la probabilité de telle valeur à telle donnée, puis-je l'indiquer dans une colonne de la table ? Car, si c'est possible dans SQL, ça se passe comment : je fais une colonne et j'y indique un chiffre compris entre 0 et 1 pour chaque donnée de la table ou y a-t-il une autre façon de procéder ? Comment fait-on quand on veut donner un "poids" à chaque donnée s'il y en a des milliers ? J'imagine que ça ne se fait pas mais il doit bien y avoir des cas où ça se produit quand même, peut-être en groupant les valeurs par "poids" ?

[CinePhil]

Tu peux donner une valeur par défaut à une colonne mais tu ne peux pas lui dire "Il y a 80% de chances que tu accueilles la valeur 'truc'." La valeur par défaut sera celle enregistrée si la valeur n'est pas donnée explicitement par la requête d'insertion.

Ou alors je n'ai pas compris la question ?

[pfortin]

Salut,

Je ne suis pas sûr non plus d'avoir compris la question. Mais je tente une idée.

Si tu souhaites ordonner les réponses en fonction de leur pertinence/probabilité/etc, tu peux le faire via une requête du style

Code :

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

1
2
3
4
SELECT valeur 
FROM tSource 
GROUP BY valeur 
ORDER BY count(valeur) desc

Tu peux même créer un champ de tri dans la table de référence si tu veux gérer explicitement cet ordre.

J'espère ne pas avoir répondu à côté...

Cordialement,

Patrick

[Chumbatta]

Bonjour,

Mon propos manque peut-être de clarté mais je crois plutôt que je n'ai pas tout à fait bien saisi ta réponse pfortin.

En fait, je souhaiterais savoir comment dans SQL je pourrais indiquer le "poids" de chaque donnée d'une table. C'est-à-dire, pour reprendre l'exemple des vêtements : j'ai la table "vêtements" avec dedans des données telles que pantalon, chemise, jupe, chapeau, etc. Imaginons que je veuille générer un personnage masculin habillé dans une tenue d'hiver, je vais donc privilégier toutes les catégories d'habit de cette saison MAIS, dans ces catégories, je vais aussi privilégier la fréquence de certains vêtements en fonction de l'âge du personnage (je pourrais aussi avoir d'autres critères comme le type d'époque). Comment alors définir la probabilité que la génération d'un tel personnage (masculin - hiver - contemporain) entraînera plus fréquemment la création d'un "pull en laine" que s'il s'agissait d'un personnage féminin à la saison d'été vivant au XIX ème siècle ?

On peut apparemment, via la fonction random de php, indiquer la fréquence d'une donnée, compris entre 0 et 1 mais puis-je détailler ce "poids" pour chaque donnée avec php ? Ou bien faudrait-il que je crée, dans SQL, une colonne "force" ou "poids" dans la table "vêtements", et, en face de chaque donnée de la table, un chiffre entre 0 et 1 pour dire que tel habit a 50% d'être généré parce qu'il est lié à tels critères (âge, sexe, etc.) mais qu'il peut aussi avoir seulement 10% d'être généré si ces même critères (âge, sexe, etc.) sont différents ?

P.S : désolé, suis vraiment un newbie de chez newbie et je n'emploie peut-être pas les termes convenables. J'espère néanmoins avoir été un peu plus explicite.

[JPhi33]

Bonjour Chumbatta,

L'ajout d'une colonne "poids" dans chaque table est tout à fait possible.
Par contre, je suis très étonné par ce procédé car il va figer la probabilité accordée à chaque donnée.

j'ai la table "vêtements" avec dedans des données telles que pantalon, chemise, jupe, chapeau, etc. Imaginons que je veuille générer un personnage masculin habillé dans une tenue d'hiver, je vais donc privilégier toutes les catégories d'habit de cette saison

Concrétisons cet exemple. Je favorise les vêtements de type "masculin - hiver" :

Code :

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

1
2
3
4
5
6
7
vêtement poids
-------- -----
pantalon 0,4
chemise  0,2
jupe     0,1
chapeau  0,3

Maintenant, si on souhaite favoriser les vêtements d'un personnage de type féminin, on n'a pas d'autre solution que de modifier les poids dans la table. Ce n'est pas pratique du tout.
Ce procédé me semble donc mal adapté au besoin.



Pour la question concernant php et ses fonctions, ce n'est pas le bon forum.

[Chumbatta]

Merci pour cette réponse. Comment faire alors ? Je sais que je ne suis pas dans le forum php mais c'est justement parce que j'ignore s'il faut plutôt voir avec php ou SQL.
Je reprends l'exemple :

Code :

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

1
2
3
4
5
6
7
vêtement poids sexe          age
-------- ----- -----     ------------
pantalon 0,4 
chemise  0,2
jupe     0,1    F     
chapeau  0,3
cravate  0,5    M     JEU, ADU, MUR, VIE

Ce qui est laissé vide correspond à toute catégorie. Pour "age", j'indique (mais c'est pour l'exemple) que la donnée cravate ne sera affectée qu'à certaines catégories d'âge : jeune adulte, adulte, âge mûr, vieillard (ces catégories sont des données d'une autre table que j'appellerais "classe_age", donc des clés secondaires ?). La colonne "poids" (c'est-à-dire la probabilité que ça génère tel type d'article) est-elle alors réellement figée ? Car le choix du sexe, de l'âge, de la saison (ou plutôt une catégorie indiquant si le vêtement est chaud ou léger) devrait créer un "chemin", enfin c'est ce que j'aimerais arriver à faire...

Si j'ai mentionné php, c'est tout simplement parce que je ne sais pas trop justement si je dois créer cette colonne "poids" (probabilité) dans SQL ou si je ne m'en occupe pas, et ce sera alors avec php que je pourrais indiquer ce "poids" pour chaque donnée (ce qui sera sans doute concrétisé par une fonction avec pleins de If).

[CinePhil]

Vu la multiplicité des cas possibles, je pense qu'il vaut mieux faire une (voire plusieurs) table(s) associative(s) indiquant la probabilité de l'association entre un article et la valeur d'un critère.

Par exemple, si on associe le vêtement au sexe, la probabilité d'une jupe sera peut-être de 90% pour une femme et de 0,0001% pour un homme (Jean-Paul Gaultier ).

Donc un schéma du style :
Vetement -0,n----intéresser----0,n- Sexe

Tables :
Vetement (v_id, v_nom...)
Sexe (s_id, s_libelle)
Vetement_interresser_sexe (vis_id_vetement, vis_id_sexe, vis_probabilite)

[JPhi33]

Bonjour,

Comment faire alors ?

Pour "age", j'indique [...] que la donnée [...] ne sera affectée qu'à certaines catégories d'âge : jeune adulte, adulte, âge mûr, vieillard (ces catégories sont des données d'une autre table que j'appellerais "classe_age", donc des clés secondaires ?).

La colonne "poids" [...] est-elle alors réellement figée ?

Car le choix du sexe, de l'âge, de la saison [...] devrait créer un "chemin", enfin c'est ce que j'aimerais arriver à faire...

Vu la multiplicité des questions, le plus simple est de conceptualiser tout ça et de le formaliser dans un MCD. Créer des tables sans organiser sa pensée n'aboutit que dans des cas rares. Au préalable, il faut poser les règles sous forme de phrases construites desquelles émergeront ces concepts.

[Chumbatta]

Cinephil, oui, c'est plutôt dans ce sens que je voyais la constructions des tables. Toutefois, d'après ce que j'ai pu lire sur Merise, il me semblait qu'établir des tables avec deux ou trois données, comme celle pour le sexe (masculin, féminin, unisexe), n'était pas une bonne méthode car une bonne conception de bdd évite justement la création de table contenant très peu de données. A moins que, pour les tables associatives, ça n'ait pas beaucoup d'importance ?

Jphi, j'ai bien essayé de concevoir un MCD, j'ai consulté plusieurs documents de méthode pour les réaliser mais le schéma qui se profilait dans mon ébauche me donnait plus de mal qu'en réalisant les tables directement : en fait, c'est plutôt assez clair dans ma tête, ça l'est beaucoup moins dans la réalisation technique, c'est-à-dire pour le transformer en MLD puis en MPD (c'est bien ainsi qu'on nomme les modèles logiques et physiques ?). En particulier, on m'a demandé d'éviter, par exemple, de mettre plusieurs valeurs dans une colonne, comme pour la colonne age sus-citée, parce que ça ne simplifierait pas les requêtes SQL. Par ailleurs, dans mon MDC, j'avais un peu de mal à trouver les termes pour les associations entre les différentes entités. Pour reprendre l'exemple de CinePhil :

Code :

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

Vetement -0,n----intéresser----0,n- Sexe

Ok, je n'avais pas pensé à ce terme "intéresser" qui, quelque part, se répèterait pour âge, aussi, non ? Donc on aurait quelque chose comme :

Vetement -0,n----intéresser----0,n- Sexe

intéresser----0,n- Age

intéresser----1,n- Epoque

intéresser----1,n- Qualité (chaud, léger)

ou saison (mais moins facile à gérer puisque je peux porter des vêtements chauds en été si ça caille d'un coup).

Or, est-ce que ça c'est correct dans un MCD ? Les cardinalités sont différentes (sauf erreur de ma part), et si elles le sont, cela signifie donc que c'est juste une modification du terme de l'association à changer. Mais cette modification, pour moi, correspond alors juste à créer un synonyme (au lieu d'"intéresser", je mettrais donc "appartenir" ou "correspondre"). Quel est, dans ce cas, le degré d'incidence d'un changement sémantique dans les associations ?

P.S : j'aurais bien voulu accéder à une copie de bdd de vêtements afin de voir comment elle était organisée mais ça semble impossible (alors qu'il existe des bdd de lexique accessible gratuitement, par exemple)

[CinePhil]

Toutefois, d'après ce que j'ai pu lire sur Merise, il me semblait qu'établir des tables avec deux ou trois données, comme celle pour le sexe (masculin, féminin, unisexe), n'était pas une bonne méthode car une bonne conception de bdd évite justement la création de table contenant très peu de données. A moins que, pour les tables associatives, ça n'ait pas beaucoup d'importance ?

Avec certains SGBD et dans certains cas, et le sexe est un bon exemple, on peut utiliser un TYPE appelé chez MySQL "ENUM" à la place d'une table de référence ne comprenant que peu de valeurs. Je ne sais pas si ce type est un standard SQL.

en fait, c'est plutôt assez clair dans ma tête, ça l'est beaucoup moins dans la réalisation technique,

Tu devrais relire ma signature ; je ne suis pas sûr que ce soit si clair dans ta tête !

c'est-à-dire pour le transformer en MLD puis en MPD (c'est bien ainsi qu'on nomme les modèles logiques et physiques ?).

Si le MCD est bien fait avec un logiciel de modélisation, le MLD se génère tout seul.

En particulier, on m'a demandé d'éviter, par exemple, de mettre plusieurs valeurs dans une colonne, comme pour la colonne age sus-citée, parce que ça ne simplifierait pas les requêtes SQL.

Ça c'est vrai, c'est un principe de base des BDD relationnelles.

Donc on aurait quelque chose comme :

Vetement -0,n----intéresser----0,n- Sexe

intéresser----0,n- Age

intéresser----1,n- Epoque

intéresser----1,n- Qualité (chaud, léger)

ou saison (mais moins facile à gérer puisque je peux porter des vêtements chauds en été si ça caille d'un coup).
Or, est-ce que ça c'est correct dans un MCD ?

Oui il peut y avoir le même verbe pour plusieurs associations. Ça gène certains puristes, ça ne me choque pas. Mais dans la mesure du possible il faut éviter.

Les cardinalités sont différentes (sauf erreur de ma part), et si elles le sont, cela signifie donc que c'est juste une modification du terme de l'association à changer.

Le fait que les cardinalités soient différentes n'a rien à voir avec le verbe décrivant l'association.

Mais cette modification, pour moi, correspond alors juste à créer un synonyme (au lieu d'"intéresser", je mettrais donc "appartenir" ou "correspondre"). Quel est, dans ce cas, le degré d'incidence d'un changement sémantique dans les associations ?

Si le MCD est fait avec un logiciel de modélisation qui génère automatiquement le MLD, avec des cardinalités maximales à n des deux côtés de l'association (ou le couple {0,1 - 0,n}), l'association engendrera une table associative qui portera selon le réglage du logiciel, le nom de l'association. Il pourrait donc y avoir plusieurs tables portant le même nom si plusieurs associations portent le même nom, ce qui n'est évidemment pas possible.

[Chumbatta]

Avec certains SGBD et dans certains cas, et le sexe est un bon exemple, on peut utiliser un TYPE appelé chez MySQL "ENUM" à la place d'une table de référence ne comprenant que peu de valeurs. Je ne sais pas si ce type est un standard SQL.

Très bien, je vais regarder de plus près ce ENUM...

Oui il peut y avoir le même verbe pour plusieurs associations. Ça gène certains puristes, ça ne me choque pas. Mais dans la mesure du possible il faut éviter.

Si le MCD est fait avec un logiciel de modélisation qui génère automatiquement le MLD, avec des cardinalités maximales à n des deux côtés de l'association (ou le couple {0,1 - 0,n}), l'association engendrera une table associative qui portera selon le réglage du logiciel, le nom de l'association. Il pourrait donc y avoir plusieurs tables portant le même nom si plusieurs associations portent le même nom, ce qui n'est évidemment pas possible.

Ce n'est donc pas qu'il faille éviter le même verbe pour plusieurs associations, il faut absolument que le nom des associations soit différent, quitte à choisir des synonymes, c'est bien ça ?

Citation:
En particulier, on m'a demandé d'éviter, par exemple, de mettre plusieurs valeurs dans une colonne, comme pour la colonne age sus-citée, parce que ça ne simplifierait pas les requêtes SQL.
Ça c'est vrai, c'est un principe de base des BDD relationnelles.

Voici un exemple de colonne dans laquelle sont insérées plusieurs valeurs (tirée de la bdd Lexique qu'on trouve sur http://www.lexique.org/) :

Code :

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

1
2
3
1_ortho         29_cgramortho
-----           -------------
abattu          VER,ADJ,NOM

J'ai bien ici plusieurs valeurs dans la colonne 29, donc je reste perplexe... A moins que cela ne concerne que les valeurs numériques ? Parce que c'est ce que je souhaiterais faire pour une colonne "âge" ou "époque", par exemple :

Code :

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

1
2
3
4
1_vet         2_age
-----          -------------
mini-jupe      ADO, JEU, ADU
fourreau       JEU, ADU, MUR

Par ailleurs, la bdd Lexique ne comporte qu'une seule table, et pourtant, si vous avez l'occasion d'y jeter un oeil, les requêtes sont multiples.

[CinePhil]

Ce n'est donc pas qu'il faille éviter le même verbe pour plusieurs associations, il faut absolument que le nom des associations soit différent, quitte à choisir des synonymes, c'est bien ça ?

C'est mieux en effet mais ce n'est parfois pas facile, voire impossible sans artifice (associer1, associer2...) et parfois inutile (quand l'association n'engendrera pas de table associative).

Voici un exemple de colonne dans laquelle sont insérées plusieurs valeurs (tirée de la bdd Lexique qu'on trouve sur http://www.lexique.org/) :

Code :

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

1
2
3
1_ortho         29_cgramortho
-----           -------------
abattu          VER,ADJ,NOM

J'ai bien ici plusieurs valeurs dans la colonne 29, donc je reste perplexe...

D'où tires-tu cette structure ? Ton lien aboutit à la page générale du lexique.
Ce n'est pas parce que les données sont présentées de cette manière qu'elles sont enregistrées de telle façon.

A moins que cela ne concerne que les valeurs numériques ?

Autant valable pour les colonnes numériques qu'alpha-numériques.

Par ailleurs, la bdd Lexique ne comporte qu'une seule table, et pourtant, si vous avez l'occasion d'y jeter un oeil, les requêtes sont multiples.

Si c'est vrai, ce n'est pas une BDD mais une table, comme une feuille de tableur. Ne pas confondre !
Vouloir utiliser un SGBDR pour enregistrer les données dans une seule table, c'est prendre un marteau-pilon à commande numérique pour écraser un moustique !

[Chumbatta]

Ahhhh, mille excuses, ce n'est pas effectivement tirée de l'exportation de la bdd, il s'agit de la table existante dans le tableur que vous pouvez télécharger ici. Sur le site, il y a toutefois une interrogation possible en ligne de cette bdd.

Mais, dans ce cas, si cette table qui figure dans le tableur sert à créer la bdd, comment est-elle enregistrée dans SQL, une importation ne suffirait-elle pas ? Comment peut-on exploiter ce fichier tableur pour en faire une bdd ? Ou bien alors, il ne s'agit pas d'une bdd ?

(se cache déjà...)

[CinePhil]

J'ose espérer que les données ne sont pas réellement enregistrées de cette manière ; c'est une horreur au sens des bases de données relationnelles !

Ça ressemble plus aux vieux fichiers séquentiels de la préhistoire ante-SQL.

Je te déconseille fortement de vouloir faire le même genre de truc tout seul dans ton coin. C'est très casse gueule.

Fait un bon modèle conceptuel de données ou un bon diagramme de classes, ce sera beaucoup plus facilement exploitable.

[Chumbatta]

Soit, vais me replonger dans le MCD alors...

Merci encore pour tous vos conseils.

P.S : c'est dommage, je n'ai pas trouvé d'exemple de mise en pratique de A à Z des différentes phases de création d'une bdd (depuis la constitution du dictionnaire jusqu'à son exploitation avec php, par exemple).

[CinePhil]

Tu peux lire en ligne le livre de Michel Diviné, "Parlez-vous Merise ?"

[Nohant]

merci pour le lien CinePhil je vais voir si je trouve des pistes à mon problème

[JPhi33]

Bonjour,

ce que je souhaiterais faire pour une colonne "âge" ou "époque" :

Code :

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

1
2
3
4
5
1_vet         2_age
-----          -------------
mini-jupe      ADO, JEU, ADU
fourreau       JEU, ADU, MUR

La modélisation correspondant à cet exemple est :

[ 1_vet ]--0,n----( 2_age )----0,n--[ age ]

L'entité "age" contient ADO, JEU, ADU, MUR.
2_age est donc une association. La table du MLD qui en est issue contiendra :

Code :

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

1
2
3
4
5
6
7
8
9
vet       age
--------- ---
mini-jupe ADO
mini-jupe JEU
mini-jupe ADU
fourreau  JEU
fourreau  ADU
fourreau  MUR

Ceci est pour l'exemple. En réalité, ce sont les clés de "1_vet" et de "age" que l'on a dans la table "2_age". A partir de cette table, on peut reconstituer la présentation des données du début.