Tables de référence

**reginato** · 04/05/2015, 23h42

Bonsoir,

je travaille actuellement sur la création d'une BDD sur les données d'essais nationales du pois protéagineux de printemps et d'hiver.

Mais voilà le volume de données est assez monstrueux pour un novice comme moi. J'utilise JMerise pour la construire et pour faciliter l'ajout ou la suppression de variables sans modifier la structure, j'ai décidé d'utiliser des tables de références.

Mais voilà par exemple pour la table de référence "T_R_Produits_Phytosanitaires_PPY" je me demandais si les attributs "PPY_Code_Produit" et "PPY_Code_Type" doivent apparaître également dans la table "T_Interventions_Phyto_PHY" dans la quelle on retrouve les attributs "PHY_Date" et "PHY_Dose".

Le but serait de créer 2 clés subrogées que j'aurai bien mis en FULLTEXT mais la version JMERISE que j'utilise ne le permet pas.

Pensez vous que c'est une bonne idée ? et comment remédier à l'absence du FULLTEXT ?

**CinePhil** · 05/05/2015, 08h59

les attributs "PPY_Code_Produit" et "PPY_Code_Type"

Dès que je lis "code", je comprends "donnée alpha-numérique ayant une signification et susceptible d'être modifiée". Dès lors, j'exclue d'en faire une clé primaire de table et, par voie de conséquence, une clé étrangère dans d'autres tables.

Quelle est la structure que vous envisagez pour ces tables de référence ? Montrez-nous au moins un morceau de schéma.

**reginato** · 05/05/2015, 09h40

Je joins en PJ une image du MCD.

Voilà dites moi si les tables de références vous semblent cohérentes.

Les codes des tables de références doivent servir à faciliter les requêtes dans les autres tables.

Merci pour le déplacement du message.

http://imageshack.com/a/img901/5938/0OF6WF.jpg

Nom : MCD_BDDAP_V3_TC.jpg
Affichages : 621
Taille : 649,1 Ko

Nom : MCD_BDDAP_V3_TC.jpg
Affichages : 621
Taille : 649,1 Ko

**CinePhil** · 05/05/2015, 10h48

1) Plutôt que le type Text, essayez de choisir les types de colonnes les plus adéquats.
Par exemple, un code postal en France est un CHAR(5).

2) J'ajouterais une entité-type de référence des départements que j'associerais à T_R_Site_Sit.
Cela éviterait la redondance des noms de départements et économiserait de la place.

3) Si le même expérimentateur peut être présent plusieurs fois dans T_essai_TST, externalisez-le.
T_experimentateur_EXP -0,n----experimenter----1,1- T_essai_TST

Idem pour organisme. Et si l'expérimentateur est lié à l'organisme, faites le schéma suivant :
T_organisme_ORG -0,n----appartenir----1,1- T_experimentateur_EXP -0,n----experimenter----1,1- T_essai_TST

4) Qu'est-ce que SOL_ID_SIT_TST dans T_R_Sol_SOL ?
Serait-ce une clé étrangère référençant le site et qui se serait glissée dans le MCD ?
Alors il faudrait une association entre T_R_site_SIT et T_R_Sol_SOL !

Idem pour T_R_Indicateur_Climat_CLM.

Vous avez le même phénomène dans d'autres entités-types (IRG_ID_TST, WSO_ID_TST...).

5) Association entre T_R_Sol_SOL et T_essai_TST
Si les cardinalités sont vraiment de (1,1 - 1,1), alors demandez-vous s'il ne faudrait pas fusionner les deux entités-types.

Idem pour l'association R_TST_CLM.

6) T_Semis_Stade_SEM
Ne faudrait-il pas externaliser SEM_Variete et SEM_Type_Variete ?

Pour répondre à votre question d'origine :

Mais voilà par exemple pour la table de référence "T_R_Produits_Phytosanitaires_PPY" je me demandais si les attributs "PPY_Code_Produit" et "PPY_Code_Type" doivent apparaître également dans la table "T_Interventions_Phyto_PHY" dans la quelle on retrouve les attributs "PHY_Date" et "PHY_Dose".

D'une manière générale, ce sont les clés étrangères faisant références aux tables de référence qui servent à retrouver les attributs signifiants provenant des tables de référence. On ne reprend donc pas ces attributs signifiants dans les tables liées.

Pour la petite histoire, j'ai travaillé à l'INRA sur la base de données nationale des bovins et j'ai modélisé une BDD pour une étude sur deux ans de mouvements de bovins. J'ai fait des jointures sur des tables allants jusqu'à plus de 60 millions de lignes sans problème de performance. La modélisation et l'indexation correcte des données a été rentable en terme de temps de préparation par rapport au gain de temps pour l'étude du thésard pour lequel je travaillais.

Bon courage.