Discussion :

[sylvain77]

Bonjour a tous

Je suis actuellement en train de travailler sur un projet concernant des donnees de peches et ai quelque difficultés pour conceptualiser la structure de ma base de données.
Mes poissons peuvent provenir de differentes techniques utilisees a bord de mêmes bateaux.

J'ai donc une table listant les bateaux, puis une table pour chaque technique (technique1. technique2) et enfin une table listant les poissons.
Un meme bateau peut utiliser différentes techniques pour attraper des poissons.
Chaque technique est complétement différente en termes de propriétés (localisation, duree...) d'ou la mise en place de deux tables distinctes: technique1. technique2 ou sont listes quand chaque technique a eu lieu, a quelle endroit.

Le probleme que j'ai, c'est au niveau de la relation entre toutes ces tables.
1 - Dois-je avoir dans ma table poisson un champ "technique1_ID" et "technique2_ID" qui me permet de pointer sur la table correspondante. Je me retrouve dans ce cas avec des champs vide quand l'autre est utilise ce qui me deplait (si technique1_id est fourni, technique2_ID sera vide)
2 - Dois je avoir un champ "technique_id" ou je fourni l'ID de la technique utilise et un autre "technique_type" ou j'indique si c'est la technique 1 ou 2. Dans ce cas, plus de valeurs nulle mais je suis alors incapable de mettre en place des relations entre ma table poisson et mes tables techniques.
3 - Je crée une table intermédiaire "technique_all" qui contient les champs "bateau_id", "technique1_id", "technique2_id" ce qui me permet de ne pas modifier ma table poisson qui pointe sur un enregistrement dans technique_all mais dans ce cas encore, cette table va contenir des valeurs nulles lorsque l'une ou l'autre des techniques sera spécifiée...

Bref, je ne trouve pas de solution qui me plaise, est-ce que je passe a cote d'une 4eme??

Merci de me donner votre avis

Sylvain

[Simplifi]

Hello
il me semble important de fusionner les deux tables même si ceratins champs doivent être vides
des champs vides dans une table ne sont pas un problème, car pour éviter les zones de texte vides, on peut à l'affichage du formulaire, masquer les zdt en fonction du type d'affichage.
Sinon, il m'arrive de procéder autrement, notament quand je n'ai aucun moyen de connaître à l'avance le nombre de colonnes nécessaires à la description d'un produit, d'une technique....
dans ma table j'ai:
- le Numéro d'objet
- le nom de la caractéristique
- la valeur numérique de cette caractéristique
- la valeur texte de cette caractéristique
- éventuellement un N°d'ordre
par exemple
1,"famille", ,"production",0
1,"nom", ,"machine1",1
1,"puissance",25,"Kw",2
1,"longueur",1,"m",3
etc
ce qui permet d'avoir une liste éventuellement 'infinie' de caractéristiques.
par contre, les requêtes sont focément à double détente

Code :

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

SELECT * FROM table WHERE N°obj IN (select N°obj FROM table WHERE nom_caractéristique = "famille" AND val_texte_caractéristique = "production";);

ensuite, un simple formulaire mode tabulaire permet d'avoir la même présentation qu'un mode fiche simple (en prennant soin de présenter la zdt du nom de la caractéristique comme une étiquette

[Tofalu]

Hello
il me semble important de fusionner les deux tables même si ceratins champs doivent être vides
des champs vides dans une table ne sont pas un problème, car pour éviter les zones de texte vides, on peut à l'affichage du formulaire, masquer les zdt en fonction du type d'affichage.

Pas vraiment, non ... entre spécialisation et généralisation, on ne choisit pas en fonction des possibilités d'un formulaire, sinon on met tous dans excel : aprés tout, il y a assez de cellules pour admettre un tas de vides.

Dans la mesure où l'on souhaite garder deux tables distinctes, la solution préférable serait, à mon avis :

1 - Dois-je avoir dans ma table poisson un champ "technique1_ID" et "technique2_ID" qui me permet de pointer sur la table correspondante. Je me retrouve dans ce cas avec des champs vide quand l'autre est utilise ce qui me deplait (si technique1_id est fourni, technique2_ID sera vide)

Celle-ci permet de mettre en place l'intégrité référentielle. Entre des NULL et l'intégrité des données, il me parait essentiel de choisir la solution la plus sécurisante.

Une autre solution serait d'avoir une table généralisée Techniquemere :

TechniqueMere(IdTechniqueMere, leschamps communs à toutes les filles s'il y en a)

Les tables techniques filles (spécialisées) :

Technique_1(IdTechnique1, champ1, champ2, idTechniqueMere#)
Technique_2(IdTechnique2, champ1bis, champ2bis, idTechniqueMere#)

La table poissons pointera alors vers l'IDTechniqueMere et non l'idTechnique X. Les données de la technique concernée seront alors accessibles via la relation techniquemere<->technique_X via le champ commun idtechniquemere.

Dans ce cas, on optimise le stockage car aucune valeur nulle, autre que les données non saisies volontairement, ne sera présente. Et surtout, l'intégrité des données est préservée via les mécanismes internes du SGBDR. Seul inconvénient, on complique un peu le développement de l'interface.

Enfin, la représentation par méta-données comme dans le deuxième exemple de Simplifi peut être intéressante si les caractéristiques à saisir sont sensées évoluer dans le temps. Dans ce cas le développement sera plus complexe puisqu'il va falloir maintenir une liste des caractéristiques de chaque technique, et la moindre requête sur une technique nécessitera une jointure (à préférer à un IN) avec cette table des caractéritiques. Mais la cerise sur le gateau est que l'utilisateur peut créer autant de technique qu'il le souhaite avec les caractéritiques qu'il désire, ce qui je l'accorde n'est pas forcément adapter à tous les cas.

[f-leb]

Bonjour à tous,

Si la règle de gestion (à confirmer) est : une technique est soit une technique de type 1, soit une technique de type 2, on écrira plutôt :

[Technique1]-1-------1-[Technique]-1-------1-[Technique2]

Technique(idTechnique, NomTechnique,….)
Technique1(#idTechnique, champ1, champ11,…)
Technique2(#idTechnique, champ2, champ22,…)

Avec mise en œuvre d’une contrainte XT.

Ensuite, c’est du gâteau : Poisson(idPoisson, nomPoisson,…, #idTechnique) reliée à la table générique [Technique].

[Tofalu]

Bonjour à tous,

Si la règle de gestion (à confirmer) est : une technique est soit une technique de type 1, soit une technique de type 2, on écrira plutôt :

[Technique1]-1-------1-[Technique]-1-------1-[Technique2]

Technique(idTechnique, NomTechnique,….)
Technique1(#idTechnique, champ1, champ11,…)
Technique2(#idTechnique, champ2, champ22,…)

Avec mise en œuvre d’une contrainte XT.

Ensuite, c’est du gâteau : Poisson(idPoisson, nomPoisson,…, #idTechnique) reliée à la table générique [Technique].

Ce qui revient à ma deuxième proposition à la différence prêt que j'utilise une clé primaire différentes pour les filles et la mère. Je suppose que c'est mieux ainis mais je n'arrive pas à comprendre pourquoi j'ajoute une champ Surement par habitude d'avoir une clé en num_auto.

En plus, c'est pas comme si je prônais cette façon de faire

http://warin.developpez.com/tutoriel...ees-access/#LV

[sylvain77]

Merci beaucoup pour vos reponses. Le lien vers l'article concernant l'heritage est vraiment tres interessant et m'a permis de mettre tout cela en place en n'ayant ni vide dans ma base et en conservant l'intégrité de la base.

Ca semble tellement evident maintenant.

Je dois maintenant explorer ces contraintes pour voir comment les adapter a ma base.

Merci

Sylvain

[Tofalu]

Dans la mesure où la base serait autonomne, c'est à dire, que jamais un autre programme viendra ajouter des données directement dans celle-ci, je pense que tu peux passer ton chemin en ce qui concerne les contraintes qui ne sont pas fondamentales ici.