Discussion :

[Babcool]

Bonjour

Je suis en train de préparer un projet dans lequel j'aurais besoin d'une base de donnée. Tout n'est pas encore complètement défini, je ne peux donc vous fournir le script de création des tables. Cependant, j'ai peur de me retrouver confornter à un problème par la suite, et je prèfère chercher une solution dès maintenant si elle implique une évoultion de l'architecture...

Donc, je veux réaliser une bases de connaissance contenant un ensemble de gène. Chaque gène appartient à au moins un génome. De plus il existe plusieurs types de gènes, pouvant cohabiter dans un même génome.

Je vais vouloir obtenir l'ensemble des gènes d'un génome. Cependant, chaque type de gène est stocké dans une table qui lui est propre. En effet, les données caractérisant un gène peuvent énormément différer d'un gène à l'autre.

La table liant les gènes aux génomes contiendra donc l'id du génome, le type du gène et l'id du gène. De plus, une autre table fournira le nom de la table correspondant à un type de gène.

Est il possible de sélectionner les tables correspondant aux gènes d'un génome sans générer manuellement une requête à l'aide des résultat d'une précédente? Dans ce cas, une première requete me fournirait le nom de toutes les tables nécessaires, puis je génèrerais la suivante en incluant l'ensemble de ces tables, cependant, j'aimerais éviter ce traitement intermédiaire.

Merci d'avance

[SQLpro]

En ce qui concerne les différentes tables de gènes il s'agit d'un cas classique d'héritage de données. Vous devez prévoir une table mère de toutes les tables fille de gènes, avec les informations communes s'il y en a. Voyez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/m...tion/heritage/

Les outils de modélisation comme Power AMC gère parfaitement ce genre de chose depuis le MCD jusqu'au MPD, y compris en générant les éventuels triggers d'exclusion mutuelle si l'héritage est exclusif !

A +

[CinePhil]

Babcool, tu parles déjà de tables alors que tu n'en es encore, semble t-il, qu'en phase de conception de l'architecture de la BDD. Tu mets la charrue avant les boeufs !

La démarche de conception est la suivante...
Commençons par une conception classique sans héritage...

il existe plusieurs types de gènes

Règle de gestion :
1) Un gène est d'un seul type et un type peut rassembler plusieurs gènes.

MCD 1 :
Gene -1,1----Typer----0,n- Type_gene

chaque type de gène est stocké dans une table qui lui est propre. En effet, les données caractérisant un gène peuvent énormément différer d'un gène à l'autre.

Je crois comprendre qu'en fait la fin de la phrase devrait être :
"les données caractérisant un gène peuvent énormément différer d'un type de gène à l'autre."

Règle de gestion :
2) Un type de gène est doté de plusieurs caractéristiques et une caractéristique peut concerner plusieurs types de gènes.

MCD 2 (qui complète le premier) :
Gene -1,1----Typer----0,n- Type_gene -1,n----Doter----0,n- Caracteristique

Chaque gène appartient à au moins un génome.

Règle de gestion :
3) Un gène peut appartenir à plusieurs génomes et un génome contient de un à plusieurs gènes.

MCD 3 (qui complète le 2) :
Genome -1,n----Composer----0,n- Gene -1,1----Typer----0,n- Type_gene -1,n----Doter----0,n- Caracteristique

S'il te faut maintenant donner une valeur à chaque caractéristique de chaque gène dans chaque génome, il te faut l'association ternaire suivante (MCD 4) :
Caracteristique -0,n----Valoriser----0,n- Gene
Genome -0,n--------------------|

Et là les difficultés commencent...
Pour que cette association soit cohérente avec le MCD 3, il faut (a) que le couple {Genome - Gene} de l'association Valoriser du MCD 4 existe dans l'association Composer du MCD 3 et il faut (b) que les caractéristiques valorisées pour le gène soient celles du type du gène.

Modifions une partie du MCD 3...
MCD 3bis :
Genome -1,n----Composer----(1,1)- Composition -(1,1)----Inclure----0,n- Gene

Les cardinalités entre parentèses signifient une identification de la composition relativement au génome et au gène. Les tables issues du MCD 3bis auront la même composition que celles du MCD 3 mais comme j'ai transformé dans le MCD une association en entité, je peux maintenant associer cette nouvelle entité aux caractéristiques.
MCD 5 (remplace le MCD 4) :
Composition -1,n----Valoriser----0,n- Caracteristique

La première contrainte (a) ci-dessus est maintenant satisfaite puisqu'il ne pourra pas exister de valorisation que pour les couples {génome, gène} existant dans une composition de génome.

La contrainte (b) est plus délicate car l'association entre le gène et la caractéristique passe par son type. Elle pourra se résoudre par un trigger en base de données mais pour le moment je ne vois pas de modélisation qui puisse simplement la satisfaire et comme ma compréhension de ton besoin est peut-être faux, je m'arrête là pour le moment.

[Babcool]

Bonjour,

Tout d'abord, merci bien pour ces 2 réponses

Après lecture du lien de SQLpro, je pense que le dernier paragraphe présentant la création d'une vue rassemblant les différentes informations pourrait me convenir plutot bien.

La proposition de CinePhil est aussi très intéressante. Elle permet une plasticité bien plus importante. Mais j'ai peur que l'utilisation se révèle un peu plus complexe. Surtout dans la mesure ou je n'ai pas besoin de tant de variabilité de la structure des gènes (en général, je tournerais que sur un ou deux type de gène a la fois).

J'ai cependant une question qui me taraude au niveau des caractéristiques. J'ai par exemple certaine caractéristiques sous forme arborescente (bon, j'envisageais de les stocker en xml dans un premier temps, car je ne sais pas si elles vont survivre a terme...), d'autres sous forme numériques, et des dernières sous formes textuelles (de taille fixe cette fois ).

Est il possible de gérer ces différents types de caractéristiques sans pour autant avoir une "multiplication" des entités . Il doit être possible de le faire que à travers l'association valoriser mais je n'ai pas l'impression d'être fan de cette idée

Cependant, je suis plus à l'aise avec la notion d'héritage, qui me semble mieux correspondre à mon besoin (et qui est aussi bien plus en adéquation avec mes structure de données dans le code...).

[CinePhil]

La proposition de CinePhil est aussi très intéressante. Elle permet une plasticité bien plus importante. Mais j'ai peur que l'utilisation se révèle un peu plus complexe. Surtout dans la mesure ou je n'ai pas besoin de tant de variabilité de la structure des gènes (en général, je tournerais que sur un ou deux type de gène à la fois).

Que veux-tu dire par "à la fois" ?

Le principe de l'héritage est de spécialiser une entité en plusieurs entités filles.
Un exemple de la vie courante en entreprise
Cadre -(1,1)----Etre----0,1- Salarie -(1,1)----Etre----0,1- Personne
Technicien -(1,1)----Etre----0,1-|
Contact -(1,1)----Etre-----------------------------------------0,1------|

Ce qui pourrait donner les tables suivantes :
Personne (prs_id, prs_nom, prs_prenom, prs_numtel...)
Salarie (slr_id_personne, slr_matricule, slr_salaire_mensuel_brut...)
Cadre (cdr_id_salarie, cdt_bonus...)
Technicien (tch_id_salarie, tch_id_atelier...)
Contact (ctc_id_personne, ctc_id_organisme...)

Dans ton cas, tu pourrais avoir des attributs communs à tous les gènes et des attributs particuliers à certains types de gènes :
Type_A -(1,1)----Etre----0,1- Gene
Type_B -(1,1)----Etre----0,1-----|

Tables :
Gene (gne_id, gne_attr_1, gne_attr_2...)
Type_A (tya_id_gene, tya_attr_special_A1...)
Type_B (tyb_id_gene, tyb_attr_special_B1...)

J'ai cependant une question qui me taraude au niveau des caractéristiques. J'ai par exemple certaine caractéristiques sous forme arborescente

Que veux-tu dire par "arborescente" ?

On peut faire de l'arborescence en BDD de deux façons :
S'il n'y a que deux niveau, c'est à dire un type de relation père/fils, chapitre/sous-chapitre... on peut se contenter de faire une auto association :
Caracteristique -0,1----Dependre----0,n- Caracteristique

Ce MCD entraîne en principe deux tables :
Caracteristique (crt_id, crt_nom...)
Dependance (dpe_id_caracteristique_fille, dpe_id_caracteristique_mere)

S'il y a plusieurs niveaux (des sous-sous-sous...-caractéristiques), alors il faut envisager la modélisation d'arbre par représentation intervallaire.

d'autres sous forme numériques, et des dernières sous formes textuelles (de taille fixe cette fois ).

Est il possible de gérer ces différents types de caractéristiques sans pour autant avoir une "multiplication" des entités . Il doit être possible de le faire que à travers l'association valoriser mais je n'ai pas l'impression d'être fan de cette idée

Là il faudrait nous donner des exemples pour qu'on puisse mieux comprendre la problématique.
Quand je parlais de valorisation des caractéristiques, c'était la valeur d'une caractéristique d'un gène dans un génome.

Je repars dans la vie courante :
Je commande une Laguna de couleur bleue à mon concessionnaire.
Vue du concessionnaire, donc de sa BDD, la caractéristique "couleur" de la voiture "Laguna" a la valeur "Bleu" pour la commande "2011-05" par exemple.

Il est vrai que certaines caractéristiques sont de type numérique et d'autre de type alphanumérique. Si tu as une table de valorisation des caractéristiques, les valeurs seront toutes de type VARCHAR et il faudra transtyper pour chercher les bonnes valeurs des caractéristiques numériques ou date ou timestamp...

(et qui est aussi bien plus en adéquation avec mes structure de données dans le code...).

Arf ! Encore un qui développe l'appli avant d'avoir modélisé les données ! Beurk !

[Babcool]

Pour les valorisation des caractéristiques, effectivement, il y a moyen de passer tout en chaine de caractères, m'enfin, je suis pas fan...

L'appli tourne déjà pour l'instant, avec un stockage des données en xml... Donc effectivement, j'ai une certaine contrainte sur la modélisation des données xD... Et je n'avais pas forcément prévu d'aller dans cette direction, c'est les joies de la recherche

A priori, je vais partir sur de l'héritage, le seul truc, c'est que mon entité mère ne contient aucune données. Mais ça n'a pas beaucoup d'influence sur le reste...

En tout cas merci bien pour tout ça, ça m'a permis de bien éclaircir la situation et d'avoir plusieurs idées de solutions alternatives si j'en ai besoin par la suite

Bab