[Toutes versions] Aide a la conception d'un modèle de base de données

[XGuarden]

Bonjours, je travail actuellement a la modélisation d'une base de donnée pour colporteur.
Le principe est simple:
Un territoire comprend plusieurs adresse.
Un territoire peut faire parti d'une seul attribution à la fois.
Une adresse peut faire l'objet de plusieurs visite.
Une attribution est faites par un attribueur et est donnée a un colporteur.
Une attribution comprend une date d’émission, une date de retour prévue et une date de retour effective.

En gros ça parait asser simple mais je galère.
Présentement access refuse d'enregistrer mon travail en me fessant l'erreur:
"L'objet défini est incorrecte ou plus défini".
J’espère régler ce problème avant que quelqu'un réponde a ce post.


Mon gros problème est que je suis incapable de faire correctement mes relations. Je suis programmeur et non modeliseur... mon travail m'apporte jamais à travailler sur des bases de données en général.

J'aimerais de l'aide afin de modeliser correctement cette base de donné.

Merci d'avance pour votre aide.

[Richard_35]

Bonjour XGuarden,

Questions complémentaires pour définir les relations :

Un territoire comprend plusieurs adresse.

==> une adresse peut-elle être affectée à plusieurs territoires ?

Un territoire peut faire parti d'une seul attribution à la fois.

> "à la fois" n'existe pas, en terme de relation.
==> un territoire peut-il avoir plusieurs attributions ?
==> une attribution peut-elle avoir plusieurs territoires ?

Une adresse peut faire l'objet de plusieurs visite.

==> Une visite peut-elle concerner plusieurs adresses ?

Je te suggère de régler ces 3 points avant de passer aux suivants.

[XGuarden]

Merci de ta participation, pour te répondre:

une adresse peut-elle être affectée à plusieurs territoires ?

Non, c'est une impossibilité total.

> "à la fois" n'existe pas, en terme de relation.
==> un territoire peut-il avoir plusieurs attributions ?
==> une attribution peut-elle avoir plusieurs territoires ?

Non un territoire ne peut pas avoir plusieurs attribution, mais une fois que le territoire est terminé, il peut être de nouveau attribuer. Exemple: Un territoire qui est visité une fois par année. Il n'est jamais attribué a plus d'un territoire mais une fois retourner il peu faire parti d'une nouvelle attribution. J’espère être clair.

Une visite peut-elle concerner plusieurs adresses ?

Non, une visite ne concerne qu'une adresse. La table visite sert en fait a garder en mémoire les visite passé. Utile pour déterminer le nombre de fois que l'adresse a été visité dernièrement.

Merci de ton aide

[XGuarden]

Pour tenter d’être le plus précis possible, je vais tenter d'expliquer la situation.

Le programme va servir a gerrer un service bénévole de colporteur.

Des responsable nommé s'occupe d'attribuer un territoire a un colporteur.
Un colporteur bien entendu peut s'occuper de plusieur territoire à la fois. (ainsi il n'a pas a revenir constamment pour en chercher un autre.

Les responsables est lui même un colporteur. (Donner l'exemple)
Un territoire ne peut se fait attribuer que par un seul responsables a la fois.
Durant tout le temps ou un territoire est attribué, il ne peut etre attribuer de nouveau. Les responsables désire pouvoir a l'aide de requêtes savoir par exemple la liste de tout les territoire attribué au courant de la dernière année par chacun des responsables. Pareillement, la basse de donnée dois être concu de sorte qu'il est possible de faire la liste de tout les territoire qui ont été attribué a une personne au cour de l'année. Une personne peut se faire attribuer le même territoire plus d'une fois.

Un territoire est composé de plusieurs adresse(porte). Une adresse ne fait parti que d'un seul territoire. Aucune adresse ne fait parti de deux territoires.

Un adresse comporte liste des dates des visite effectué dans le passé de sorte a s'assurer que celle-ci est ni faite trop souvent ni pas suffisamment.

Bien entendu, une adresse peu ne jamais avoir été attribué(au début du projet).

Pour ce qui est des attribution, elle est toujours faites par un et un seul responsable, pour une duré déterminé a un et un seul colporteur.

Une fois le territoire terminé, le colporteur remet sa "fiche de territoire" et le responsable peu alors marqué le territoire comme terminé en attendant une futur attribution. Un autre Responsable peut décider d'attribuer alors ce territoire a n’importe quel colporteur. Mais encore une fois durant tout le temps ou le territoire est attribué, il ne peut être sujet a un autre attribution.

[Chtulus]

Bonjour XGuarden,

Comme tu connais déjà tes contraintes, je te conseil de lire déjà ce très bon article de SQLpro.

Tout y est dit, c'est très bien pour les personnes qui n'ont jamais modélisé

[XGuarden]

Je susi en trein de lire l'article. J'ai déja modélisé mais ca date... Ces surtout pour ne rien oublier que j'ai besoins d'aide et sur le choix des relations. Présentement toute mes table un une clé primaire et il me semble que ca ne devrais pas etre le cas.

[Richard_35]

Bonjour XGuarden et Chtulus,

En fonction de tes réponses, les premières relations devraient être les suivantes :

*** 1er point ***

Un territoire comprend plusieurs adresse.
une adresse peut-elle être affectée à plusieurs territoires ?
==> Non, c'est une impossibilité total.

Territoire :
retirer le champ Adresse.
Adresse :
ajouter le champ NoTerritoire.

Territoire 1--->N Adresse, via NoTerritoire.
*** fin 1er point ***


*** 2ème point ***

Une adresse peut faire l'objet de plusieurs visite.
Une visite peut-elle concerner plusieurs adresses ?
==> Non, une visite ne concerne qu'une adresse.

Visite :
ajouter le champ NoAdresse (N°).

Adresse 1--->N Visite, via NoAdresse.
*** fin 2ème point ***

*** 3ème point ***
D'après ce que je comprends, Attribution = Responsable, non ?
*** fin 3ème point ***

Règlons ces 3 points avant de passer à la suite, STP.

[XGuarden]

Richard_35 j'ai corrigé les points que tu a mentionner et je vais ajouter une capture d'écran. Par contre ton troisième point me laisse perplexe.

*** 3ème point ***
D'après ce que je comprends, Attribution = Responsable, non ?
*** fin 3ème point ***

En fait non, Une attribution est faite par un responsable a un colporteur pour un territoire donnée.

C'est impossible de fusionner attribution et responsable dans la même table.

-Un responsable peut faire plusieurs attribution différente.
-Une attribution est faite pour un colporteur a la fois.

Je ne suis pas actuellement certain si une attribution doit pouvoir être faite pour plusieurs territoire ou non. Par exemple un colporteur peut se faire attribuer plusieurs territoire a la fois mais je ne suis pas sur si c'est considéré comme une nouvelle attribution ou bien une mise a jour d'une attribution existante.

[XGuarden]

Voici la dernière capture d'écran de mon modèle.
Bon je dois dire qu'il y a pas mal de truc qui semble se répéter.
De plus, un responsable est également un proclamation.
Une personne ne peut-être responsable si elle n'est pas proclamation(colporteur).

[Richard_35]

Bonjour XGuarden,

Eh bien, le problème est que tu emploies des termes qui sont absents de la fenêtre "Relations".
Donc,

proclamation(colporteur).

proclamateur = colporteur, si j'ai bien compris. Peut-être faudrait-il appeler la table "Proclamateur" => "Colporteur", ou parler de "proclamateur" dans tes posts, et non de "colporteur".

Pour le 3ème point, il me semble avoir compris : la table "Attribution" est faite pour gérer les relations N<--->N entre "Responsable" et "Proclamateur" pour un territoire donné. En cela, la relation indiquée est OK.

*** 4ème point ***
Effectivement :

De plus, un responsable est également un proclamation.
Une personne ne peut-être responsable si elle n'est pas proclamation(colporteur).

Responsable :
supprimer les champs communs avec Proclamateur.
Responsable 1--->1 Proclamateur, via No.
Note : je pense qu'il est bon de garder la table "Responsable" au cas où, par la suite, tu aurais besoin de champs spécifiques aux responsables et non aux proclamateurs (par exemple, la date de passage en "responsable" d'un proclamateur). De ce fait, la table "Proclamateur" ne sera pas poluée par ces informations et tu ne seras pas obligé d'efectuer des tests "responsable oui/non".
Si tu n'es pas de mon avis, tu peux supprimer la table "Responsable" et ajouter un champs "responsable" de type Oui/Non (case à cocher) dans la table "Proclamateur".
*** fin 4ème point ***

*** 5ème point ***

Je ne suis pas actuellement certain si une attribution doit pouvoir être faite pour plusieurs territoire ou non. Par exemple un colporteur peut se faire attribuer plusieurs territoire a la fois mais je ne suis pas sur si c'est considéré comme une nouvelle attribution ou bien une mise a jour d'une attribution existante.

ATTENTION : c'est fondamental à préciser !
Il s'agira, en fait de gérer une relation N<--->N entre "Attribution" et "Territoire" via une table de liaison comportant les deux clés primaires de ces tables.
*** fin 5ème point ***

Je te propose :

• de régler ces 4ème et 5ème points ;
• de modifier les relations en conséquence ;
• de poster les nouvelles relations.

==> pour passer à la suite.

[f-leb]

bonjour à tous,

J’ai également quelques points à faire remarquer

En l’état, à partir d’une DateVisite, il n’est pas facile de remonter jusqu’au colporteur qui effectue la visite.
Visite→Adresse→Territoire
Puis comme un territoire peut faire l’objet de plusieurs attributions, il faut encore faire des comparaisons de dates pour remonter :
Territoire→Attribution, et enfin, Attribution→Colporteur

Je propose de rajouter une relation :
Visite-∞------1-Attribution

Il faudra s’assurer lors d’une insertion de visite que l’adresse fait bien partie du territoire de l’attribution (avec Access 2010 d'après ta copie d'écran, on peut (on doit) faire ça avec un évènement de table).

Envoyé par XGuarden

Durant tout le temps ou un territoire est attribué, il ne peut être attribué de nouveau.

Je verrais bien une table supplémentaire : Periode(idPeriode, DateAttribution, DateRetourPrevue)
Attribution-∞------1-Periode

(DateRetourEffectif restant dans la table Attribution)

Dans la table Attribution, penser à mettre un index "unique" (ou clé primaire) sur le couple {idPeriode, idterritoire}.
Il faudra encore programmer une contrainte pour éviter un chevauchement de périodes attribuées sur un même territoire.

[XGuarden]

Bon j'ai lu les points que tu a mentionné. J'ai us un peu de difficulté a comprendre certain point et ne me demande bien comment tu fais pour faire des citation, c'est tellement clair =:0)

Pour Richard_35:

Colporteur = proclamateur. La raison d'utilisation du mot proclamateur est simplement pour être plus exacte. Par définition un colporteur vent des choses.
L'utilisation du mot solliciteur n'est pas exacte aussi puisqu'il ne demande rien. Donc le mot exacte est proclamateur. Mais puisque plusieurs ne sont pas familier avec ce terme, j'utilise le mot colporteur puisque c'est plus facile a comprendre le rôle de la personne. J’espère avoir bien expliquer cette ambiguïté.

Citation:
Pour le 3ème point, il me semble avoir compris : la table "Attribution" est faite pour gérer les relations N<--->N entre "Responsable" et "Proclamateur" pour un territoire donné. En cela, la relation indiquée est OK.

Je ne suis pas sur de te suivre mais si je comprend bien ce n'est pas exacte.
La table "attribution" sert plutôt a gérer des relations N<--->N entre Responsable et Territoire. Le proclamateur n'est que la personne qui est attribué pour faire ce territoire.

*** 4ème point ***
Je suis de ton avis et je fais le changement sur le champs.
Par contre étant donné que selon la logique utilisé dans cette oeuvre de bien fesance:

-Seulement les personnes résidant sur un des territoires existant peuvent se faire attribuer un territoire.

Il est donc logique de conclure que tout les proclamateur et par conséquent les responsables aussi réside dans des adresses de certains territoires existants.

Par conséquent je me demande s'il serait pas bon de soit créer un table seulement pour les adresse ou bien de créer un lien qui lie les adresse au proclamateurs(colporteur) libérant ainsi la table proclamateurs de plusieurs éléments. En mettant par exemple un ID dans proclamateur correspondant a une adresse. Par contre il ne faut pas oublier qu'une personne peu changer d'adresse a tout moment.

*** 5ème point ***
Pour être honnête je n'ai pas vraiment compris ce que tu voulais dire.
Je vais donc expliquer plus profondément ce que je voulais dire:

Un proclamateur peut se faire attribuer plus d'un territoire.

Je me demandais donc s'il s'agit d'une relation 1-N entre attribution et territoire.

Mais puise qu'il est possible qu'un proclamateur remette sa fiche pour un territoire complété alors que celui-ci a reçu plus d'une attribution, je crois qu'il serait préférable de dire:

-une attribution n'est faite que sur un seul territoire.
-un proclamateur peut recevoir plusieurs attribution(et par conséquent plusieurs territoire)


Maintenant pour f-leb:

Tu ma perdu avec les évènements de table. C'est nouveau a Access 2010 je crois.

En l’espèce, il peut y avoir plusieurs visite a plusieurs adresse différente par le même proclamateur ou des proclamateurs différent a la même date.

La date de visite ne sera jamais appelé à être appelé directement, c'est non pertinent sauf pour faire une requête afin de voir tout les adresses qui ont été visité pour une période donné.

Pour ta citation "Puis comme un territoire peut faire l’objet de plusieurs attributions"

En fait je ne sait pas trop comment expliquer cela, en simple:
Un territoire ne fera jamais parti de plus d'une attribution a la fois.
Quand un territoire est attribué, il ne peut pas être de nouveau attribué tant qu'il ne sera pas retourné.

Je ne sait pas trop comment exprimer cela sous forme de relation.

Pour ce qui est de:
Je propose de rajouter une relation :
Visite-∞------1-Attribution

Je ne sis pas sur de comprendre l'avantage.
Certe une attribution comporte plusieurs visite
et une visite n'est faite que durant une attribution.
S'il y a une nouvelle visite a la même adresse il ne s'agira quand même pas de la même visite donc tu a raison. Mais ça ne risque pas de former des relations en rond dans mon modèle?

citation:
Il faudra encore programmer une contrainte pour éviter un chevauchement de périodes attribuées sur un même territoire.

Je crois que c'est au niveau de la programmation effectivement qu'il ne faut pas donne a l'utilisateur l'option d'attribuer un territoire s'il l'est déjà.

citation:
Je verrais bien une table supplémentaire : Periode(idPeriode, DateAttribution, DateRetourPrevue)
Attribution-∞------1-Periode

Je vais examiner cette possibilité et te revenir avec ça.

Je vais reposter les modifications bientôt. Je vais peut-être dormir avant par contre.
Encore une fois merci beaucoup pour votre aide.

[Richard_35]

Il y a beaucoup de choses... c'est pour cela qu'il me semblait nécessaire de segmenter : clore un ou plusieurs points (tables de base) pour passer à d'autres (processus).

Je te remercie de tes explications très intéressantes. Mais il faut, malgré tout, utiliser les mêmes termes dans les posts et dans les Relations, pour éviter de passer par la case "traduction" (cela fait gagner du temps).

*** 3ème point ***

La table "attribution" sert plutôt a gérer des relations N<--->N entre Responsable et Territoire. Le proclamateur n'est que la personne qui est attribué pour faire ce territoire.

Tu as parfaitement raison mais, j'ajouterai : "les deux, mon général !". En effet, la table "Attribution" sert à gérer les relations N<--->N entre un "Responsable" et un couple "Territoire"/"Proclamateur" (les deux clés sont stockées).
*** fin 3ème point ***

*** 4ème point ***
Ce point semble reglé.
*** fin 4ème point ***

*** 4ème point BIS ***

Par conséquent je me demande s'il serait pas bon de soit créer un table seulement pour les adresse ou bien de créer un lien qui lie les adresse au proclamateurs(colporteur) libérant ainsi la table proclamateurs de plusieurs éléments. En mettant par exemple un ID dans proclamateur correspondant a une adresse. Par contre il ne faut pas oublier qu'une personne peu changer d'adresse a tout moment.

C'est une bonne idée : tu abordes, là, la gestion des adresses (classique). Il faut, d'abord, déterminer si tu veux conserver l'historique des adresses successives.
*** fin 4ème point BIS ***

*** 5ème point ***

Je me demandais donc s'il s'agit d'une relation 1-N entre attribution et territoire.

==> Non, non, surtout pas... (voir en fin de point).

-une attribution n'est faite que sur un seul territoire.
-un proclamateur peut recevoir plusieurs attribution(et par conséquent plusieurs territoire)

==> c'est le cas avec les relations actuelles.

La question que tu évoquais :

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

est celle de savoir si "une attribution doit pouvoir être faite pour plusieurs territoire" sous le même numéro d'attribution.
*** fin 5ème point ***

[XGuarden]

Envoyé par f-leb

bonjour à tous,

J’ai également quelques points à faire remarquer

En l’état, à partir d’une DateVisite, il n’est pas facile de remonter jusqu’au colporteur qui effectue la visite.
Visite→Adresse→Territoire
Puis comme un territoire peut faire l’objet de plusieurs attributions, il faut encore faire des comparaisons de dates pour remonter :
Territoire→Attribution, et enfin, Attribution→Colporteur

Je propose de rajouter une relation :
Visite-∞------1-Attribution

Il faudra s’assurer lors d’une insertion de visite que l’adresse fait bien partie du territoire de l’attribution (avec Access 2010 d'après ta copie d'écran, on peut (on doit) faire ça avec un évènement de table).


Je verrais bien une table supplémentaire : Periode(idPeriode, DateAttribution, DateRetourPrevue)
Attribution-∞------1-Periode

(DateRetourEffectif restant dans la table Attribution)

Dans la table Attribution, penser à mettre un index "unique" (ou clé primaire) sur le couple {idPeriode, idterritoire}.
Il faudra encore programmer une contrainte pour éviter un chevauchement de périodes attribuées sur un même territoire.

J'ai annalisé ce que tu a dit, mais je ne comprend pas en quoi l'ajout d'une table Période aiderais. Ca ne ferait pas que rendre le tout plus compliqué?

[XGuarden]

Voici ma base de donné actuellement. Je continue d'essayer d’intégrer ce que vous m'avez conseiller mais j'avoue que je galère.

Je ne suis pas trop sur comment séparer les informations d'adresses.
Si je cré un lien entre proclamateur et adresse, j’obtiens en double les nom et prénom. Si je garde dans proclamateur uniquement un ID d'adresse, ca risque de ne pas être évident pour faire des requetes...

Pour ce qui est de la relation entre Responsable et Proclamateur, je rencontre un petit problème actuellement. Je n’arrive pas a faire une relation 1-1. Je suis actuellement a le recherche sur google d'une solution. Pour les autres petit problème que vous m'avez mentionner je suis la dessus également.

Merci encore de votre aide =:0)

[XGuarden]

Une autre mise-à-jour.
Je me demande si j'améliore ou si je suis en trein de foirer ma base de donnée lol.

[f-leb]

Bon, je reprends à zéro…

Une adresse est caractérisée par Nom, prenom, telephone, rue, etc et appartient à un territoire.
Un territoire comporte plusieurs adresses.

Une adresse peut être celle d’un colporteur. L’adresse d’un colporteur est alors caractérisée par des attributs supplémentaires (par exemple courriel, DateEmbauche, diplôme, etc).

Une attribution concerne un territoire et un seul. 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).

Une attribution comporte un responsable qui est lui-même un colporteur.
Une attribution est confiée à un colporteur (différent du responsable ?!).

Tous les colporteurs peuvent avoir plusieurs attributions.

En mettant de côté les visites pour l’instant, je propose le schéma :


Concernant les visites, je reprends ton schéma :
Visite-∞------1-Adresse

Je reviens sur ce que j’ai signalé plus haut : comment tu remontes au colporteur qui a effectué la visite ?

[XGuarden]

Tu a vraiment tout compris a 100%. Pour ta question:

"Une attribution comporte un responsable qui est lui-même un colporteur.
Une attribution est confiée à un colporteur (différent du responsable ?!)."

Un responsable peu s'attribuer a lui même un territoire. Ça ne cause aucun problème et ça l'arrive effectivement.

Pour ton schéma, il est logique et me permet en effet de corriger mon schéma.

Par contre il reste un point sur lequel je suis septique: Le nom donné au table...
Je plaisante lol.
C'est le choix de la création de deux tables d'adresse.
SI je veux faire une requêtes pour faire sortir la liste de tout les colporteur je n'imagine même pas la requêtes puisque les responsable sont aussi des colporteurs.

Pour ta question sur la requête, j'imagine que je serait obliger de formuler une hyper longue requêtes... Cela dit, l'ajout d'une relation comme tu la proposé risque pas de causer des problèmes a la base de donnée? Ca semble un peu circulaire si j'ajoute une relation.

[XGuarden]

J'ai apporté une correction afin de m'adapter a tes propositions. Mon modèle sait beaucoup améliorer par contre la duplication des info proclamateur et responsable me semblait étrange et j'ai essayer quelque chose. Dit moi ce que tu en pense. Je dois admettre par contre que je réalise qu'une adresse peu avoir plus qu'un répondant dans la réalité des faits.... mais que l'ajout d'une table répondant bouzierait la relation adresse proclamateur(du moins de la façons que je l'imagine.)

Également, pour ce qui est des visites, étant donné qu'il n'y a pas toujours de visite, çà ne pose pas problèmes qu'il y ait un lien possible avec proclamateur.

En effet, il est très possible qu'une maison ne soit pas visiter étant donné qu'elle est la maison d'un proclamateur.

[f-leb]

Envoyé par XGuarden

Un responsable peut s'attribuer a lui-même un territoire. Ça ne cause aucun problème et ça arrive effectivement.

Donc tout va bien puisque rien n’empêche d’avoir idResponsableColporteur=idColporteur dans ma table AttributionTerritoire.

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

Schéma qui correspond aux règles de gestion :
Une adresse peut être une adresse de colporteur
Une adresse de colporteur est une adresse.

Adresse :

Code :

1
2
3
4
5
idAdresse    Nom          Prenom   idTerritoire  …
   1         Dubois       Paul         1
   2         Dupont       Jacques      2
   3         Durand       Pierre       1
   4         Duchemin     François     2

EtreUneAdresseDeColporteur :

Code :

1
2
3
idAdresse     courriel                   DateEmbauche  …
  1           Paul.Dubois@machin.fr      14/02/2005
  4           FDuchemin@truc.fr          18/07/2008

Les adresses 1 et 4 sont des adresses de colporteurs puisqu’on retrouve leurs identifiants dans EtreUneAdresseDeColporteur.
Comme ils sont des colporteurs, ils ont droits à des attributs supplémentaires (courriel, Date d’embauche, etc ce que tu veux).

Les adresses 2 et 3 ne sont pas des adresses de colporteurs puisqu’on ne retrouve pas leurs identifiants dans EtreUneAdresseDeColporteur. Ce sont donc des adresses à visiter a priori.

Envoyé par XGuarden

SI je veux faire une requête pour faire sortir la liste de tous les colporteurs je n'imagine même pas la requête puisque les responsables sont aussi des colporteurs.

Les colporteurs sont ceux dont l’identifiant existe aussi dans EtreUneAdresseDeColporteur :

Code sql :

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

Les adresses à visiter sont celles dont l’identifiant n’apparaît pas dans EtreUneAdresseDeColporteur (un colporteur ne visite pas un autre colporteur en principe) :

Code sql :

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

Rien de bien méchant avec les assistants Requête…

Envoyé par f-leb

Concernant les visites, je reprends ton schéma :
Visite-∞------1-Adresse

Je reviens sur ce que j’ai signalé plus haut : comment tu remontes au colporteur qui a effectué la visite ?

C’est pour ça que je proposais un chemin plus court : Visite-∞------1-AttributionTerritoire
selon la règle de gestion : "une visite est effectuée dans le cadre d’une attribution".

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.


C’est quoi "langue" ?