Discussion :

[Richard_35]

Bonjour XGuarden et F-leb,

@ XGuarden
2°/ Clé(s) de liaison :"
J'aimerais avoir si possible un exemple de la différence sur une requêtes comparé a si je garde la clé primaire unique si possible =:0).

==> comme je te l'ai dit, c'est un point de détail. Les requêtes ne sont pas "dans la balance" de la décision : il y aurait un champ de jointure au lieu de deux, ce n'est donc pas le problème. Ce sont les divers assistants qui sont en cause : ils ne proposent qu'un seul champ de jointure.
==> ne perds donc pas de temps sur ce sujet.

@ F-leb
Dans la fenêtre "Relations" il y a effectivement un bouton "jointure...".
Encore une anomalie, ce bouton à rien à f#¤@ là.

==> je suis d'accord avec toi, F-leb, d'un point de vue "analyse" pure.
@ XGuarden : Access permet de définir, dans les relations, une jointure LEFT ou RIGHT par défaut, proposée à chaque requête faisant intervenir les deux tables concernées. Ces jointures sont modifiables, dans la requête, elles sont, juste, proposées.

[XGuarden]

J'ai apporté une petite modification a la base de donnée pour être conforme a l'idée qu'une personne peu parler plusieurs langue mais il n'y a qu'une langue principal par adresse. Dite moi ce que vous en penser.

[Richard_35]

Attention, un petit mot est important, dans ta phrase :

mais il n'y a qu'une langue principal par adresse

, c'est le mot principal !

En effet, dans ton schéma, ce n'est pas langue principale de l'adresse, c'est la seule langue de l'adresse : nuance importante.
Si tu veux une langue principale d'une adresse et d'autres langues (non-principales, donc) liées à l'adresse, alors il faut une autre table de liaison.

Sinon, le reste me semble OK.
F-leb, ton avis ?

[XGuarden]

Seulement la langue principal de l'adresse est important a retenir, puisque les différente langue parlé a cette adresse sont stocké via tblPersonne.

Je travail présentement a l'ajout d'une table Rapport ainsi que la création de requête. A noter que je suis incapable de rajouter des langues dans la table langue. Mystère....

[XGuarden]

Une petite mise-à-jour avec la nouvelle table.
Le tout me semble ok.
J'ai compris que les liaisons sont seulement sugerer et donc inutile...
Je ne suis pas encore sur a propos de la mise-à-jour en cascade si ça change quelque chose dans mon projet par contre.

Je vais avoir besoins d'aide pour mes requêtes qui ne fonctionne pas exactement comme souhaité mais je crois que rendu la je vais devoir poster ça dans une autre section.

Merci de votre aide, dite moi ce que vous en penser.

[XGuarden]

Voila la pièce jointe.. J'avais oublier de la poster.
En passant, il y a un petit problème, il m'est impossible avec le modèle actuel de créer une personne qui n'est pas proclamateur...

[f-leb]

...il m'est impossible avec le modèle actuel de créer une personne qui n'est pas proclamateur...

Un proclamateur est avant tout une personne

Dans le formulaire, il faut s'arranger pour créer et renseigner la personne dans un premier temps (nom, prénom,...). Si la personne est un proclamateur (une case à cocher "Proclamateur" par exemple), on fait apparaître les données complémentaires de la table des proclamateurs (date de naissance, responsable ...).
Pour le bout de schéma Personne-1-----1-Proclamateur, tu peux t'inspirer des exemples d'interfaces du tutoriel http://warin.developpez.com/tutoriel...onnees-access/

Pour la table des rapports pourquoi pas mais on ne connait pas le contenu de ces rapports et la signification des champs nbxxxxx...

[Richard_35]

Bonjour XGuarden et F-leb,

...il m'est impossible avec le modèle actuel de créer une personne qui n'est pas proclamateur

Dans les "Relations", le sens est important.

Dans la relation entre Personne et Proclamateur, tu dois avoir Proclamateur en Table/Requête et Personne en Table/Requête liée : de ce fait, Proclamateur doit exister pour créer Personne. Il faut donc "inverser" la donne et tu pourras créer des Personnes sans Proclamateur.

[f-leb]

bonjour Richard,

... de ce fait, Proclamateur doit exister pour créer Personne.

C'est l'inverse.

Il est vrai que la représentation Personne-1------1-Proclamateur nous apparaît comme une relation "symétrique " dans le fenêtre des relations d'Access alors qu'il n'en n'est rien.

Avec les cardinalités (façon Merise), on écrirait:

Personne----0,1-----être------1,1------Proclamateur

Un proclamateur est une personne (cardinalités mini et maxi=1)
Un personne peut être un proclamateur (cardinalité mini=0).

Concrètement Personne.idPersonne est une clé primaire de type NumeroAuto,
Proclamateur.idPersonne est clé primaire et clé étrangère de type numérique référençant Personne.idPersonne.

Il y a donc une table référencée et une table référençante mais les cardinalités mini n'apparaissent pas dans la fenêtre des relations.

Une personne habite à une adresse, cette personne pouvant être un proclamateur.
Une attribution concerne un proclamateur, ce proclamateur qui est lui même une personne avec une adresse
etc...

vous me suivez

Mais bon on se comprend hein, faut en effet inverser la donne

[Richard_35]

Bonjour F-leb,

Je pense que nous pensons la même chose tout en disant l'inverse...

********************************************
Le symptôme décrit par XGuarden est :

En passant, il y a un petit problème, il m'est impossible avec le modèle actuel de créer une personne qui n'est pas proclamateur...

ce en quoi, je réponds que, si ce symtôme se produit maintenant c'est que, dans "Relations" il doit être inscrit (maintenant) :

Proclamateur en Table/Requête et Personne en Table/Requête liée

et

de ce fait, Proclamateur doit exister pour créer Personne

car, maintenant, le sens n'est pas le bon.
********************************************

Donc, pour créer une Personne sans que, forcément, elle soit présente dans Proclamateur, il faut :

"inverser" la donne et tu pourras créer des Personnes sans Proclamateur

soit saisir Personne en Table/Requête et Proclamateur en Table/Requête liée.

[f-leb]

Je pense que nous pensons la même chose tout en disant l'inverse...

voui c'est exactement ça ! C'était juste pour noyer le poisson

Je ne suis pas encore sur a propos de la mise-à-jour en cascade si ça change quelque chose dans mon projet par contre.

vaut mieux la mettre.

Note aussi que la suppression en cascade sur Personne-Colporteur me paraît justifiée. Si on supprime une personne, elle ne peut exister comme colporteur et on supprime aussi le colporteur.

[XGuarden]

Richard_35 t'a mit dans le 1000 =:0)
C'était exactement ça le problème. JE vous redonne des news.