Discussion :

[Mos]

Salut à tous !

Voila je remanie une BDD pour "élargir son champ d'action" :

Je patauge pour trouver la meilleure solution permettant une évolutivité dans l'avenir (et ne pas me retrouver dans la situation actuelle...)
Actuellement j'ai 1 table :

• T_cultivar : {ID_CULTIVAR, DESIGNATION_CULTIVAR, DATE_OBTENTION, FK_TAXON, CARACTERE1, CARACTERE2....} pour décrire une variété

(CARACTEREx décrit une caractéristiques de la variété pour l'espèce en question, ce qui permet de l'identifier)

Il me faut aujourd'hui élargir cette BDD pour intégrer d'autres espèces... Mais les critères d'identification ne sont pas les mêmes (exemple : 1 forme pour une pomme, 1 teneur en sucre pour une betterave sucrière)

J'avais pensé faire des tables séparées, en considérant que l'espèce "pomme" était une entité, et l'espèce "blé" une autre.

Mon problème : En dehors de ces critères d'identification, tous les autres caractéristiques sont communes : designation, date d'obtention, ref taxonomie, fournisseur, pays d'obtention etc...). Faire x tables pour chaque espèce mutilplie ces champs... et oblige à créer des requêtes distinctes pour chaque table.
Serait-il possible de concevoir un modèle :
J'avais pensé séparé les champs communs du reste

• 1 table pour T_cultivar : {ID_CULTIVAR, DESIGNATION_CULTIVAR, DATE_OBTENTION, FK_TAXON, ....}
• 1 autre table pour les caractères propres à chaque espèce

mais cela ne résoud en rien ma multiplicité de table, et m'oblige à créer de nouvelles tables à chaque ajout de nouvelle espèce.

Y aurait-il un moyen d'abstraction de cette 2ème partie qui permettrait d'avoir une (des) tables communes, utilisables quelle que soient les espèces ?

Je pense que cela reviendrait à avoir une table qui définisse le contenu d'un champ et une autre qui contienne toutes les valeurs de champs :
- T-DEF_CARACTERES : ID_CARACTERE, ESPECE, CARACTERE, DEF_CARACTERE
- T-VAL_CARACTERES : ID_VAL_CARACTERE, FK_ID_CARACTERE, VALEUR

Il me semble que ce schéma n'est pas complet, ne faudrait-il pas un FK_ID_CULTIVAR dans T-VAL_CARACTERES ?

Qu'en pensez-vous ?

Mos

[hed62]

J'avais pensé faire des tables séparées

Oui

en considérant que l'espèce "pomme" était une entité, et l'espèce "blé" une autre.

Non ! Je m'explique plus loin

Faire x tables pour chaque espèce mutilplie ces champs

Effectivement, cherche dans ce forum les notions d'héritage, tu devrais trouver de plus amples détails.

Pour ton soucis de variétés, il me semble que tu raisonne en termes d' "instances" (pour voler le mot à UML) plutôt qu'en termes de concepts.

Or, lors de la conception d'une base de données, tu dois avant tout réfléchir en terme de concept : tu bâti un MCD , modèle conceptuel de données.

Donc, exit les blé, betterave, etc... et welcome les variété, espèces, plante (par exemple). pour expliciter ma phrase sur les "instances", blé et betterave seront des instances de plante.

Que te reste-il ? Eh bien, des plantes, et des caractéristiques particulières. Comment relier les deux ? En disant :

une plante est identifiée par une ou plusieurs caractéristiques.

gras : les cardinalités
souligné : les entités
italique : la relation

L'entité plante regroupe les choses communes à toutes les plantes : nom, pays, id, designation...

L'entité caractéristique peut sembler simple de prime abord :
un champs = une caractéristique possible.

Mais, comme tu le dis toi même, une caractéristique peut être une teneur en sucre. Je n'imagine même pas une table avec toutes les valeurs possibles des teneurs en sucre ! Car cela dépend de la plante également.

Tu en arrives donc à la conclusion : c'est au travers de la relation entre plante et caractéristique que tu va spécifier certaines informations, plus précisément une valeur. La relation devient porteuse :


Plante -1,n------identifié par (valeur : double) ------0,n- Caractéristique


Cela, en admettant que ce soit ce que tu désires exprimer, deviendra le MLD suivant (modèle logique de données, qui se rapproche de la base de données) :

Plante { id, design ...}
Caractéristique { id, design, ...}
Identifie { id_plante, id_carac, valeur}

Ceci permet de stocker du blé, du maïs, des betteraves.... Et beaucoup d'autres choses encore.

Si tu as des questions N'hésites pas à aller voir la FAQ Merise !

[Mos]

Merci pourc e coup de pouce !

Tu en arrives donc à la conclusion : c'est au travers de la relation entre plante et caractéristique que tu va spécifier certaines informations, plus précisément une valeur. La relation devient porteuse :


Plante -1,n------identifié par (valeur : double) ------0,n- Caractéristique

Effectivement c'est par là que je sentais la chose... mais impossible de formaliser, malgré la FAQ MERISE que j'aid ejà lu plusieurs fois...

J'ai toujours du mal quand il s'agit d'avoir des identifiants doubles, triples...

Cela, en admettant que ce soit ce que tu désires exprimer, deviendra le MLD suivant (modèle logique de données, qui se rapproche de la base de données) :
Plante { id, design ...}
Caractéristique { id, design, ...}
Identifie { id_plante, id_carac, valeur}

C'était bien ça !

Merci encore !

Mos

[Mos]

Bien j'ai progressé sur mon MCD, et les points évoqués ci-dessus m'ont bien aidé...

Toutefois il reste un point non satisfait (que j'avais peut-être oublié d'omettre).

Si on a :
Plante -1,n------identifié par (valeur : double) ------0,n- Caractéristique,
on peut entrer toute valeur pour identifier un cultivar.

Cependant dans un but d'identification, il faudrait que pour un type de cultivar (ex : groseille, pommier...) on ait certains caractères obligatoirement.
ex :

• pour les groseilles : couleur de la baie, morphologie de la grappe
• pour les pommiers : forme du fruit, longueur du pédoncule

Y-a-t il moyen par les règles de l'intégrité référentielle d'avoir à la fois la souplesse de critères nouveaux ET certains critères pour un type de cultivars.
(certains caractères sont indispensables pour pouvoir procéder à une identification, d'autres non)

[hed62]

Ajouter une seconde relation entre plante et caractéristique, non porteuse, signifiant quelles caractéristiques sont obligatoires .

[Mos]

Je m'interroge si l'on s'est bien compris, car je ne vois pas en quoi une relation supplémentaire entre les entités caractéristique et plante peut rendre obligatoire certaines "instances" de caractéristique.

Je reprends la définition du problème :
1 cultivar (=variété, ex : Pink Lady) appartient à un groupe de plante (ex : pommier) qui possède des caractéristiques propres à ce groupe de plante.

Pour moi on se retrouve avec 3 entités (voir MCD joint) : variété, plante, et caractéristique.
Mais ce schéma ne me parait pas correct : si on prend une exemple concret : on peut très bien pour une pomme de variété Pink Lady avoir une caractéristique qui n'a rien a voir avec le groupe pomme...

[hed62]

Pourquoi ne pas mettre le champ obligatoire, de type booleen sur la relation "identifie". A vrai, la caractéristique est obligatoire, à faux elle ne l'est pas?

[Mos]

Après réflexion, il vaudrait mieux travailler sur une liste de caractères autorisés par type de plante (identifiants) qui caractériseront une variété. D'où le nouveau schéma joint et une nouvelle entité.


Est-ce une bonne interprétation ?