Discussion :

[LecGaël]

Bonjour,

Je reviens vers vous pour mon projet, qui consiste à faire une base de données qui regroupe les différentes pièces d'un train, et je dois aussi creer l'interface qui permet de faire des recherches dans la base, ainsi que de pouvoir rajouter des éléments dans celle ci.
Je pars du principe qu'une pièce est unique mais peut être à différents Lieux, et cette pièce fait partie d'une famille de "pièces" une pièce unique peut avoir plusieurs numéro de Symbole (c'est un identifiant marketing pour commander la pièce).
Jusqu'ici j'ai crée une table Organe ( mes pièces) qui ne possède pas de doublons avec un id autoIncrementé, une table Famille, une table Equipement (Lieux) et une table OrganeEquipement.
Je n'ai pour l'instant crée aucune relations entre ces tables...
La table OrganeEquipement sert a faire correspondre les pièces en différents lieux , je lie l'id unique de la pièce avec l'id du Lieux, du coup je peux associé plusieurs fois la pièces mais à des lieux différents.

Ma question c'est de savoir si je suis sur la bonne voie, pour l'instant j'ai rentré un champ symbole dans la table Organe mais sachant qu'un organe peut avoir plusieurs numéros de symbole, je pense qu'une table OrganeSymbole s'impose pour lié un organe à plusieurs numéro de symbole.

L'idée serrait de pouvoir exploiter sur C# des outils comme les dataAdapter, les commandBuilder les datasets pour pouvoir modifier la base facilement depuis une interface, mais sachant que je débute dans les deux domaines, ça prend du temps...

EDIT: Voici une "MCD" sur l'image à gauche les entités représentent les tables que j'ai déja fait et a droite celle qui faudrait sans doute que je fasse, après comme je vous l'ai dit je n'ai fait aucune relations entre mes tables sur Access et ma question porte la dessus.



Voilà voilà bonne journée

[Jean-Philippe André]

Salut

le langage utilisé en bout de chaine n'a aucune importance sur l'architecture de ta BD

Aussi si on se limite à cet aspect, oui lorsque tu as une potentielle relation n-n, ca te prend une table intermediaire OrganeSymbole

[User]

Bonjour,

Comme le mentionne Jean-Philippe :

oui lorsque tu as une potentielle relation n-n, ca te prend une table intermediaire OrganeSymbole

Dans un MCD tu dois distinguer les entités des relations, et dans les relations tu ne mentionnes pas les clés des entités qui sont misent en relation.

Donc, j'aurais tendance à dire que ton MCD n'en est pas un et qu'il ressemble plus à un début de modèle relationnel avec des tables, manque juste les liens entre ces tables.

Par exemple, d'après ce que tu dis, tu aurais une relation 1-n entre Organe et symbole sur les champs id 1-n idOrgane.

Donc tu n'aurais pas besoin du champ symbole dans organe

Cdlt,

[Jean-Philippe André]

Salut,

je complète en indiquant que, vu de mon balcon, ca semble pas utile non plus d'avoir un champ auto increment ID danta table OrganeSymbole, car si tu mets la cle sur les 2 champs, ca suffira

[User]

Salut,

je complète en indiquant que, vu de mon balcon, ca semble pas utile non plus d'avoir un champ auto increment ID danta table OrganeSymbole, car si tu mets la cle sur les 2 champs, ca suffira

Tout à fait d'autant que ça permet d'assurer la cohérence des données.