Discussion :

[Pierre Fauconnier]

Parfait. Du moment que c'est justifié, c'est correct

Ce qu'il faut savoir pour les EDPI, c'est s'ils peuvent être à cheval sur deux départements:

• Non => le lien Commune / département n'a pas lieu d'être;
• Oui => le lien EDPI / Département n'a pas lieu d'être.

Il faut aussi voir si chaque commune est relié à un EDPI ou si des grosses entités sont "autonomes" par rapport aux EDPI. Si des communes peuvent exister sans être reliées à un EDPI et que un EDPI ne peut être relié qu'à un département, il faut conserver les deux liens mais prévoir un mécanisme qui interdit de renseigner les deux clés étrangères en même temps pour une commune car soit elle pointera vers un dpt, soit elle pointera vers un EDPI qui pointera vers un dpt.

Je le redis: Tout dépend des règles de gestion.

[La_Kai]

Un EPCI ne peut pas être à cheval sur plusieurs départements et chaque commune fait partie d'un EPCI, il n'y a pas de commune autonome.
Du coup, on est toujours d'accord, j'ai seulement à supprimer le lien Commune <-> Département, puis que les EPCI font le lien entre les communes et les dpts

[Pierre Fauconnier]

Oui

[La_Kai]

[*]Chargement des tables d'associations.
Une fois toutes tes listes (tables) de référence établies et donc tes clefs primaires connues, tu peux charger les associations.
Évidement cela te prend un moyen de mettre en relation tes clefs avec les données d'origines.
L'idéal (c'est le Graal des informaticien) c'est d'avoir une clef unique (éventuellement composée) qui te permet d'identifier tes enregistrements.
Par exemple : le nom de la commune et son code postal peut te permettre de distinguer les 3 "Foncouverte" qui existent en France.
Généralement je fais ce genre d'exercice en Excel avec un VLookup (RechercheV) en important mes tables de référence dans mes sources Excel et en y "gaussant" mes données.
[/LIST]

A+

Je ne comprends pas ce que signifie "charger les associations".

Je les remets sur Excel et je leur attribue manuellement les valeurs des clés primaires correspondantes ?
J'ai déjà utilisé la fonction RechercheV, mais dans ce cas là, je ne vois pas spécialement comment l'utiliser

Généralement je fais ce genre d'exercice en Excel avec un VLookup (RechercheV) en important mes tables de référence dans mes sources Excel et en y "gaussant" mes données.

A+

Peux-tu éclairer ma lanterne française sur ce que veut dire "gausser" outre-manche ?
Après recherche, j'imagine que cela signifie que tu manipules tes données de manière plus ou moins probantes jusqu'à ce que ce soit bon, c'est à peu près bon ?

[Pierre Fauconnier]

Encore un peu de modélisation.

Normalement, les anciennes communes devraient disparaître de la base, ainsi que les coordonnées des anciennes communes. Dès lors, je suis étonné que les secteurs de piégeage ne pointent pas vers les nouvelles communes.

Pour ce qui est de charger les données en Access avec les "nouvelles clés", je fait le travail en Access plutôt qu'en Excel. Ca évite les aller-retours. Si on sait faire du RECHERCHEV en Excel, on sait le faire en Access.

Donc, je travaille en important d'abord dans Access les tables périphériques. Puis j'importe les tables principales en créant des jointures en Access (comme on ferait avec RECHERCHEV en Excel).

[La_Kai]

Je vais peaufiner et poursuivre ma modélisation (car ce que je vous ai montré n'est qu'un tiers environ de la totalité de la BD), je reviendrais vers vous si j'ai des questions ou simplement pour confirmation.
A ce moment là, j'aurais sûrement besoin d'aide pour les clés étrangères

[Pierre Fauconnier]

[...]
Au niveau esthétique, personnellement j'essaye autant que faire se peut de ne pas "croiser les fils" donc je place mes tables de manière à ce que mes relations (les traits) ne se coupent pas. Je trouve cela plus lisible.
A+

Lorsqu'il y a 50 tables dans le diagramme, ne pas avoir de fils qui se croisent relève de la gageure... Perso, je préfère un diagramme bien conçu avec des fils qui se croisent qu'un diagramme mal conçu sur le plan relationnel mais qu'on pourrait exposer au Louvre

[La_Kai]

Je pense que tu n'as pas tort, ma BD doit tendre vers ça (pas totalement mais presque), c'est l'équivalent de ce que je doit faire mais dans la Manche (elle a été faite l'année dernière), et on ne peut pas vraiment empêcher que ça se coupe :




Sinon, j'ai peaufiné mon organisation au niveau des communes, je vous laisse juger :

[Pierre Fauconnier]

Je sens que je vais faire mon chiant...

Si tu appelles une table xxx_Normandie, tu vas faire quoi quand tu géreras l'étude des destructeurs des bassins versants de la Vendée ou de l'Ardèche? Tu vas créer des tables xxx_Vendée et xxx_Ardèche? De plus, je pense que les bassins versants se foutent de la découpe administrative chère au modèle centralisateur parisien français. J'imagine que le bassin versant du Rhône traverse différentes communes, différents départements et différentes régions.

Garde ton modèle de tables avec une liaison vers le département sans amener une notion "métier" (i.e. Normandie) dans le nommage de tes objets (tables, champs, ...), c'est tout bon. Si après, tu souhaites rattacher les dpts aux 5 régions de France, tu pourras le faire pour étendre ton modèle à l'entièreté de l'Hexagone.

Ce que je voulais souligner dans ma remarque suite au poste de René, c'est que pour moi, l'esthétique du diagramme, ça passe LARGEMENT après sa cohérence technique. Travaille d'abord sur la conception de ton modèle de données. Si, par la suite, tu as du temps à perdre, que tu n'as que ça à foutre de tes soirées et pour autant que ce soit possible, tu essaieras de réaliser un diagramme où les fils ne se croisent pas. Chacun sa marotte

[La_Kai]

Ah oui merde j'ai oublié d'enlever les deux "Normandie", c'était pas voulu, c'est mes feuilles Excel qui se nomment comme ça ^^'

Oui je suis bien d'accord avec toi, j'avais bien saisi que l'esthétique des relations passait après la bonne conception de la BD, il faut toutefois s'y retrouver, mais c'est secondaire

[Pierre Fauconnier]

Dans une base de données relationnelle, toutes les tables sont reliées entre elles (en tout cas les tables "applicatives"). Donc, dans ton modèle, ce n'est pas cohérent d'avoir la table SecteursPiegeage sans liens vers d'autres tables.

Pour la table PersonnelFREDON, je ne peux pas dire, puisque je ne sais pas à quelle réalité elle se rattache.

[La_Kai]

La table SecteurPiegeage est destinée à être reliée à d'autres tables que je vais ajouter par la suite.

Pour la table PersonnelFREDON, c'est pour savoir qui a répondu au téléphone, qui a modifié ou renseigné une information, etc. Je vais sûrement la mettre en relation avec d'autres tables dans le futur.

Autrement dit, les relations que j'ai posté hier ne sont pas figées, je n'en suis qu'à un tiers de mon travail à ce niveau

[La_Kai]

Bonjour bonjour me revoila,

Les tables sont vides mais j'aimerais que vous jetiez un œil à l'organisation générale de ma BD avant que je me lance dans l'importation des tables Excel. Je sais c'est un peu le bordel mais je peux pas trop mieux ranger que ça. C'est plus ou moins rangé par thème, je comprends mon bazar quoi.



N'hésitez pas à proposer des améliorations, je suis tout ouïe.

PS : j'espère que la photo sera assez lisible, sinon vous pouvez la télécharger

Merci d'avance !

[Pierre Fauconnier]

Difficile à dire sans savoir +/- précisément ce que fait l'appli et quelles réalités de terrain tes tables recouvrent...

Perso, je dirais que je trouve étrange que ta table enlevement_Equarissage soit reliée uniquement à la table des points d'enlèvements, mais c'est peut-être très correct.

Au delà, difficile de juger selon moi, sans une analyse plus approfondie de ton appli et du cahier des charges, ce qui sort un peu du cadre des forums, je pense...

[La_Kai]

Je vais revérifier pour la table Enlevement_Equarissage. Sinon, c'est vrai que as raison, j'ai posté mes relations au cas où vous voudriez jeter un coup d'oeil, mais c'est vrai que sans connaître le but et les demandes, difficile de donner son avis

A la prochaine

[Pierre Fauconnier]

Dans la mesure où il n'y a pas de table "Équarrissage", l'appellation "référent équarrissage" me laisse perplexe. Si ton référent équarrissage est bien lié à ton point de collecte, ok, mais alors je l'aurais personnellement appelé "Référent Point de collecte" et pas "référent équarrissage". La terminologie employée devrait normalement ne pas soulever ce genre d'ambiguïtés.

Donc, sans savoir ce que recouvre les terminologies PC_Equarrissage, Référent Equarrissage, Enlèvement Equarrissage et Equarrissage RA (entre autres), difficile de voir si ton modèle de données est correct.

Au passage, et sans vouloir reprendre sur l'orthographe, équarrissage s'écrit avec deux "r"... Je trouve personnellement que c'est gênant dans une nomenclature. Si tu travailles seul sur ton code, ça peut éventuellement passer (quoique), mais si je devais travailler avec toi sur ton appli, j'aurais constamment des erreurs dans mon code et dans mes requêtes SQL à cause de cette faute d'orthographe.

[La_Kai]

Effectivement j'ai oublié un r sur chaque nom de table où il y a Equarrissage, je vais corriger ça.
Oui c'est vrai que tu n'as pas tort, un maximum de clarté est souhaitable, je vais modifier ça aussi.

Merci pour ton apport

[La_Kai]

Bonjour,

J'ai une nouvelle petite question, peut-être quelque peu stupide mais en tout cas ça me bloque.



Comme vous pouvez le voir ci-dessus, j'aimerais créer une table Localite_piegeage et y renseigner dedans les 4 quatre communes différentes sur lesquelles un piégeur peut piéger, voire pourquoi pas rajouter une cinquième pour anticiper un gros piégeur.
Voici mon soucis : évidemment il faut que je créer une relation entre les communes dans la table Localite_piegeage et les communes dans la table Communes, seulement vu que cela me fait créer plusieurs relations en provenance de la même table, il me créé une table Communes1, Communes2, etc.

Avez-vous des idées ?

Encore une fois merci d'avance

[Pierre Fauconnier]

Salut.

Tu as deux solutions, une mauvaise et une bonne.

La mauvaise: Ajouter x champs dans la table des piégeages pour les communes 1, 2, 3,..., x. Tu dois alors ajouter autant de fois la table des communes dans le diagramme et lier les paires "table ajoutée / clé externe".

La bonne: Un principe de base est de considérer la règle suivante: 0 liaison, 1 liaison, une infinité de liaisons... Autrement dit, ne pas limiter les possibilités de liaisons en passant par une liaison "plusieurs à plusieurs". Tu peux ainsi lier les piégeages à plusieurs communes. Les sous-formulaires des deux côtés te permettron de créer les appariements de tes données, par exemple.

[La_Kai]

Autrement dit, je passe par les autres tables pour arriver à mes fins, et j'utilise les sous-formulaires pour afficher les diverses communes où un piégeurs piège ?