Discussion :

[jax54000]

Bonjour,

Est-il normal/fréquent qu'une table soit liée à toutes les autres ?

Dans mon cas il s'agit d'une table "email" dont le sujet de discussion peut être lié à toutes les autres données de la base.

Merci.

Djo

[Invité]

Bonjour

Tout dépend de ton schéma, mais cela peut arriver.

Le mieux est de nous mettre une copie d'écran de tes liaisons, non ?

Philippe

[jax54000]

Ben je n'ai pas encore fait les liaisons car je ne savais pas si c'était faisable.

Petite copie d'écran mais je ne sais pas si ça va vous aider. Je vous préviens c loin d'être la dernière version...je viens juste de commencer

http://www.cijoint.fr/cjlink.php?fil...cijPYkLo8X.jpg

Merci.

[jax54000]

ça fait peur ?

Ma question est juste de savoir si une table "email" (qui contiendrait donc des emails ou des liens vers des emails) peut être liée à toutes les autres tables (car un email peut parler de n'importe quel sujet).

Thanks.

Djo

[f-leb]

ça fait peur ?

Terrifiant

mais si tu as,

Email---approuver----Document-----Concerner-----Produit

c'est que tes règles de gestion t'ont amené à associer par deux Email--Document puis Document--Produit, non ?
La structure des tables et des relations sont dictées par les règles de gestion, c'est tout.

En fait, ta question n'est pas très claire. Tu peux donner un exemple de ce qui te tracasses ? (avec 2-3 tables hein! pas plus)

[jax54000]

C'est bien ce que je me disais...ça fait peur

Exemple:

4 tables : Produits, Non-conformités, Commandes, Emails,

Un email peut parler d'un produit spécifique
Un email peut parler d'une non-conformité spécifique
Un email peut parler d'une commande spécifique
...

Ce qui me tracasse c'est qu'effectivement un email peut parler/concerner toutes les données/tables de ma base.

La question que je me pose alors est : dois-je lier cette table email à toutes les autres ?

Idem avec la table Documents (la même problematique se pose)

J'espère que je suis plus clair.
Merci
A+
Djo

[nico84]

Bonjour,

Code :

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

car un email peut parler de n'importe quel sujet

signifie aussi qu'un email est rarement lié à une table donnée... Que va apporter le lien avec cette table ???

Dans le même esprit j'ai une table "documents" qui contient l'adresse de documents liés à n'importe quel objet de ma base et cette table n'a aucun lien car je gère la cohérence quand j'écris dans la table ou quand l'utilisateur veut effacer le "père" du document. Le document a son ID et contient 2 champs pour retrouver à qui il est lié : le nom de la table du père et l'id du père

[f-leb]

bonjour à tous,

j’essaye de recoller les morceaux avec un autre exemple qui ressemble plus ou moins à ton cas.

Un document est transmis par Email, un Email peut transmettre plusieurs documents.
Un document à un type (commande, livraison,….) et concerne un produit :

Type-1------∞-Document-∞--------1-Produit
...........................|
...........................-∞--------------1-Email

Si ton tracas était qu’un "un Email peut parler de plusieurs produits", je te rétorquerais que grâce à une requête SELECT avec les jointures Email---Document---Produit, tu pourrais remonter aux produits concernés par un Email particulier.

Dans ce cas, raccorder directement Email à Produit serait redondant. Et la redondance est à proscrire dans une base de données…

Bref, un Email qui "parle de n'importe quel sujet" ne semble pas être une formalisation convenable de règle de gestion.

[jax54000]

Yes mais :

Si un email ne transmet aucun document et que son contenu concerne un produit. Il faut bien lier la table email à la table produit non ?

Exemple d'email:
Objet email: Evenement Produit numero de serie 11
Corps email: Je vous annonce que le produit numéro de serie 11 est retiré de la ligne de production.

Je voudrais pouvoir "attacher" cet email au produit 11.

Merci de votre aide je suis total débutant pour BD.

+

[nico84]

Code :

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

Il faut bien lier la table email à la table produit non ?

Il n'y a aucune obligation à lier 2 tables, le lien sert à garantir la cohérence des données mais n'est jamais obligatoire.

Exemple : si un mail est associé à l'article 458, l'existence d'un lien peut garantir "en dur" que l'article 458 existe et ne peut plus être supprimé tant que le mail existe. Cette garantie sera plus efficace qu'un controle logiciel et incontournable, par contre la gestion des erreurs sera moins conviviale...

[jax54000]

...Je comprends pas bien

L'idée dans mon exemple est de pouvoir par exemple faire la requete suivante:

Affiche moi tous les emails envoyés entre janvier et mars et qui concernaient le produit 11.

Si je veux faire ça, on est d'accord que le lien est obligatoire ?

Merci.

[f-leb]

...Si je veux faire ça, on est d'accord que le lien est obligatoire ?

Pour moi dans ce cas, il me semble tout à fait justifié.

de même:

Un email peut parler d'un produit spécifique
Un email peut parler d'une non-conformité spécifique
Un email peut parler d'une commande spécifique

Email----0,?----parlerProduit----0,n----Produit
Email----0,?----parlerNC-----0,n-----NonConformite
Email----0,?----parlerCommande-----0,n----Commande

J'ai mis un "?" sur la cardinalité maximale ne sachant pas si je devais mettre 1 ou n car un Email peut par exemple parler de plusieurs produits ? C'est possible ça, non ?

[jax54000]

Ahhhhhhh tu me rassures !

Oui je confirme que c'est possible qu'un email parle de plusieurs produits.

Je commence à saisir...
J'ai peur par contre que le nombre de liens et de tables montent en flèche...

Merci.

A+

[nico84]

Code :

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

Si je veux faire ça, on est d'accord que le lien est obligatoire ?

Pas obligatoire, non... Justifié pourquoi pas ça dépend de l'application qu'il y a derrière...
Par exemple je n'utilise pas de macros, ça a peut être un intérêt supérieur dans ce cas ? Il y a tellement de façons de programmer la même chose qu'il est difficile d'avoir une réponse absolue !

A ma connaissance une requête inner ou left join marche aussi bien qu'il y ait un lien ou non entre les 2 tables. C'est peut-être plus rapide avec un lien (je n'ai pas la réponse à cette question) mais la syntaxe est la même et le résultat aussi.

S'il s'agit de lier le mail à tout ce dont il parle on est plus dans l'esprit du moteur de recherche là, non ???

[f-leb]

bonsoir,

A ma connaissance une requête inner ou left join marche aussi bien qu'il y ait un lien ou non entre les 2 tables. C'est peut-être plus rapide avec un lien (je n'ai pas la réponse à cette question) mais la syntaxe est la même et le résultat aussi.

je viens de comprendre là où tu voulais en revenir.
Lorsqu’on rajoute le "lien" -1-------∞- (ou plus rarement -1------1-) dans la fenêtre des relations d’Access, on met en œuvre un mécanisme supplémentaire qui est celui de l’intégrité référentielle.

Exemple : si un mail est associé à l'article 458, l'existence d'un lien peut garantir "en dur" que l'article 458 existe et ne peut plus être supprimé tant que le mail existe. Cette garantie sera plus efficace qu'un controle logiciel et incontournable, par contre la gestion des erreurs sera moins conviviale...

oula, l’éternel débat que je ne vais surtout pas relancer ici :

Réflexions sur la fenêtre des relations et l'utilité de l'intégrité référentielle
Contraintes FOREIGN KEY SQL vs code client

S'il s'agit de lier le mail à tout ce dont il parle on est plus dans l'esprit du moteur de recherche là, non ???

S’il s’agit de rechercher ces informations dans le corps du Mail, voilà une fonctionnalité qui pourrait intéresser Jax54000. A voir… Mais même les infos pêchées par un moteur sont "indexées" dans une base de données, non ?

[nico84]

Oui je pense que dans pareil cas l'intégrité référentielle n'apporte pas grand chose, et dans tous les cas elle n'est pas obligatoire.

Pour les moteurs de recherche je pense aussi qu'ils doivent gérer de grandes quantités de liens, mais dans des tables externes (où il n'y a que des liens) et sans aucune intégrité. Une solution dans cet esprit serait a mon avis plus proche du besoin exprimé dans cette file - mais tout cela n'engage que moi