Discussion :

[AnnaPouet]

Bonjour à tous,

Dans ma base de données, j'ai une table projet (clé primaire: N°Projet).
Chaque projet est constitué de deux sites distincts (A et B), car l'entreprise intervient sur deux sites pour un projet donné. J'ai donc également une table Site (clé primaire: N°Site).
Pour chaque site sur lequel on intervient, on a une multitude d'information qui dépendent du projet auquel il s'associe.

J'avais donc créer ma base de cette manière:
Projet (N°Projet, ...infos sur le projet ...)
Site_par_Projet(N°Projet, N°Site, Position_site (A ou B), ... infos sur le site en rapport avec le projet)
Site(N°Site, ... infos sur le Site)

Jusque là cela me semblait une bonne solution... jusqu'à ce que je m'attaque aux formulaires...
En effet, si je veux par exemple: N°Projet, N°Site A, Nom site A, N°Site B, Nom Site B, ect... Alors je passe par 2 requêtes et il faut que je fasse le formulaire "a la main" avec création de table, modif formulaire et MAJ faites par requête.

Je pensais pouvoir simplifier avec une table contenant 3 clés primaires, je m'explique:
Projet (N°Projet, ...infos...)
Projet_Sites (N°Projet, N°Site A, N°Site B)
Site_par_Projet(N°Projet, N°Site, ...infos...)
Sites(N°Site, Nom_Site, infos...)

Le problème est que je n'arrive pas à relier la table PROJET_SITES à la table SITE_PAR_PROJET. Si j'essaie d'associer N°Projet et N°SiteA de la table P_S à N°Projet et N°Site de la table S_P_P, j'obtiens le message d'erreur "Index unique introuvable pour le champ référencé d'une table principale".
J'ai lu quelque part qu'il faut qu'un des deux champs mis en relation soit indexé sans doublon, mais dans mon cas, un numéro de site peut apparaitre plusieurs fois dans les tables car il peut être choisi pour n'importe quel projet.

Comment faire pour simplifier tout ça afin de pouvoir accéder aux formulaires automatiques et pouvoir accéder aux Sites A et B sans passer par des requêtes?

Je ne sais pas trop si j'ai été claire (au besoin je peux joindre une capture de mon MCD) et remercie ceux qui prendront le temps de se pencher sur mon pavé.
Merci d'avance!

[curt]

Bonsoir AnnaPouet,

peux-tu joindre ta base en pièce jointe (sur le forum ou par MP), ça sera plus simple d'étudier ton problème.

A la lecture de tes explications, je crois que ta structure n'es pas judicieuse. Un coup d'oeil sur la base le confirmera peut être.

Bonne soirée.
Curt

[alexbesht]

Bonjour!
J'ai un problème très similaire à celui d'Anna, avec le même message d'erreur. Voici le fond du problème, avec les explications antérieures sommaires mais nécessaires:
Je dois construire un outil de gestion de stock éditoriaux. J'emploie Access 2003. La spécificité de la base de données est que certains ouvrages sont édités sous le code EAN (codes similaires au code ISBN, plus utilisés) de l'établissement pour lequel je travaille, et d'autres sont co-édités sous l'EAN du co-éditeur. Le problème est que chaque code EAN n'est, du coup, pas unique car j'ai trouvé 2 ouvrages distincts qui ont exactement le même code EAN13 car l'un est édité par mon établissement, et l'autre est co-édité sous le code EAN du co-éditeur.
Ce problème n'est pas donc une simple exception à la règle, il pourrait se répéter à l'avenir et je dois le prendre en compte. C'est pourquoi j'ai pensé qu'il fallait composer la clé primaire de ma table "ouvrage" par les 2 champs "EAN13", et "édition/distribution" qui correspond au type d'édition (édition réalisée entièrement par mon établissement, co-édition avec EAN de mon établissement, ou encore co-édition avec l'EAN du co-éditeur). La combinaison des 2 champs doit me donner un élément unique à chaque fois, logiquement.
Mais j'éprouve des difficultés au moment de lier les différentes tables. J'ai une table "éditeurs", une table de jonction "éditer", et une table "ouvrages" donc, et une autre table "détails mouvements" que je n'arrive pas à lier entre elles. J'obtiens le même message qu'Anne quand j'essaye de lier les 2 champs qui composent ma clé primaire à la table de jonction.
Cela doit être un problème d'indexiation mais je ne saisis pas trop la façon de procéder, je ne suis même pas sûr de la façon de lier les tables quand elles comportent plusieurs clés primaires (je n'ai eu que quelques notions d'Access, et majoritairement sur papier et non sur ordi...vive la France), et j'aurais donc besoin de votre aide pour cette étape précise.
Je vous joint une capture d'écran des relations pour que cela soit un peu plus clair et je m'excuse de la longueur de ce message mais il faut être clair dans ces cas-là il me semble, j'espère que je l'ai été un minimum.
Merci pour votre aide!
Alexandre

[alexbesht]

Je crois avoir réglé mon problème en feuilletant une page de forum qui en une phrase résumait mon problème finalement, enfin je crois. Une nouvelle capture d'écran pour avoir votre avis,
Merci!

[f-leb]

bonjour,

pour les clés multiples, il faut "tendre" la relation dans le sens clé primaire vers la clé étrangère.

C.a.d tu tends de Ouvrage.EAN13 vers DetailsMvt.EAN13. Tu double-cliques sur la relation et tu rajoutes la ligne Ouvrage.Edition, DetailMvt.Edition.

Par contre le couple {EAN13,Edition} n'est pas forcément un bon candidat pour la clé primaire.
Tu peux aussi bien mettre un numAuto {idOuvrage} comme clé primaire, puis rajouter un index "sans doublon" sur le couple{EAN13,Edition} (clé alternative).

[alexbesht]

bonjour,

pour les clés multiples, il faut "tendre" la relation dans le sens clé primaire vers la clé étrangère.

C.a.d tu tends de Ouvrage.EAN13 vers DetailsMvt.EAN13. Tu double-cliques sur la relation et tu rajoutes la ligne Ouvrage.Edition, DetailMvt.Edition.

Par contre le couple {EAN13,Edition} n'est pas forcément un bon candidat pour la clé primaire.
Tu peux aussi bien mettre un numAuto {idOuvrage} comme clé primaire, puis rajouter un index "sans doublon" sur le couple{EAN13,Edition} (clé alternative).

Bonjour,
Merci de la réponse. J'avais compris qu'il fallait "tendre" la relation comme vous l'avez décrit mais c'était plus au niveau des clé étrangères mêmes que j'avais un problème. Il est réglé maintenant il me semble.
Sinon en effet, un num Auto pourrait marcher pour la table ouvrages mais pouvez-vous me dire précisément les risques ou les problèmes que pourrait engendrer le couple (EAN13,Edition) comme clé primaire.
Merci

[f-leb]

Bonsoir,

Sinon en effet, un num Auto pourrait marcher pour la table ouvrages mais pouvez-vous me dire précisément les risques ou les problèmes que pourrait engendrer le couple (EAN13,Edition) comme clé primaire.

Je te renvoie au papier de SQLPro sur les Clefs auto incrémentées et en particulier les paragraphes:
1. Qualité d’une bonne clef et 2. Clef naturelle ou clef numérique ?

Tu commences à voir le problème ?

[alexbesht]

Tu commences à voir le problème ?

Oui, j'étais plus ou moins au courant, mais je ne trouvais pas ça si gênant que ça. De toute façon le problème est réglé, j'ai été mal informé, un code EAN est unique à tout ouvrage, il contient un numéro spécifique pour chaque éditeur, le doublon résultait donc d'une erreur faite par mes prédécesseurs, la clé primaire double n'est plus nécessaire, ouf.
Merci pour votre aide