Discussion :

[cidmcflow]

2 table

fille [nom, centres_interet]
garcon [nom, centres_interet]

comment réaliser une 3eme table

association[nom fille, nom garçon]

tout en respectant la condition : il faut qu'il est le même centre d'interet

[marot_r]

fille [nom, centres_interet]
garcon [nom, centres_interet]
association[centres_interet, nom fille, nom garçon]

et mettre une relation avec intégrité référentielle entre

association et garcon sur nom_garcon, centre_interet
association et fille sur nom_fille, centre_interet.

Je te suggère aussi ne pas faire 2 tables : garcon et fille mais une seule table personne avec un champ sexe. Ca te simplifiera la vie quand tu voudra sortir des listes de personnes.

Avec 2 tables il te faudra 2 listes séparées ou jouer avec la source de ta liste. Avec une seule table tu as simplement à filtrer ceux que tu veux voir. N'est-ce pas plus simple ?

A+

[cidmcflow]

justement je n'arrive pas à mettre une relation avec intégrité référentielle sous access. access me met qu'il y a une erreur d'index.

C'est vrai qu'une table est plus simple pour les personne, cependant je ne comprend pas très bien l'histoire du filtrage. je fais cela grâce à une requête ?
Il n'y a donc pas un moyen simple de réglé ce petit problème tout bête (PS : je me casse la tête dessus depuis une heure)

[marot_r]

Si tu permets un autre conseil n'utilise pas le nom comme clef primaire d'une table car il existe des homnymes, un numAuto est bien meilleur.

Dans ta structure actuelle, il faut que tu définisses un index unique sur Nom+CentreInteret pour tes deux tables garçon et fille.

Ensuite il faut que tu définisses un index unique sur ta table à 3 champs composé des trois champs, surtout pour être sur que tu n'associes pas 2 fois les même personnes pour le même centre d'intérêt.

Personnelement voilà comment je monterai ma BD.

Table Personne
ClefPersonne (numAuto)
Sexe
Nom
Autres renseignements utiles.

Table Interet
ClefInteret (numAuto)
Libelle
Autres renseignements utiles.

Table InteretPersonne
ClefPersonne (long)
ClefInteret (long)

Clef primaire = ClefPersonne+ClefInteret, car une personne peut avoir plusieurs centre d'intérêt, non ?

Table InteretEnCommun
ClefInteret (Long)
ClefPersonne1 (long)
ClefPersonne2 (long)

ClefPrimaire = ClefInteret+ClefPersonne1+ClefPersonne2, car 2 personnes peuvent avoir plusieurs centres d'intérêts en commun, n'est-ce pas ?

Est-il absolument indispensable que les deux personnes soient de sexe différents ? Si oui, ce modèle là ne permet pas de le garantir par modélisation mais tu peux le gérer par programme.

Tu noteras aussi que le modèle ne garantie pas que tu n'associes Personne A et B puis Personne B et A, ni A avec A et B avec B. Ceci est aussi à faire par programme.

Quand tu es dans la fenêtre des relations, le truc consiste à ajouter 2 fois la table Personne.

Puis de faire une relation

entre InteretPersonne<->InteretEnCommun sur ClefInteret+ClefPersonne et

entre InteretPersonne_1<->InteretEnCommun sur ClefInteret+ClefPersonne_1.

A+

[marot_r]

C'est vrai qu'une table est plus simple pour les personne, cependant je ne comprend pas très bien l'histoire du filtrage. je fais cela grâce à une requête ?

Oui, au moment où tu en as besoin, tu affiches tous les enr qui sont de sexe féminin par exemple. Quand tu ouvres un formulaires tu peux aussi demander à Access de n'afficher que certains enregistrements. Cela t'obliges à gérer seulement des sélections dans ta liste et pas des données réparties entre 2 tables.

A+

[cidmcflow]

Merci, je vais regarder cela, en effet cela ne marche pas également si on impose comme contrainte que chaque personne ne peut avoir qu'un seul centre d'interet.
je vais plutot regarder cela du coté des formulaires et non dans la conception de mes tables.

[marot_r]

Si tu ne veux qu'un seul centre d'intéret, il suffit de mettre ta clef primaire sur l'identifiant de la personne alors tu ne pourras créer qu'un seul centre d'intérêt par personne. Tu peux aussi intégrer la clef Centre d'intérêt à la table des personnes comme cela une personne = un centre.

Il est important de bien concevoir son modèle de tables car le contrôle par la programmation repose sur le talent du programmeur.

Si tu as un modèle de table bien monté tu améliore grandement les qualité d'intégrité des données dans ta base. Par exemple, même si la personne n'utilise pas les forms, la bd s'assure que si tu entre A dans une table il faut que ce A existe dans une table de référence et te préviens si tu essayes de supprimer ce A de référence et qu'il est utilisé dans une autre table.

Si tu te reposes uniquement sur la programmation alors tu risques que quelqu'un oublie les règles d'intégrités et 'bousille' tes données tu vas te retrouver avec des A sans références et des machins qui flottes sans que tu puisses les ratcaher à quoi que ce soit.

A+

[cidmcflow]

Merci beaucoup pour tout ces renseignement, en effet j'opte plutôt pour une bonne conception de mes tables et de mes relations.

Si on met le champ "nom" en clé primaire (et pas celui de "interet") on ne peut pas faire une intégrité referentielle entre les table homme ou femme et la table assosiaction.

Mais j'ai trouvé la solution. Je met bien les 2 en clé primaire pour me permettre de faire une relation. Mais j'utilise les indexs des table homme et femme pour spécifier que le champ "nom" doit être unique. Ainsi aucun doublons sur le champ nom n'est possible -> donc un seul interet par personne

Merci a+

[Siguillaume]

Mais j'ai trouvé la solution.

Et le tag ?