[MySQL] aide pour le designe d'une base

Logiciel & apps Programmation
1

Salut

Voila ce que j’ai fait pour le moment, mais je suis sur qu c’est pas encore l’ideal.

Pour situer le contexte : des gens qui font des simulations sur des molecules, et des calculs, etc… : les données en elles-memes sont des especes de “snapshot” pris au cours de l’evolution d’une phénomene (i.e. des coordonnées pour simplifier)(1 Frame = 1 snapshot=

http://www.ibpc.fr/Perso/Nicolas.Guiot/img…Complex_V3b.png

(Pour info, j’ai fait ce schema avec DbDesigner4, si vous connaissez mieux pour linux, pquoi pas…)

Au final, les données importantes sont stockées dans les 3 tableaux du bas; la table molecule permettra de stocker le nom de la molecule etudiée + commentaires, et les tableaux en haut a droite sont des paramètres (qui compliquent la tache…)

Mon problème est le suivant :
Dans la table "PhaseGas" on aura pour chaque couple de (idMolecule,idTraj) env. 10 000 Frames, et pour chaque Frame, un ensemble de "Frame, Ele,Vdw,Bad" (i.e. les fameuses coordonnées)
Dans la table "PB", on aura pour chaque triplet (idMolecule,idTraj,idPrmtop) environ 10 000 Frames (et pour chaque frame un ensemble de PbSur,PbCal)
Dans la table "GB", on aura pour chaque quadruplet (idMolecule,idTraj,idPrmtop,idIgb) environ 10 000 Frames (et pour chaque frame, un ensemble GbSur, GB)

DONC, si je me souviens bien de mes restes de cours en SGBD, il faudrait que je fasse de nouvelles tables, pour ne pas avoir a stocker les memes informations plusieurs fois, genre :
-AssemblageGas : idAssGas(prim), idMolecule, idTraj ; on remplace dans la table PhaseGas ces 2 dernieres clés par "idAssGas"
-AssemblagePB : idAssPB(prim), idMolecule, idTraj, idPrmtop ; on remplace dans la table PB ces 3 dernieres clés par "idAssPB"
-AssemblageGB : idAssGB(prim), idMolecule, idTraj, idPrmtop, idIgb ; on remplace dans la table GB ces 4 dernieres clés par "idAssGB"

? Bien ou pas ??

OU BIEN (?) :
-AssemblageGas : idAssGas(prim), idMolecule, idTraj ; on remplace dans la table PhaseGas ces 2 dernieres clés par "idAssGas" (idem solution précédente)
-AssemblagePB : idAssPB (prim), idAssGaz, idPrmtop
-AssemblageGB : idAssGB(prim), idAssPB, idIgb

Je suis dispo si vous avez besoin de details, ou de meilleures explications sur la base

Merci d’avance

2

Pas évident à dire comme ça. Pour de la modélisation, je ne sais pas quel modèle tu utilises.

Par exemple en Merise (une vraie méthode ça peut aider mine de rien) on formalise une entité du monde réel en une entité BDD.
D’autre part, on ne stocke que des données atomiques (càd irréductible dans le contexte de l’étude).
On stocke également les relations. Une relation devient une table la plupart du temps sauf cas de dépendance fonctionnelle.

Je suis mauvais en chimie mais admettons :
Une molécule est composée d’atomes.

On modélise une entité molecule et une entité atome. On les relie par une relation composer.
On ajoute les cardinalités. entre molecule et la relation : 1, n car une molécule est composée d’au moins 1 atome et peut-être composée de plusieurs. Entre atome et la relation : 0, n car un atome peut ne pas entrer dans la composition d’une molécule connue du système, mais peut entrer dans plusieurs.
Il n’y a donc pas de doublons.

Ensuite on ne stocke pas les données calculées. Dans la mesure où elles sont calculées, on peut les retrouver à l’aide de procédures stockées, cela permet de gagner de la place dans la base, et l’info est vite retournée.

Tout ça pour dire que si tu pouvais représenter en langage relationnel ce serait plus simple à étudier.

Sinon si tu fais des nouvelles tables, tu auras de toute façons les infos stockées car il faudra une table issue d’une relation entre assemblagegas et phasegas pour lier les deux tables.

Si ton appli te permet de générer un modèle relationnel regarde les différences entre la base telle qu’elle est actuellement et la nouvelle idée que tu en as.

3

moi ça me fai penser a une base de donnée orienté stat…

mais intuitivement c tres bien ce que t as fais !

tu as trois tables de ‘faits’ (cad de données) autours des quel gravite des table de references ou dimensions c ce qu’on appel un starschema

c une structure qui est optimisé pour l’extraction de stat a partir d’un grand nombre d’enregistrement

par contre contrairement a un model plus relationnel (style merise avec des entite en cascade) il n’est pas optimisé pour decrire des structures (en effet pour connaitre toutes les trajectoires d’un molecule on doit obligatoirement passé par la table de fait qui est tres grosse donc ça a un certain cout)

entre les deux il y a ce qu on nomme flake schema (schema en flocon)

on modelise les structures tout en gardant une (ou des) table de fait

donc dans la table trajectoire faudrait rajouter l’identifiant de la molecule concernée comme ça si on veux connaitre toutes les trajectoires d’une molecule pas besoin de taper dans la table de fait (ou l’info est par nature dupliquée : etat de la trajectoire a plusieur instant…)

etc pour les autre table

4

A vrai dire, je suis pas sur d’avoir bien compris ce que vous avez voulu m’expliquer…
Et puis je ne suis pas sur que ton exemple de “molecule” s’applique a mon cas réel (je me doutais que si j’essayais de detailler, ca allait vous embrouiller…)

Bref, si on veut simplifier la chose, Trajectoire, prmtop et igb sont des nouvelles “dimensions”, c’est pourquoi je pensais que, vu qu’elles se repetaient pour de nombreux enregistrement, il etait judicieux de les regrouper dans une table à part (la je rejoins ton idée de données atomiques…)

Ensuite, pour les relations entre les tables (les seuls schemas dont je me rappelle etaient faits sous Access pour ma part), j’aurais pu faire des lignes (genre 1:n, n:n, etc…) mais j’ai pensé qu’avec les identifiants, c’etait + simple a “lire” sur mon schema. Si vous preferez, pour mieux comprendre, je peux vous faire ce que je crois etre les relations…

5

en fait j’ai interprété ce que j’ai compris du post d 'oxyfrance…

en fait tu ne cherche pas du tout a decrire la structure de la molecule juste a stocké des etats successifs …

dans ce cas ton modele est tres suffisant

ps : ne pas repeter des données n’est pas forcement une bonne solution quand on cherche a optimiser sur la vitesse …

ex : un cube de données avec des donnees pre aggregés etc

pour toi peut etre des données cumulées pour 10 frames , 100 frames 1 minutes etc …

6

Bon, disons que je decide de garder ce design-la (cf lien + haut), ne serait-il quand meme pas plus judicieux par exemple pour la table GB, au lieu de créer un ID, de faire une clé composée des 4 champs rouges ? idem pour PB et PhaseGaz avec les champs rouges ??

7

la question est comment va tu acceder a la table ?

dans tous les cas tu peux garder une cle unique ‘simple’ pour la table (c plus simple pour faire des update etc …)

maintenant si tu accedes systematiquement en faisant un where de idtruc = …
and idmachin = … faut faire un index sur idtruc idmachin

ps :
un index sur idtruc, idmachin optimise les acces sur idtruc et idmachin mais aussi sur idtruc seul ( par contre pas sur idmachin seul : un index composé c une bete concatenation avec un B tree deriere)

donc : une cle composé oui mais evite de creer une regle d’unicité sur une grosse table c tres gourmant a l’insertion juste un (ou plusieur) index pour optimiser les acces

8

bon, au final, j’opte pour la solution “initiale”, je pense que ca risque de me poser moins de problèmes pour la suite (enfin j’espere…)

Merci de votre aide