Discussion :

[XGuarden]

langue a deux aspect.
Quand on parle d'une adresse, c'est la langue de la personne qui réside la.
Quand on parle de proclamateur, c'est la liste des langues parlées par le proclamateur.

Ainsi, il est possible de faire une requête pour faire afficher par exemple tout les adresse parlant l'allemand ou le mandarin, etc.. et de faire apparaître la liste des proclamateur capable d'aller a cette adresse(étant donné la langue parlé).

PS. Je travail a ajuster la base de donnée. Je vais bientot poster une mise=à-jour.

[XGuarden]

Je précise comment marche le bout de schéma :
Adresse-1-----1-EtreUneAdresseDeColporteur

En fait un adresse peu comporter plusieurs colporteur(proclamateur)
Rien empêche a une homme et a une femme de travailler tout les deux. Ce qui arrive effectivement a plusieurs reprise dans la base de données.

Une relation Adresse-1-----00-EtreUneAdresseDeColporteur ne serait-elle pas plus approprié?

Pour ce qui est des relations, en effet je n'avais pas pensé a leftjoin et rightjoin.
Mais j'admet que je suis encore en trein de réfléchir ou appliquer l'intégralité referenciel(mise a jour en cascade et suppression en cascade). Je ne voudrais pas faire une grosse erreur.

Je poste une copie de la base de donnée puisqu'on ne voit pas sur Screenshots le genre de relation existant au niveau de l'intégralité réfférenciel.

J'ai rajouté la liaison entre visite et adresse que tu a proposé. Je vais voir ce que ca donne niveau requêtes. Par contre puisqu'une visite est toujours applicable pour une adresse, une liaison adresse attribution n'aurait t-elle pas été souhaitable?

Merci de ton aide.

[Richard_35]

Bonjour XGuarden et f-leb,

J'ai un peu "lâché l'affaire", il semble...

Je ne peux pas lire la pièce jointe, je suis en Access 2003.

Néanmoins, la gestion de la langue semble être une nouveauté. Quoiqu'il en soit, si j'ai bien compris :

• 1 adresse à une langue et une seule ;
• 1 proclamateur peut posséder N langue(s) ;
• 1 langue peut être parlée par N proclamateur(s).

Il semble nécessaire de gérer une table LANGUE :
- Id_langue (clé primaire)
- nom_langue
- etc...

Une table LIAISON_PROCLAMATEUR_LANGUE :
- Id_liaison (clé primaire)
- Id_langue
- Id_proclamateur
==> LANGUE 1--->∞ LIAISON_PROCLAMATEUR_LANGUE, via Id_langue ;
==> PROCLAMATEUR 1--->∞ LIAISON_PROCLAMATEUR_LANGUE, via Id_proclamateur ;
==> Index unique sur le couple Id_langue/Id_proclamateur.

Ceci dit, tu l'as, peut-être, déjà prévu dans ta base .accdb.

[f-leb]

re moi, salut à tous

En fait une adresse peu comporter plusieurs colporteurs(proclamateurs)
Rien empêche a une homme et a une femme de travailler tout les deux. Ce qui arrive effectivement a plusieurs reprises dans la base de données.

voilà qui est nouveau ! Jusqu'à présent on avait idAdresse→Nom, idAdresse→Prenom etc... (une adresse "détermine" une personne).
Il faut donc une nouvelle table pour ces personnes:
Personne(idpersonne, Nom, Prenom,...).

A une adresse peuvent habiter plusieurs personnes, une personne habite à une adresse:
Personne-∞-------1-Adresse


Une personne peut être un colporteur, un colporteur est une personne (avec des attributs spécifiques courriel, matricule, date d'embauche etc... comme indiqué plus haut):
Colporteur-1--------1-Personne


Tu m'as également précisé qu'un responsable est aussi un colporteur, et que selon les attributions un colporteur pouvait être colporteur et responsable à la fois. Il n'y a donc aucune raison de faire une table pour les colporteurs et une table pour les responsables.
===>tout le monde dans le même sac (la table Colporteur à laquelle tu peux rajouter un champ Oui/Non pour signaler que le colporteur est en principe un responsable).

Comme Richard pour les langues avec une table de jonction:
Personne-1------∞-ParlerLangue-∞-------1-Langue

Je prépare un schéma qui devrait être définitif (ou pas loin en tout cas)...

EDIT: comme ça:

[XGuarden]

Voici la version actuel. Je continue d'Essayer de l'ajuster selon vos suggestion.
Mais j'ai cru bon de vous montrer pour avoir votre avis.

[XGuarden]

Il y a également les types de jointure. Par exemple jointure droite, gauche etc.., suppression en cascade, mise-a-jour en cascade, etc...
Je me demande bien quoi mettre. Certain lien son simple d’autre non, Voici ce que je crois être bon présentement:

Légende:
I = Intégrité référenciel a oui
M = Mise-a-jour en cascade
S = Suppression en cascade

Territoire - Adresse
Supprimer un territoire n’empêche pas que ces adresse existe toujours...
Bien que d'un autre coté elle n'est plus pertinente puisqu'elle n'est pas atrtibué a aucun Territoire. Cependant, il est possible qu'un territoire soit supprimé mais que les adresses soit relocalisé vers un autre territoire par exemple pour fusionner deux territoire trop petit(I-M)

Adresse - Visite
Si une adresse est supprimé je ne voit pas l'interet de garder les visite qui on été effectué a cette adresse. Maison détruite pour la construction d'un centre d'achat par exemple. (I-M-S)

Territoire - AttributionTerritoire
Si un territoire est supprimé, les attributions qui ont été faite pour celui-ci reste inchangé logiquement(c'est seulement du passé). L'idéal serait sans doute de supprimer les attribution pour ce territoire ou bien de trouver un moyen d'indiquer que ce territoire n'existe plus(I-M)

AttributionTerritoire - Visite
Vue que attributionTerritoire sert principalement a garder en mémoire les différente attribution effectué au court du temps, le fait de supprimer une attribution n'a aucun effect sur rien d'autre. Il s'agit probablement que d'une corection d'erreur et une adresse et par conséquent les visites correspondante peuvent être relocalisé vers un autre territoire(I-M)

AttributionTerritoire - Visite
Notes: J'ai de la difficulté a comprendre pourquoi créer deux tables Proclamateur(une pour les responsables). Pourquoi Access ne permet pas directement de faire deux lien vers une tables? Une table sous forme de requêtes qui vérifie la condition "EstUnResponsable" ne serait-elle pas mieux?

Proclamateur - Personne
Même si un proclamateur quite son rôle, il reste une personne, il devient juste une personne comme les autres. (I-M) Par contre su une personne est supprimé(morte) il ne peu plus être un proclamateur. Mais il l'a déjà été et a déjà possiblement recu des assignation, il fut les garder en mémoire. Par exemple si je fait une requêtes sur le nombre de proclamateur au cour de la dernière année, si je le supprime le résultat sera faussé.(I-M)

Personne -ParleLangue
La relation n'exite plus sans la personne
(I-M-S)


Personne- Adresse
L'adresse existe toujours si la personne meurt, en fait une autre personne va finir par occuper la maison...
(I-M)

ParleLangue - Langue
La langue existe toujours si une relation est supprimé.
(I-M)


J’espère avoir été clair merci de me donner votre avis.

[f-leb]

bonjour,

à mon avis, tu brûles

Quelques broutilles qui traînent ici et là...

je vois un champ "langue" qui traîne dans la table Adresse et j'aurais plutôt vu le champ "courriel" dans Personne. Pour "telephone" peut-être tenir compte des types de téléphone (fixe, mobile), qu'une personne peut avoir plusieurs téléphones. A voir...

Un champ "idAdresse" traîne encore dans Proclamateur.

Distingue tes champs "Mémo" en MemoVisite, MemoAttribution, MemoAdresse etc. Évite les accents en préférant "telephone" plutôt que "téléphone".

Le champ idParlerLangue n'est pas utile.
ParlerLangue(#idLangue, #idPersonne) avec la clé primaire sur les deux champs.

Reste à programmer quelques contraintes (pense aux évènements de table si ton application est pour Access 2010).

Visite(idVisite, #idAdresse, #idAttribution, DateVisite)
L’inconvénient est effectivement d’avoir à gérer "une boucle".
La gestion n’est pas très compliquée, il faut notamment vérifier lors de l’insertion d’une visite que:
- L’idAdresse soit parmi celles du territoire de l’idAttribution.
- La DateVisite est supérieure ou égale à la DateAttribution prévue par l’idAttribution et inférieure ou égale à la DateRetourEffectif si celle-ci est renseignée.

...Un territoire peut faire l’objet de plusieurs attributions (mais pas en même temps, on est bien d’accord qu’il faudra vérifier ça en comparant les dates d’attribution d’un territoire).

Sinon ça me semble tout bon. Un avis Richard ?

[f-leb]

Notes: J'ai de la difficulté a comprendre pourquoi créer deux tables Proclamateur(une pour les responsables).

oulala non. Proclamateur et Proclamateur_1 désigne la même table (dans la fenêtre des relations, tu obtiens Proclamateur_1 en insérant une deuxième fois la table Proclamateur).

Pourquoi Access ne permet pas directement de faire deux lien vers une tables?

Bien vu, c'est en effet très curieux mais la fenêtre des relations n'est qu'une représentation graphique. Dans les faits il n'y a qu'une seule table Proclamateur mais qui joue deux rôles (proclamateur et proclamateur responsable)

L'idéal serait sans doute de supprimer les attribution pour ce territoire ou bien de trouver un moyen d'indiquer que ce territoire n'existe plus(I-M)

Bonne idée, on parle de suppression "logique". Tu rajoutes un champ Oui/non "TerritoireActif".

Ton analyse m'a l'air bonne, je regarderais en détail...

bonne journée.

[Richard_35]

Bonjour XGuarden et F-leb,

F-leb, tout semble aux petits oignons... chapeau !
Juste 6 petites remarques :

1. Pour la clarté, ajouter le lien Proclamateur_1 1--->1 Personne ;
   
   
2. Concernant

   Le champ idParlerLangue n'est pas utile.
   ParlerLangue(#idLangue, #idPersonne) avec la clé primaire sur les deux champs.

   C'est vrai mais, personnellement, j'apprécie d'avoir un seul champ qui identifie la liaison en elle-même, et un index unique pour sécuriser le groupe concerné. En effet, je ne connais pas VBA et, en cas de besoin, j'utilise donc "à donf" les assistants : ceux-ci, en cas de liaisons diverses entre deux entités proposent souvent un seul champ de liaison (formulaire/sous-formulaire, état/sous-état, assistant d'ajout de bouton pour appeler un fromulaire, etc...). Donc, pour moi, en tout cas, je trouve bien pratique cette clé primaire mono-champ. Enfin, c'est un détail, et cela revient strictement au même, je suis d'accord.
   
   
3. Je note que l'historique des adresses d'une entité n'est pas intéressante dans ton projet. En conséquence, une ancienne adresse ne sera pas conservée et, par exemple, il sera impossible de retrouver la liste des adresses successives d'une personne.
   
   
4. XGuarden, tu as, visiblement, tranché concernant ton interrogation

   Je ne suis pas actuellement certain si une attribution doit pouvoir être faite pour plusieurs territoire ou non.

   En effet, en final, 1 attribution (sous le même n°) ne pourra concerner qu'un seul territoire dans la relation indiquée :
   - Territoire 1--->∞ Attribution, via IdTerritoire ;
   - Attribution 1--->1 Territoire, via IdTerritoire.
   
   
5. Il n'y a plus de table Responsable et tu as penché pour un champ Oui/Non (case à cocher). Pas de problème mais, si un jour tu dois enregister des informations propres aux responsables, tu devras alimenter les tables correspondantes et tester, à chaque fois, si la case "responsable" est cochée ou non. Par exemple, tu pourrais vouloir stoker la date de passage en "responsable", le n° de contrat de passage en "responsable", etc... Et, dans ce cas, tu stockeras ces informations dans Proclamateur ou dans Personne
   
   
6. Attention aux options d'intégrités référentielles... elles peuvent être "destructrices". Tu peux cocher l'intégrité référentielle sans cocher les options proposées.

Ceci dit, la trame me semble OK.

[f-leb]

bonjour Richard,

Pour la clarté, ajouter le lien Proclamateur_1 1--->1 Personne ;

pour moi non, on a déjà Proclamateur-1-----1-Personne et ça suffit.
La table Proclamateur_1 n'existe pas dans les faits. En fait c'est une anomalie curieuse de l'outil "relations" d'Access qui ne permet pas de lier deux champs vers la même table.

Regarde la réflexion de fsmrel (qui en connait un bout) dans la discussion :http://www.developpez.net/forums/d99...l/#post5566030
il qualifie même cette façon de faire comme étant "débile"

Attention aux options d'intégrités référentielles... elles peuvent être "destructrices". Tu peux cocher l'intégrité référentielle sans cocher les options proposées.

Surtout la suppression en cascade, mortel !

[XGuarden]

f-leb

"je vois un champ "langue" qui traîne dans la table Adresse et j'aurais plutôt vu le champ "courriel" dans Personne. Pour "telephone" peut-être tenir compte des types de téléphone (fixe, mobile), qu'une personne peut avoir plusieurs téléphones. A voir..."

en fait ce champ langue désigne la langue principal parlé a cette adresse. C'est ce champ qui détermine quel proclamation qui convient d'envoyer. Par exemple une adresse marqué chinois même si les gens parle aussi le français peut se voir attribuer un proclamateur qui parle chinois vue que ça touche davantage les gens d'entendre le monde parler dans leur langue maternel.

"Reste à programmer quelques contraintes (pense aux évènements de table si ton application est pour Access 2010)."

Je lis de la documentation la dessus, ce concept est nouveau pour moi.

Pendant que j'y pense, connaisser vous une validation efficace pour les adresse de courriel?

Juste pour être sur, avez-vous compris mes exemple de liaison I-M-S?

"Pour la clarté, ajouter le lien Proclamateur_1 1--->1 Personne ;"
C'est fait, mais est ce que ça changera quelque chose autre que graphiquement?


"clé primaire sur les deux champs."
J'ignore comment faire, je vais lire de la doc, mais il semble que ça ne fasse pas l'unanimité comme idée.

"Je note que l'historique des adresses d'une entité n'est pas intéressante dans ton projet. En conséquence, une ancienne adresse ne sera pas conservée et, par exemple, il sera impossible de retrouver la liste des adresses successives d'une personne."

C'est exacte, garder la liste des adresse d'un proclamateur n'a aucune importance, en fait garder des anciennes adresse pourrais juste porter a confusions. Pour ce qui est des personne c'est la même chose.

Pour le point 5, j'ai pessé la question. Et dans le contexte, il est en fait impossible que cette information soit utile un jour. Tout ce qui importe, c'est de savoir que cette personne a le droit d'attribuer des territoires. PS. Même si une personne perd le doit d'attribuer des territoires, elle peut quand même rester la personne qui a attribué des territoire par le passé sans problème avec le shéma.

Pour le point 6. Justement j'ai laissé un message sur ce que je pensait comme liaison. Je ne suis pas sur entre quel relation je peu mettre suppression...

Je laisse un Screenshots a jour.
Merci encore pour votre aide =:0)
A noter qu'il existe également une autre table qui devrai être créer mais qui n'a pas encore d'utilité pour l'instant. Les proclamateurs remettre a chaque mois une fiche ou il mentionne le nombre d'heure travailler et divers petit élément. J'ignore si je devrais intégrer ça tout de suite ou l'ajouter en temps et en lieu.

[XGuarden]

J'ai ré enlever le lien avec la deuxième table proclamateur...
La suppression en cascade est bonne pour visite et adresse me semble correcte non? A quoi bon garder la liste des visites faites a une adresse qui n'existe même plus.

[f-leb]

... A quoi bon garder la liste des visites faites a une adresse qui n'existe même plus.

Si tu dois un jour récompenser le "proclamateur du mois" sur le nombre de visites qu'ils ont effectués, tes proclamateurs ne seront peut-être pas contents d'apprendre que telle visite à 50 bornes de chez eux ne compte pas sous prétexte que l'adresse n'existe plus.

[f-leb]

XGuarden, tu as, visiblement, tranché concernant ton interrogation En effet, en final, 1 attribution (sous le même n°) ne pourra concerner qu'un seul territoire dans la relation indiquée :
- Territoire 1--->∞ Attribution, via IdTerritoire ;
- Attribution 1--->1 Territoire, via IdTerritoire.

j'ai du mal avec tes notations Richard.

Pour ma part, soit j'écris:
Territoire-1-----∞-Attribution

comme dans la fenêtre "relations" d'Access (je copie/colle le symbole "∞" à partir de Word ce qui fait que sur le forum j'ai toujours Acces et Word ouvert en même temps).

Soit j'écris:

Attribution---1,1---concerner-----0,n-----Territoire

avec les cardinalités façon MCD de chez Merise mais tout le monde ne connaît pas.

[Richard_35]

1°/ Schéma relationnel :
Richard :

Pour la clarté, ajouter le lien Proclamateur_1 1--->1 Personne

F-leb :

pour moi non, on a déjà Proclamateur-1-----1-Personne et ça suffit.
La table Proclamateur_1 n'existe pas dans les faits. En fait c'est une anomalie curieuse de l'outil "relations" d'Access qui ne permet pas de lier deux champs vers la même table.

==> Oui, oui, je sais que c'est la même table et que Access suffixe les mêmes tables par "_x" : c'est pour cela que je parlais, uniquement, de clarté dans le schéma.

XGuarden :

J'ai ré enlever le lien avec la deuxième table proclamateur...

==> c'était juste pour la clarté du schéma : aucune importance que le lien soit établi ou non, du moment qu'il est établi avec Proclamateur.

C'est fait, mais est ce que ça changera quelque chose autre que graphiquement?

==> donc, non, cela ne change QUE le graphique.


2°/ Clé(s) de liaison :
XGuarden :

"clé primaire sur les deux champs."
J'ignore comment faire, je vais lire de la doc, mais il semble que ça ne fasse pas l'unanimité comme idée.

Richard :

C'est vrai mais, personnellement, j'apprécie d'avoir un seul champ qui identifie la liaison en elle-même, et un index unique pour sécuriser le groupe concerné. En effet, je ne connais pas VBA et, en cas de besoin, j'utilise donc "à donf" les assistants : ceux-ci, en cas de liaisons diverses entre deux entités proposent souvent un seul champ de liaison (formulaire/sous-formulaire, état/sous-état, assistant d'ajout de bouton pour appeler un fromulaire, etc...). Donc, pour moi, en tout cas, je trouve bien pratique cette clé primaire mono-champ. Enfin, c'est un détail, et cela revient strictement au même, je suis d'accord.

==> à toi de voir, mais ce n'est pas fondamental.


3°/ Nouvelle table :

A noter qu'il existe également une autre table qui devrai être créer mais qui n'a pas encore d'utilité pour l'instant. Les proclamateurs remettre a chaque mois une fiche ou il mentionne le nombre d'heure travailler et divers petit élément. J'ignore si je devrais intégrer ça tout de suite ou l'ajouter en temps et en lieu.

==> il vaut mieux tout faire dans la foulée, tant que c'est chaud...


4°/ N° téléphone :
Un n° téléphone fixe est lié à un lieu (Adresse) et, en général, est unique pour une adresse. En revanche, un n° de téléphone mobile est lié à une personne et, celle-ci, peut en avoir plusieurs.
A voir s'il faut gérer cette partie.


5°/ Divers (pour le fun) :

j'ai du mal avec tes notations Richard

En fait, la flèche traduit le "pour" de "un pour n". D'ailleurs, j'aurais dû écrire Attribution 1<--->1 Territoire, au lieu de Attribution 1--->1 Territoire.
Mais, c'est vrai que j'aime bien la notation Merise mais bon, ce n'est pas dans l'air du temps (le temps des Merise...).

D'autre part, j'attendais la fin de ce fil pour te demander comment tu indiquais le signe "∞" (que j'avoue, piteusement, copier/coller de l'un de tes post...).

[XGuarden]

PA propos des point:
"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).

"3°/ Nouvelle table :"
Je vais l'ajouter et poster le résultat sous peu.

"4°/ N° téléphone :"
Tu a raison ça aurait pu avoir une importance, ici on parle de téléphone fixe uniquement. D'ailleur même les cellulaire ont une seul adresse de facturation. Par contre au cas ou j'ai rajouter mémoPersonne. Il sera possible d'ajouter le numéro ce cellulaire en note si désiré dans ce champ.

Merci de votre aide, je poste la suite sous peu.

[f-leb]

Visite(idVisite, #idAdresse, #idAttribution, DateVisite)
L’inconvénient est effectivement d’avoir à gérer "une boucle".
La gestion n’est pas très compliquée, il faut notamment vérifier lors de l’insertion d’une visite que:
- L’idAdresse soit parmi celles du territoire de l’idAttribution.
...

par exemple avec la requête

qui retourne les couples (adresse, attribution) possibles. J'ai retiré les occurrences où l'adresse est celle d'un colporteur (critère PersonneQuiEstColporteur.idPersonne Est Null).

Sur l'évènement Avant Modification de la table visite, on écrit la macro:


Avec ça tu peux toujours courir pour rentrer une adresse qui n'est pas parmi les adresses du territoire de l'attribution.

[XGuarden]

C'est peut-être moi qui oublie de quoi mais quand tu dit:
"Avec ça tu peux toujours courir pour rentrer une adresse qui n'est pas parmi les adresses du territoire de l'attribution."

Dans quel circonstance cela peut-il arriver?
Quand est ce rentre t-on une adresse?
On crée la liste d'adresse, on les associe a un territoire et voila.
J'ai peut-être oublié quelque chose mais ou est ce qu'on demande une adresse?
Vue que les proclamateurs remettre une fiche de territoire comprenant la liste des adresses effectué et non effectué, il n'y a pas de possibilité qu'il ajoute une adresse inexistante. Bon je suis possiblement dans l'erreur mais...

Bien que je crois que tu voulais plutot dire:
"Avec ça tu peux toujours courir pour rentrer une VISITE qui n'est pas parmi les adresses du territoire de l'attribution."

Dans ce cas c'est tout a fait logique je crois.

J'aimerais savoir si d'apres vous certaine liaison devrais être gauche ou droite d'origine... Merci

[f-leb]

bonjour,

"Avec ça tu peux toujours courir pour rentrer une VISITE qui n'est pas parmi les adresses du territoire de l'attribution."

yaisse, je parlais bien de l'adresse (idAdresse) dans la table Visite...

J'aimerais savoir si d'apres vous certaine liaison devrais être gauche ou droite d'origine... Merci

Plus haut, j'ai écrit deux requêtes entre les tables Adresse et EtreUneAdresseDeColporteur. Une avec INNER JOIN et l'autre avec LEFT JOIN:

Code sql :

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

1
2
3
SELECT A.idAdresse, A.Nom, A.Prenom, C.courriel, C.DateEmbauche
FROM Adresse A INNER JOIN EtreUneAdresseDeColporteur C
ON A.idAdresse=C.idAdresse

Code :

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

1
2
3
4
SELECT A.idAdresse, A.Nom, A.Prenom
FROM Adresse A LEFT JOIN EtreUneAdresseDeColporteur C
ON A.idAdresse=C.idAdresse
WHERE C.idAdresse IS NULL

Les types de jointure, c'est pour les requêtes (Manipulation des données) avec le type de jointure selon le besoin.

La fenêtre "Relations", c'est pour visualiser les tables&champs, les relations clés primaires/étrangères (Définition des données).

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

[XGuarden]

Selon m recherche dans la fenêtre relation, le type de jointure est lui défini par défaut si aucun est précisé. Il serais peut-être bon d'En définir quelque un par défaut.

Par ailler, j'ai supprimer toute les suppressions en cascade de la base de donnée.
Je réfléchi sur les conséquence des mise-a-jour en cascade présentement.