Discussion :

[Pierre Fauconnier]

[...]il arrive souvent (en tout cas à moi) qu'on transfert des données dans Excel[...]

MS Query et [EDIT] Power Query [/EDIT] permettent de récupérer ces données sans perte du 0. C'est une question d'outils et de capacité à les manipuler, à la base. Normalement, depuis 2007, on ne devrait jamais importer des données dans des feuilles "vides" et donc, dont les colonnes ne sont pas formatées.

Beaucoup (trop) de questions viennent sur nos forums suite à une mauvaise conception des feuilles de calcul ou des bases de données, ou à la suite d'une méconnaissance des outils qui permettent aux applications de communiquer entre elles. On peut choisir de faire l'impasse sur cet aspect des choses, mais on se prépare des réveils douloureux.

Lorsque je vois une base de données où une pléthore de champs "OUI/NON" remplacent une architecture m:n sur base de trois tables, je frémis quand même un peu. Bien concevoir une relation m:n, c'est quelques minutes... Maintenir une base mal torchée, ce sont des heures et des heures de sueur avec in fine, une base mal torchée.

je ne vais pas me faire des amis, mais je pense qu'il y a une limite, tout de même...

[marot_r]

Bonjour Pierre.

Hélas nous vivons dans un monde imparfait avec pleins de gens imparfaits qui essayent simplement de faire de leur mieux ... même si comme a dit un chanteur "parfois ton mieux n'est pas assez".

"Poqer Query" ? Qu'est-ce ? Jamais entendu parlé.

A+

[La_Kai]

Lorsque je vois une base de données où une pléthore de champs "OUI/NON"[/URL] remplacent une architecture m:n sur base de trois tables, je frémis quand même un peu. Bien concevoir une relation m:n, c'est quelques minutes...

Qu'est-ce que tu appelles une relation m:n ? Car dans la base que je dois transposer sur Access, il y a quelques colonnes avec des oui/non, peut-être que je pourrais améliorer cela avec ce dont tu parles ?

Power Query, non ? (j'ai peut-être enfoncé une porte ouverte)

[marot_r]

Bonjour je pense que c'est une relation 1 à N ou N à N soit de 1 à plusieurs (ex : client <-> commandes) ou de plusieurs à plusieurs (ex : commandes <-> produits).

Si tu as plusieurs champs en oui/non, tout dépend de ce qu'ils représentent.

Par exemple si tu as EstActif, EstEnCouleur et EstInterne ces 3 champs correspondent sans doute à des propriétés de ton élément et donc sont à mettre dans l'enregistrement.

Par contre si tu as EstVert, EstRouge et EstBLeu et qu'un élément puisse être vert, bleu et rouge en même temps, il est probable que tu doives plutôt faire une association entre ton élément et une table des couleurs avec une structure du type.
tblElement
ClefElement

tblCouleur
ClefCouleur

tblAssElementCouleur
ClefAssElementCouleur (optionel mais souvent pratique).
ClefElement
ClefCouleur

Enfin Par contre si tu as EstVert, EstRouge et EstBLeu et mais qu'un élément ne puisse être que vert ou bleu ou rouge mais pas 2 couleurs en même temps, il est probable que tu doives plutôt faire une association entre ton élément et une table des couleurs avec une structure du type.

tblElement
ClefElement
ClefCouleur

tblCouleur
ClefCouleur

Il arrive souvent que ces champs booléens soit utilisés comme cela pour des raisons d'interface, le développeur veut que l'utilisateur puisse cocher ses choix directement mais cela pose pas mal de soucis après pour exploiter efficacement les données. Donc si on peut on évite et si on ne peut pas on met en place des solutions (ex : table de saisie temporaire, sous-formulaires avec table pré-remplie, ...) pour qu'au final on se retrouve avec une "belle" structure de données sans pour autant entraver les utilisateurs.

En matière de conception il n'y a pas vraiment de mauvaise solution il y a par contre des solutions plus ou moins adaptées aux contraintes présentes et si possible futures.

A+

[Pierre Fauconnier]

Une relation 1:n (1 a plusieurs) signifie que plusieurs enregistrements d'une table peuvent pointer vers un seul d'une autre table. C'est le cas de l'article lié à une catégorie. Plusieurs articles peuvent être liés à une même catégorie, mais chaque article n'a qu'une catégorie.

Dans cette autre discussion, j'ai modélisé une relation 1:n avec les types de catégories et une relation de plusieurs à plusieurs (m:n) dans le cas d'adhérents pouvant s'inscrire à plusieurs programmes. Cette relation passe par une table intermédiaire qui va permettre cette relation m:n grâce à deux relations 1:n. Dans ce cas-ci, j'ai mis une clé primaire composite sur les deux clés externes pour empêcher des doublons dans les inscriptions.

[...]
En matière de conception il n'y a pas vraiment de mauvaise solution il y a par contre des solutions plus ou moins adaptées aux contraintes présentes et si possible futures.[...]

Je m'inscris en faux contre cette affirmation. Je pense pour ma part qu'il y a beaucoup de (très) mauvaises solutions, et qu'il n'y en a que une ou deux, jamais plus, qui sont défendables.

[...]
tblAssElementCouleur
ClefAssElementCouleur (optionel mais souvent pratique).
ClefElement
ClefCouleur[...]

Perso, j'ajoute la clé tblAssElementCouleur dans le cas ou les doublons d'associations sont permis. Si les doublons sont interdits comme dans la base que j'ai illustrée, je mets alors une clé composite sur les clés externes. C'est bien plus pour respecter les règles de gestion que pour le côté pratique que l'on met une clé primaire simple ou une composite

[marot_r]

Bonjour.

Pour la partie "pratique" de la clef dans l'association, perso je la met car j'ai assez souvent des cas

• où mon association devait être unique et une des clef était inconnue au moment de la création de l'enregistrement d'association.
  Quand on défini une clef unique composée on ne peut pas créer l'enregistrement.
  Donc j'utilise une clef primaire autonum ET un index unique composé des 2 clefs étrangères.
• et plus rarement où il m'était pratique de retrouver l'élément sans devoir me référer à l'une ou l'autre des clefs étrangères.

Accessoirement, et je sais que c'est un détournement de fonction, utiliser une clef autonum incrémental permet de savoir dans quel ordre les données ont été entrées ce dont je me suis servi quelque fois pour faciliter la saisie.

J'avoue que depuis que je suis au Québec, ça fait 20 ans maintenant, je suis plus pragmatique dans mes approches : la BD répond au besoin du client et fonctionne ? Oui, alors c'est bon.
L'architecture et les tables sont tout croches et mal montées ? OK, on va vivre avec et rectifier autant que faire ce peu et tant pis si on ne respecte pas quelques "dogmes" au passage.

A+

[Pierre Fauconnier]

Salut René,

Pour le pragmatisme, je suis d'accord. Sur une base "en prod", on fait ce qu'on peut et on n'a pas toujours le loisir de remettre d'équerre. Mais ici, il s'agit de créer une base Access sur base d'Excel, donc autant faire les choses bien dès la conception de la base


Pour l'histoire de la clé primaire composite ou de l'index composite, c'est, comme toujours, une question de règle de gestion, la conception de la base devant normalement suivre ces règles "au plus près"...
Mais c'est chouette que tu aies parlé de l'index composite car cette possibilité n'est pas toujours connue des utilisateurs d'Access, or elle peut rendre de grands services...

[La_Kai]

Bonjour à tous, me revoilà pour de nouveaux questionnements,

Je suis (enfin) en train d'élaborer la véritable structure de ma BD Access, voici ce que j'ai commencé à faire :



Je suis à peu près confiant sur la plupart des relations, sauf la partie entourée en bleu. En fait, je travaille avec et les communes actuelles (dont les communes nouvelles post-2017) et les anciennes communes. Pour cela je dois donc conjuguer ces deux tables Access mais je ne suis pas du tout sûr de mon coup... auriez-vous des suggestions ?

En outre, comme vous le savez sûrement, j'importe des fichiers en provenance d'Excel, par conséquent les clés primaires s'incrémentent automatiquement à l'importation de la feuille Excel vers Access. Sauf que les clés primaires ne s'incrémentent pas dans les tables avec les clés étrangères (en gros : je pose les relations mais les cellules des tables étrangères restent vides). Sauriez-vous pourquoi ?

Encore une fois je débute dans Access, je me fais aider par certaines connaissances mais j'ai toujours des lacunes persistantes ^^'

Merci d'avance,

[marot_r]

Bonjour.

Merci d'avoir posté ton modèle de données, ça aide beaucoup.

Au niveau des tables,

• je vois Coord_ACommunes et Coords_Communes, pourquoi 2 tables qui semblent avoir les même champs ?
  Habituellement si on a les mêmes champs pour des choses "qui ont avoir" on préférera ajouter une table des types et avoir un code de type (ou une clef).
  Ici on pourrait peut-être avoir
  tblTypeCommune
  ClefTypeCommune
  NomTypeCommune (Nouvelle, Ancienne ou Avant2017, Apres2017).
  
  tblCommune
  ClefCommune
  ClefTypeCommune
  Autre info
  
  Ou alors seulement un champ booléen EstAvant2017 dans la table des communes. Il y a peu de chance qu'on revoit les communes avant un bout de temps selon moi :-).
  
• Pourquoi tu as une table pour les anciennes communes et pour les nouvelles ?
  Est-ce que les anciennes communes sont toutes dans les nouvelles ?

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+

[Pierre Fauconnier]

Salut.

Je ne sais pas ce que sont les EPCI, mais ça me semble bizarre que les communes pointent vers les dpts et les EPCI et que les EPCI pointent vers les départements. Ca voudrait dire que tu permets à une commune de pointer vers un autre département que celui vers lequel pointe le EPCI vers lequel pointe la commune.

[La_Kai]

Salut.

Je ne sais pas ce que sont les EPCI, mais ça me semble bizarre que les communes pointent vers les dpts et les EPCI et que les EPCI pointent vers les départements. Ca voudrait dire que tu permets à une commune de pointer vers un autre département que celui vers lequel pointe le EPCI vers lequel pointe la commune.

Les EPCI sont les Etablissement Publics de Coopération Intercommunales. Pour faire plus simple, ce sont les intercommunalités.

Je pense voir ce que tu veux dire, il suffirait donc que j'enlève la relation entre les communes et les départements pour supprimer ce problème ?

[Pierre Fauconnier]

une base de données, c'est la théorie des ensembles.

Si les départements englobent les EPCI qui englobent les communes, alors il ne faut pas de lien entre la commune et le département, puisque l'on pourra déduire le département d'une commune grâce à son EPCI... Ne sachant pas ce qu'est un EPCI, je ne sais pas modéliser, mais je peux dire que tu as de très fortes chances d'avoir des incohérences dans ta base. Par exemple, d'avoir une commune qui pointe vers l'Ardèche et en même temps vers un EPCI qui pointe vers le Calvados.

[marot_r]

Bonjour.

En outre, comme vous le savez sûrement, j'importe des fichiers en provenance d'Excel, par conséquent les clés primaires s'incrémentent automatiquement à l'importation de la feuille Excel vers Access. Sauf que les clés primaires ne s'incrémentent pas dans les tables avec les clés étrangères (en gros : je pose les relations mais les cellules des tables étrangères restent vides). Sauriez-vous pourquoi ?

La relation n'implique pas que la donnée va être copiée (oui moi aussi ça m'a surpris les 1er temps). Il faut que tu le fasses toi-même au moment du chargement.

Habituellement voilà comment on procède :

1. Chargement des tables de références.
   Cela va pour chaque élément te donner sa clef primaire.
2. 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.
   
   On peut aussi importer les données dans des tables temporaires et faire le travail avec des requêtes Access.
   Si tu vas avec cette solution je recommande de faire une base à part (liée à tes tables de prod) pour cela qui ne va faire que le chargement et qu'on jettera après.
   Ça évite de devoir nettoyer la BD principale de tout un tas de truc qui ne serviront qu'une seule fois.
   On peut aussi gardrer les données dans Excel si tu ne veux pas t'embêter avec des tables temporaires.

A+

[La_Kai]

une base de données, c'est la théorie des ensembles.

Si les départements englobent les EPCI qui englobent les communes, alors il ne faut pas de lien entre la commune et le département, puisque l'on pourra déduire le département d'une commune grâce à son EPCI... Ne sachant pas ce qu'est un EPCI, je ne sais pas modéliser, mais je peux dire que tu as de très fortes chances d'avoir des incohérences dans ta base. Par exemple, d'avoir une commune qui pointe vers l'Ardèche et en même temps vers un EPCI qui pointe vers le Calvados.

Il suffit donc de supprimer le lien entre les départements et les communes ?

[Pierre Fauconnier]

Je suppose que oui, mais je repète que je ne sais pas ce qu'est un EPCI... Si tu m'en disais plus?

Si toute commune est liée à un EPCI et que tout EPCI est lié à un département, tu peux probablement supprimer le lien entre Commune et Département.

La modélisation d'une base de données dépend des données ( truisme...) et des règles qui président à leur gestion. Tant que je ne connais pas la donnée (EPCI) ni les règles qui lient une commune à un département et le EPCI à une commune et un département, je ne pourrai rien affirmer.

[La_Kai]

Les EPCI sont les Etablissement Publics de Coopération Intercommunales. Pour faire plus simple, ce sont les intercommunalités.

Ce sont les intercommunalités, je ne sais pas dans quel département tu habites, mais par exemple dans le Calvados, où je réside, il y a 16 intercommunalités/EPCI, ces EPCI regroupent un certain nombre de communes en leur sein. L'intercommunalité de Caen La Mer regroupe 48 communes qui se trouvent tout autour de Caen.
https://fr.wikipedia.org/wiki/Caen_la_Mer

Est-ce que tu y vois un peu plus clair ?

Pour te resituer par rapport à ma BD, j'ai besoin des EPCI tout d'abord car elles permettent un affinage géographique, mais également car la BD est découpée en secteurs, qui tantôt suivent un découpage par rapport aux Bassins Versants, tantôt aux intercommunalités.

Un bassin versant représente l'espace géographique drainé par un cours d'eau, comme la BD porte sur les piégeurs de rongeurs aquatiques dans le Calvados (Normandie), ces bassins versants sont parfois utilisés pour délimiter un secteur de piégeage.

[Pierre Fauconnier]

J'habite en Belgique => pas de départements, mais administrativement, c'est au moins aussi compliqué... On a les politiques qu'on mérite (me demande ce qu'on a bien pu faire pour mériter ces nullités, mais passons)...

Si chaque commune est liée une intercommunalité et dans la mesure où je suppose qu'une intercommunalité ne peut pas être à cheval sur deux départements, le lien Commune / Département n'a pas lieu d'être et peut être supprimé, ainsi que la clé étrangère qui pointe vers le département dans la table des communes. Tu pourras déduire le département en passant par son intercommunalité.

[Pierre Fauconnier]

[...]comme la BD porte sur les piégeurs de rongeurs aquatiques dans le Calvados (Normandie)[...]

Si la BD ne porte que sur le Calvados, est-ce utile d'utiliser une table des départements qui ne contiendra dès lors qu'un entrée? Penses-tu étendre la BD à d'autres départements?

Quoi qu'il en soit, ce n'est pas un problème de garder la table des dpts, mais il faut juste s'assurer des bons liens entre les tables pour ne pas générer d'incohérences.

[La_Kai]

J'habite en Belgique => pas de départements, mais administrativement, c'est au moins aussi compliqué... On a les politiques qu'on mérite (me demande ce qu'on a bien pu faire pour mériter ces nullités, mais passons)...

Je ne savais pas ! Cet échange est vraiment intéressant pour le coup, vous fonctionnez plutôt par canton j'imagine, plus sur le modèle Suisse ? Ou bien le modèle fédéral Allemand ? J'ai fait une fac de géo mais étudier l'urbanisme en France ça m'a déjà suffit ^^'

Si chaque commune est liée une intercommunalité et dans la mesure où je suppose qu'une intercommunalité ne peut pas être à cheval sur deux départements, le lien Commune / Département n'a pas lieu d'être et peut être supprimé, ainsi que la clé étrangère qui pointe vers le département dans la table des communes. Tu pourras déduire le département en passant par son intercommunalité.

Tu as tout pigé niveau emboitement géographique, donc oui je pense que le lien peut être supprimé, j'aurais pu y penser moi-même si j'avais fait plus attention

Maintenant il faut que je regarde et comprenne comment attribuer les valeurs des clés primaires aux clés étrangères :p

[La_Kai]

Si la BD ne porte que sur le Calvados, est-ce utile d'utiliser une table des départements qui ne contiendra dès lors qu'un entrée? Penses-tu étendre la BD à d'autres départements?

Quoi qu'il en soit, ce n'est pas un problème de garder la table des dpts, mais il faut juste s'assurer des bons liens entre les tables pour ne pas générer d'incohérences.

Pour l'instant cela ne porte que sur le département du Calvados, mais le pour l'instant est important, c'est pour cela que j'ai choisi de créer une table Département. En fait pour être plus précis, il y a toute la Normandie dans les tables communes (car la BD servira peut-être à autre chose que les piégeurs/rongeurs) et donc je choisis de laisser toutes les communes plutôt que de réduire à seulement celles du Calvados, pour ne pas brider par la suite les futurs (éventuels) développeurs de la BD.