Discussion :

[Almeyric]

Bonjour

Suite à mon premier poste ici : http://www.developpez.net/forums/d14...s-accueillant/

J'ai décidé de repartir de 0 en m'appuyant sur l'existant et avec une meilleur logique pour qu'une autre personne puisse comprendre facilement.

Je viens de voir une réponse, j'irai répondre après ma petite question.

Du fait que je repars de 0, j'apprends à utiliser Access en même temps et là je bloque sur quelque chose d’apparemment simple mais je ne trouve aucune réponse.

Donc j'ai créé 4 tables : tbl_Communes, tbl_Departements, tbl_Prefectures, tbl_Regions,

Les tables Départements et Régions sont des listes présentées comme ceci :

ID_Dept (Clé & NumAuto), Num_Dept, Nom_Dept, Nom_Région <--- le Nom_Région provient de la table Région par relation 1 a plusieurs et ce met à jour si changement dans Régions. Je pense que cela j'ai compris.

Ce que je désire, c'est que dans ma table Communes, j'affiche le Num_Dept par relation mais que quand le Num_Dept est égal "01" alors dans le champ Nom_Dept s'affiche le nom "Ain".

De même pour le nom de la région.

J'espère que je me suis bien expliqué.

Merci d'avance.

[Didier L]

Bonsoir,

Ce que je désire, c'est que dans ma table Communes, j'affiche le Num_Dept par relation mais que quand le Num_Dept est égal "01" alors dans le champ Nom_Dept s'affiche le nom "Ain".

Attention, parle t'on de table ou de formulaire quand tu dis "j'affiche"

Car la logique, c'est que les tables soient les plus légères possible avec le minimum de redondance et ne sont la que pour "stocker" des informations.
Ensuite pour présenter ces informations, on peux les reconstruire avec des requêtes et les afficher via des formulaires ou des états.

Donc dans la table "communes" la seule information nécessaire au bon fonctionnement de la base c'est le N° du département. Le champ "Nom_dept" n'a pas lieu d'être et ne doit pas être renseigné.
En revanche pour une consultation, nous irons le récupérer dans la table des département en faisant le lien justement sur le N°.
c'est le principe même d'une base de données relationnel. On découpe et décompose l'information, que l'on range dans des tables et on évite la redondance d'information. Seules les clés servent de lien entre les tables pour faire les requêtes.
L'analyse et la construction du schéma relationnel est l'un des points les plus important d'une base. Cela définit déjà ce que l'on veux, et ce que l'on pourra faire ou non.
c'est aussi en le relisant que l'on arrive a comprendre le fonctionnement d'une base si tenté qu'il soit juste et ai été bien construit.
Car une erreur à ce niveau pourra empêcher des traitements par la suite.

Peux tu faire une capture d'écran des relations entre ces tables ?
Cela permettra également de voir les champs disponibles

[Almeyric]

Bonsoir,

Attention, parle t'on de table ou de formulaire quand tu dis "j'affiche"

Je parle bien de table.

Car la logique, c'est que les tables soient les plus légères possible avec le minimum de redondance et ne sont la que pour "stocker" des informations.
Ensuite pour présenter ces informations, on peux les reconstruire avec des requêtes et les afficher via des formulaires ou des états.

Ok, je comprends mieux.

Donc dans la table "communes" la seule information nécessaire au bon fonctionnement de la base c'est le N° du département. Le champ "Nom_dept" n'a pas lieu d'être et ne doit pas être renseigné.
En revanche pour une consultation, nous irons le récupérer dans la table des département en faisant le lien justement sur le N°.
c'est le principe même d'une base de données relationnel. On découpe et décompose l'information, que l'on range dans des tables et on évite la redondance d'information. Seules les clés servent de lien entre les tables pour faire les requêtes.
L'analyse et la construction du schéma relationnel est l'un des points les plus important d'une base. Cela définit déjà ce que l'on veux, et ce que l'on pourra faire ou non.
c'est aussi en le relisant que l'on arrive a comprendre le fonctionnement d'une base si tenté qu'il soit juste et ai été bien construit.

Du coup, je comprends mieux le principe de base et j'ai l'exemple à ne pas faire avec la base en production.

Peux tu faire une capture d'écran des relations entre ces tables ?
Cela permettra également de voir les champs disponibles

La voici :



Donc si j'ai bien compris, au niveau de la table Préfectures que j'ai importé de la base en production, je ne dois pas avoir les champs suivants : Nom_Dept, CP_Commune, Nom_Commune. Puisqu'avec une requête ou un état, je pourrais récupérer avec le Num_Dept et le Num_Insee, le CP et le Nom.

Est-ce bien cela ?

Par contre, je n'arrive pas à appliquer l'intégrité référentielle entre les tables département et communes.

Acces me dit :

Les donnée de la table ne respectent pas les règles d'intégrité référentielle.

[Didier L]

Donc si j'ai bien compris, au niveau de la table Préfectures que j'ai importé de la base en production, je ne dois pas avoir les champs suivants : Nom_Dept, CP_Commune, Nom_Commune. Puisqu'avec une requête ou un état, je pourrais récupérer avec le Num_Dept et le Num_Insee, le CP et le Nom.

Est-ce bien cela ?

Effectivement ils ne sont pas nécessaires. Seul le champ "N_INSEE" est requit car avec lui on peut récuperer le Num_Dept, le Nom et le CP de la commune, et avec le Num_Dept on pourra aussi récupere le nom_dept et ainsi de suite si on veut aussi récuperer la région

Code :

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

1
2
3
4
5
Par contre, je n'arrive pas à appliquer l'intégrité référentielle entre les tables département et communes.
 
Acces me dit :
 
Les données de la table ne respectent pas les règles d'intégrité référentielle.

C'est normal car il y a déjà des données dans les deux tables et le lien doit se faire sur la même information et surtout le même type de donnée.
Je suppose que le L'ID_Dept doit etre un numéro auto (et qu'il ne sert a rien) car la Num_Dept pourrais très bien etre aussi la clé primaire de cette table car il doit être unique. De plus c'est cette information que l'on retrouve dans la table des communes et non l'ID !
Il faut donc faire cette relation sur ces deux champs en partant de la table département et en allant vers la table commune.
Attention, pour pouvoir appliqué l'intégrité référentielle le champ Num_Dept doit au minimum être indexé sans doublon (mais c'est mieux si c'est la clé primaire)

[Almeyric]

Effectivement ils ne sont pas nécessaires. Seul le champ "N_INSEE" est requit car avec lui on peut récuperer le Num_Dept, le Nom et le CP de la commune, et avec le Num_Dept on pourra aussi récupere le nom_dept et ainsi de suite si on veut aussi récuperer la région

Ok, je fais le nécessaire à ce niveau.

[QUOTE]Je suppose que le L'ID_Dept doit etre un numéro auto (et qu'il ne sert a rien) car la Num_Dept pourrais très bien etre aussi la clé primaire de cette table car il doit être unique. De plus c'est cette information que l'on retrouve dans la table des communes et non l'ID ![QUOTE]

Ok. Mais quid du cas de la Corse avec 2A et 2B, le type de donnée peut être n'importe quoi pour la clé primaire, d'après ce que je vois.

-----------

Donc j'ai modifié la table département en indiquant le Num_Dept en clé primaire, recréer la relation vers la table Communes, et Access râle toujours pour l'intégrité.

[Didier L]

Oui la clé peut être du texte sans souci et pour moi effectivement un N° de département est du caractère à cause justement de la corse 2A et 2B et pour les autres aussi cela simplifie l'affichage "01" ... "09" avec le "0" devant ;-)

[Almeyric]

OK. Après mettre occupé de mes filles, j'ai enfin fini la relation entre les 4 tables et remis à jour toutes les informations des préfectures (le plus chiant).

Voici mes relations :



1 - Je n'arrive toujours pas à mettre l'intégrite entre Communes et Département. Access me dit toujuors le même message. Donc j'ai regardé si il y a des différences entre les deux champs et oui, dans la tbl_Communes, Num_dept est indexé avec doublons (normal), mais dans la tbl_Dept, il est indexé sans doublons. Et là, j'arrive pas le changer.

Comment faire ?

2 - Beh je sais plus ce que je voulais en 2. ça me reviendra.

[Didier L]

mais dans la tbl_Dept, il est indexé sans doublons.

C'est normal et c'est tant mieux.
maintenant si les deux champs sont bien du texte cela veux dire que dans la table commune il y a des n° de département qui n'existe pas dans la table département.

Pour les trouver, il faut faire un requête avec les deux tables faire afficher les N° de département des deux table, double cliquer sur la relation et choisir le type de jointure "Afficher tous les enregistrements de la table tbl_Communes et seulement ceux de la table tbl_departement pour lesquels les champs sont joint".
Ainsi en fermant on doit avoir une flèche qui va de la table communes vers la table département.
Ensuite dans le critère de sélection du champ N° de département de la table département tu mets : Est null.
Tu exécute la requête et tu verra les communes qui ont un N° de département qui n'existe pas dans la table département.
S'il y en a beaucoup, tu peux faire un regroupement pour savoir quel sont les départements qui te manque.
Ensuite tu les crée, et enfin tu pourras faire ta relation

[Almeyric]

Alors j'ai utilisé l'assistant avec la solution de non-correspondance, et effectivement, il me sort 12 numéros qui ne corrspondent pas.
C'est de 1 à 9 dans la table commune et dans la table département, de 01 à 09.

Je suppose, qu'il doit être tout a fait possible de réaliser une macro pour que cela change tout seul.

En résumé, je dois demander :

1 - Selection des communes égal avec le Num_dept de 1 à 9.
2 - Tant que X inferieur ou egal à 9, je fais une boucle pour changer les numéros.

Je pense pouvoir y arriver, je regarde cet am. Si besoin, je viendrai chercher de l'aide.

[Almeyric]

Bon j'ai réussi à ne plus avoir de non correspondance.

Donc j'ai modifié les Num_Dept dans la tbl_Communes avec la fonction rechercher et remplacer. Mais je n'arrive toujours pas à appliquer l'intégrité.

Pourtant la requête de non correspondance entre les deux tables avec le type de jointure différents me donne toujours le même résultats.

Acces me dit toujours que ma tbl_Communes ne respectent pas les règles !!

[Didier L]

Peux tu envoyer une base avec tes deux tables ?
Que je regarde

[Almeyric]

Voici la base

http://ovh.to/1AT5w7Z

Tu remarqueras que j'avance un petit peu.

[Didier L]

Le sens de la relation de ta requête n'était pas le bon ni le critère

Voila la solution:


Et il existe bien des commune avec un N° de département qui n'existe pas dans ta table


Crée le département "20" dans ta table et le problème sera résolut

[Almeyric]

Ah quel plouc, je modifiais la relation dans les relations principales, et pas la relation dans la requête.

Ce sont deux villes de l'aisne. Problème résolu.

Merci Didier.

[Didier L]

Bonjour,

Merci donc de penser au tag "Résolu"