problème ACCESS intégrité référentielle

[ludosnip]

bonjour à tous

 

voici mon problème : j'ai une table PIECE et une table AUTEUR.

 

Ma table AUTEUR, comporte les champs : N° auteur et Nom auteur.

Ma table pièce comporte les champs : Code pièce, Nom pièce, durée, prix et Nom auteur.

 

Sur le champ Nom auteur(dans ma table pièce)je fais, dans liste de choix, un menu déroulant comportant les noms des auteurs avec une requête. Cependant lorsque je fais une relation entre la table pièce et auteur et que je coche "intégrité référentielle", il me met un message d'erreur. Si au lieu des noms auteurs je fais un menu déroulant avec les numéros auteurs toujours dans la table pièce, là je n'ai aucun problème, l'intégrité référnetielle fonctionne sans problème.

 

 

pourriez vous me dire comment faire ?

[KewlCat]

Tu ne peux pas avoir de référence d'un champ sur un autre si le champ "cible" n'est pas à la fois unique et non nul. C'est donc parfaitement normal que cela fonctionne avec la clé de la table (puisqu'elle remplit ces conditions).

Au passage, je te fais remarquer que tu as une redondance de données, si tu stockes le nom de l'auteur dans deux tables différentes... (i.e. ta table AUTEUR ne te sert à rien... du moins, rien de plus que ce qu'un select distinct nom_auteur from PIECE peut te fournir)

 

-- note --

Je déplace ce sujet dans "Programmation"

[Dylav]

Bonsoir Ludosnip, KewlCat,

 

Comme je l'écrivais avant que la chute de la BD ne censure mes propos, la table AUTEUR n'a d'utilité que si l'auteur est identifié dans la table PIECE par son numéro, et non par son nom. Tu pourras ensuite enrichir la table AUTEUR d'autres renseignements concernant l'auteur (comme son prénom, sa date de naissance, son style, un aperçu de son œuvre, etc.), toutes informations que tu pourras rendre accessibles à partir de la pièce sur demande du visiteur. Et ceci sans avoir besoin de les répéter dans la table PIECE, évitant ainsi lourdeur, redondances, répétitions et difficultés de mises à jour multiples (autant de fois que l'auteur aura produit de pièces).

 

Au passage, je te fais remarquer que tu as une redondance de données, si tu stockes le nom de l'auteur dans deux tables différentes...

Sans vouloir ergoter, on ne peut néanmoins pas dire à proprement parler qu'il y ait redondance sur le nom de l'auteur : si l'on considère que ce nom est justement la clef de la table AUTEUR, le schéma de données est cohérent... mais bon, que de difficultés à venir, ne serait-ce que la gestion des homonymes !

[KewlCat]

Sans vouloir ergoter, (...)

Si le nom de l'auteur est la donnée porteuse d'information et qu'elle est répétée sur deux tables (dont, au passage, l'une d'elles ne comporte aucune autre donnée significative), il y a bel et bien un "gaspillage" (puisque tu refuses le terme "redondance")

[Dylav]

Sans rebondir trop longtemps sur cette question oiseuse que j'ai moi-même suscitée, si tu considères que la table AUTEUR a pour clef nom_auteur, et pour rubrique documentaire associée à cet auteur son numéro_auteur, l'affaire prend corps (même si c'est quelque peu absurde, je le reconnais). C'est pour cela que je mettais en cause la notion de redondance

[KewlCat]

Héhé, je savais qu'il marcherait ce mini-troll

[Dylav]

Je n'ose pas poster un simple smiley

(zut, je l'ai fait)

[KewlCat]

3FNBCK RuLeZ !

ok, j'arrête

[jp46]

Salut LudoSnip, salut à tous,

 

Il me semble que vous confondez la fonctionnalité et l'apparence.

Fonctionnalité :

C'est le CODE Auteur qui doit servir de lien

Apparence :

Dans la table Pièce, le champ Auteur sera :

- numérique, de même nature que la clé NoAuteur de la Table Auteur

- une liste de choix, source:T_Auteur, lien=Col1, Aff:2col, largeur=0;6

- l'affichage sera le nom d'Auteur et non son No

 

Cordialement, à+

[Dylav]

Bonjour jp46, et bienvenue sur Zébulon,

 

A propos du présent sujet, n'aie pas d'inquiétude, je crois que plus personne n'avait de doutes sur le design des tables et la cardinalité des données. Merci néanmoins d'avoir détaillé les choses.

 

@+

Dylav