[AC-2007] relation 2 à plusieurs

[ben07]

Bonjour,

Je débute avec Access et j'ai du mal à modéliser mes tables :

J'ai une tables contenant des points, la clé primaire est un numéro auto et il y a aussi plusieurs autre informations. Je souhaite créer des segments à partir de ces points, donc à chaque fois un point A et un point B. J'ai donc une relation 2 à plusieurs : un segments contient deux points, un point peut faire partir de plusieurs segments.

J'ai un peu cherché et il semblerai que la solution est de créer une table de jointure, c'est ce que j'ai fait (voir image jointe). Tout d'abord, pouvez-vous me confirmer que c'est la bonne solution ? Ensuite mon problème réside pour la saisie, qui consistera plutôt à l'import de données depuis Excel sous la forme :
- numéro de segment
- numéro du point A
- numéro du point B
- autres caractéristiques qui devraient être stockée dans la table point_segment (donc en relation avec A ou B)
- autres caractéristiques qui vont dans la table segment

Comment faire ?

Je vous remercie par avance de m'apporter vos lumières.

[f-leb]

bonsoir,

quelle est la signification du champ [coté] dans la table [Point-segment] ?

[ben07]

Envoyé par f-leb

bonsoir,

quelle est la signification du champ [coté] dans la table [Point-segment] ?

Bonsoir,

C'est le coté du segment : soit A soit B. J'ai effectivement oublié de préciser que le coté a une importance ; un même point peut apparaitre des deux cotés.

[Richard_35]

Bonjour Ben07 et Fabien,

Intéressante discussion à laquelle je me permets de participer.

Envoyé par Ben07

.../... un même point peut apparaitre des deux cotés.

==> Cela veut-il dire que pour un même n° de point et un même n° de segment (clé primaire de Point_Segment), tu peux avoir un enregistrement avec côté=A et un autre avec côté=B ?

Envoyé par Ben07

Ensuite mon problème réside pour la saisie, qui consistera plutôt à l'import de données depuis Excel

==> Question "fondamentale" à résoudre !... En effet, via une saisie, les clés primaires (NuméroAuto) sont distribuées dans les clés étrangères par le process, alors que en intégration d'un fichier Excel, il faut distribuer les clés primaires (NuméroAuto) dans les clés étrangères par un autre moyen.

[f-leb]

salut Richard,

Envoyé par Richard_35

==> Cela veut-il dire que pour un même n° de point et un même n° de segment (clé primaire de Point_Segment), tu peux avoir un enregistrement avec côté=A et un autre avec côté=B ?

toi aussi tu te demandes ce qu'est un "coté de segment" ?

L'autre alternative à la table [point_segment] étant naturellement de mettre deux clés étrangères dans [Segments]:

Segments(idSegment, ..., #idPointA, #idPointB)

[ben07]

Bonsoir,

Envoyé par Richard_35

Bonjour Ben07 et Fabien,

Intéressante discussion à laquelle je me permets de participer.

==> Cela veut-il dire que pour un même n° de point et un même n° de segment (clé primaire de Point_Segment), tu peux avoir un enregistrement avec côté=A et un autre avec côté=B ?

Non, mais que tu peux touver un point étant A dans un segment et B dans un autre.

Envoyé par Richard_35

==> Question "fondamentale" à résoudre !... En effet, via une saisie, les clés primaires (NuméroAuto) sont distribuées dans les clés étrangères par le process, alors que en intégration d'un fichier Excel, il faut distribuer les clés primaires (NuméroAuto) dans les clés étrangères par un autre moyen.

Le NuméroAuto n'est que pour le segment, j'ai déjà tous les points existants.

[ben07]

Envoyé par f-leb

L'autre alternative à la table [point_segment] étant naturellement de mettre deux clés étrangères dans [Segments]:

Segments(idSegment, ..., #idPointA, #idPointB)

C'est ce que je fais actuellement mais ça pose d'autres problèmes :
1) les informations spécifiques à chaque point d'un segment sont nombreuses : je me retrouve donc avec info1_A, info1_B, info2_A, info2, etc. au final j'ai une table énorme (x2).
2) lorsque j'ai besoin d'obtenir la liste de tous les points utilisés dans des segments, je suis obligé de faire une requête qui liste tous les points A puis la même qui liste tous les points B et ensuite de faire une union entre ces requêtes. Le résultat de cette union ne me permet plus d'avoir une sous feuille de donnée qui liste les segments auquels les points appartiennent.

[Richard_35]

3 choses :

*** 1 ***

Envoyé par Ben07

Non, mais .../...

==> OK, alors la clé primaire de Point_Segment est bonne. Effectivement, la solution de Fabien (salut, Fabien) est équivalente.
*** fin 1 ***


*** 2 ***

Envoyé par Ben07

Le NuméroAuto n'est que pour le segment .../...

==> pourtant, dans ton premier post, tu dis :

Envoyé par Ben07

J'ai une tables contenant des points, la clé primaire est un numéro auto .../...

==> Contradictoire, non ?
*** fin 2 ***


*** 3 ***
Dans ta table segment, tu as :
- N° (clé primaire, numéro auto)
- Distance
- Angle A->B

Sachant que

Envoyé par Ben07

.../... un segments contient deux points .../...

==> Qu'entends-tu par "Angle A-B" ?
Un segment est un ensemble de 2 points donc, une droite : je n'ai pas compris ce que vient faire l'angle A-B là dedans.
*** fin 3 ***

[ben07]

point 2 : Ce n'est pas contradictoire, la table point est déjà existante, que ce soit des numéros auto ne change rien, c'est juste un identifiant unique qui désigne un point (d'ailleurs en réalité, ce n'est pas un numéro auto).

point 3 : C'est l'angle que forme le segment par rapport à l'axe des abcisse (par exemple). Si je connais l'angle que forme le segment dans la direction A vers B, je peux calculer aussi celui entre B et A (+180° s'il est entre 0 et 179, - 180° sinon) donc aucun intérêt de stocker les deux valeurs.

[Richard_35]

Bonjour Ben07,

Envoyé par Ben07

.../... d'ailleurs en réalité, ce n'est pas un numéro auto

==> OK, c'est fondamental à savoir, en cas d'importation de fichier Excel.

Envoyé par Ben07

C'est l'angle que forme le segment par rapport à l'axe des abcisse (par exemple) .../...

==> OK, compris.


Pour en revenir à ta problématique d'origine :
Oui, ton schéma est correct. Personnellement, je préfère utiliser la méthode décrite par Fabien, concernant la table Point_Segment, soit :
- Id_Point_Segment (clé primaire, numéro auto)
- Num_Point
- Num_Segment
- Cote
==> ne pas oublier de créer un index unique sur le couple Num_Point/Num_Segment.
Cette solution s'adapte à l'emploi des assistants (je ne connais pas VBA), notamment pour les liaisons "champ père" / "champ fils" des sous-formulaires.

Mais la structure :
- Num_Point (clé primaire)
- Num_Segment (clé primaire)
- Cote
est, également, correcte.

Envoyé par Ben07

Ensuite mon problème réside pour la saisie, qui consistera plutôt à l'import de données depuis Excel sous la forme :

==> si tu prévoies une saisie :
- dans le formulaire Segment, un sous-formulaire sur Point-Segment qui affecte des Points (liste déroulante) à la table Point-Segment, tout en gardant, par défaut et non modifiable, la clé de Segment ;
- dans le formulaire Point, l'inverse.

En cas d'importation d'un fichier Excel :
le but, en final, étant de retrouver les clés pour les "mixer" entre elles, tu devras faire des liens entres libellés et en déduire la clé. Bien entendu, cela suppose que les libellés en question sont uniques. L'unicité devrait être contrôlée avant chaque importation.