Relations multiples

[Duracell]

Bonjour à tous,

Je fabrique du carton multicouche. Un même carton peut contenir jusqu'à trois colles différentes (ou identiques). J'ai donc créé un champ par colle dans ma table Article (carton). J'ai une table Colles qui recense toutes les colles (une trentaine).

J'ai besoin de sélectionner tous les produits en fonction d'un champ (oui/non) de la table Colles. C'est à dire que la table Colles doit être reliée d'une façon ou d'une autre aux trois champs colle de la table Article.

Quelqu'un peut-il m'aider? Ca fait une semaine que je tatonne sur Access et je n'en peux plus.

Merci

 

[chris]

Re : Relations multiples

Bonjour

Pas sûre d'avoir tout compris mais a priori

Dans le mesure où "Un même carton peut contenir jusqu'à trois colles différentes ou identiques" cela veut dire qu'il peut y avoir une, deux ou trois colles.
Il ne faut donc en aucun cas créer 3 champs colle dans la table carton (car inexploitable en requête comme tu l'as pressenti et non évolutif) mais créer 3 tables :

• Cartons avec un enregistrement par type de carton (d'après ce que je comprends cette table stocke les divers types de carton)
  identifiant unique = type carton
• Colles : avec un enregistrement par type de colle
  identifiant unique = type colle
• Utilisation colle dans carton : un enregistrement par combinatoire possible. Su une même colle peut servir plusieurs fois dans le collage et que tu as besoin de le savoir la structure sera
  • ID carton
  • ID colle
  • entre_couches (exemple 1-2 ou 2-3 ou 3-4)
  • autres champs si nécessaire
    identifiant unique = le trio ID type carton/ID type colle/entre_couches.
    Sinon les 2 premiers champs suffisent

Relation de 1 à n de la table Cartons vers la table Utilisation
Relation de 1 à n de la table Colles vers la table Utilisation

Après il est très simple de rechercher dans la table Utilisation quels cartons utilisent telle ou telle colle.

De plus lorsque tu feras du multicouches à 7 couches cela marchera tout aussi bien !

Tu peux configurer la table Utilisation pour qu'en saisie les champs ID carton et ID colle soient des listes déroulantes basées sur la table correspondante.

 

[Duracell]

Re : Relations multiples

Bonjour Chris,

Tu as compris mon problème.
Merci pour toute ces indications. Mon problème concerne mainteneant la mise à jour d'une telle base. Chaque mois, il y a environ 300 nouveaux cartons à entrer dans cette base. J'aimerais ne remplir qu'une ligne par carton dans la table Article. Est-il possible de transférer automatiquement les données consernant les colles vers la table Utilisation.

Car si j'ai ce problème avec les colles, il y a aussi les encres, les vernis...
Si pour un carton je dois entrer des informations dans 5 tables, ce sera trop long et ingérable.

As-tu une solution?

Merci

 

[chris]

Re : Relations multiples

Bonjour

Que contient la table article ?
300 cartons est-ce 300 types ou 300 exemplaires d'un ou plusieurs types ?

Les 3 tables que j'ai évoquées servent à définir la typologie des cartons.
Il faut définir les colles d'abord, puis les divers types de cartons avant de pouvoir préciser comment est fabriqué chaque type de carton dans Utilisation.

Si Article sert à gérer les quantités de cartons achetés, vendus, fabriqués (je ne sais) seule la référence carton est nécessaire.

Sinon explique ce que tu veux faire. Une base de données c'est comme un mécanisme d'horlogerie : il faut bien spécifier tout avant de commencer si on veut que cela marche.

 

[Duracell]

Re : Relations multiples

Re,

Merci Chris pour ton aide.
La table Article contient les carton fabriqués (assemblage, impresion... de plusieurs couches de carton).
Les 300 Articles à entrer sont tous différents: ils peuvent avoir la même succession de couche de carton mais pas les mêmes colles...

J'ai déjà trié mes Articles dans des structures (succession de carton...).
La table colle contient les infos concernant toutes les colles utilisées. Sa mise à jour se fait à part.

Mon but est d'entrer les informations concernant un produit en une seule fois. Ensuite, des requêtes doivent engendrer des actions en fonction des composants de l'article, de ses conditions d'utilisation...

J'ai du mal à m'exprimer correctement.
Je ne suis pas un pro d'access mais pour gérer toutes ces données je ne vois que ça.

Je pense que ce que j'ai exposé reflète le fonctionnement de ma base.

Que me sugères tu?

Merci

 

[chris]

Re : Relations multiples

La table Article contient les carton fabriqués (assemblage, impresion... de plusieurs couches de carton).

J'ai déjà trié mes Articles dans des structures (succession de carton...)

Il faudrait la structure de ta table et même de ta base pour t'aider car on risque de ne pas se comprendre.

La table colle contient les infos concernant toutes les colles utilisées. Sa mise à jour se fait à part.

Oui c'est bon.

Mon but est d'entrer les informations concernant un produit en une seule fois. Ensuite, des requêtes doivent engendrer des actions en fonction des composants de l'article, de ses conditions d'utilisation...

Dans mon schéma on aurait un formulaire Cartons avec sous-formulaire Utilisation pour tout saisir.
Il faut peut-être élargir la notion d'utilisation pour y intégrer les encres et autres.

Sans vision globale de ta base et de tes besoins, je ne peux pas vraiment t'aider.

Il faut surtout ne pas avoir une vision Excellienne : un base de données c'est très différent du tableur.

Chaque donnée ne doit exister qu'une fois. C'est par les requêtes et les relations qu'on obtient des vues croisant les données.

 

[Duracell]

Re : Relations multiples

Merci Chris,
Je vais tenter de mettre en application tes conseils. J'aimerais te donner ma base mais je ne peux pas dans un soucis de confidentialité.
Je pense avoir un problème avec la nature des relations. Dans quel sens les faire?
J'ai lu plusieurs informations concernant le sens des relations et ça n'est pas clair.

Je vais essayer de modifier ma base pour pouvoir la transmettre.

 

[Duracell]

Re : Relations multiples

Salut Chris!
Ma base Zipé fait 11 Mo. Je ne peux pas l'envoyer.(par mail peut-être?).
En voici une image. J'en prépare un mode d'emploi. J'ai essayé plusieurs types de relations. C'est un grand bazard. Dis-moi ce que tu en penses.

Merci Chris.

 

[chris]

Re : Relations multiples

RE

L'image est très peu lisible mais je peux voir que ta structure n'est pas bonne : elle sera inexploitable (ou très difficilement) et non évolutive.
Comme je le disais "Il ne faut donc en aucun cas créer 3 champs colle dans la table carton" ou articles en l'occurence, ni 3 champs vernis, etc
Quelques indications :

• Il faut sortir tous les composants de cette table : colles, vernis, encres, coatings.
• Pour les finitions (métal, plastic ou cire) je ne sais pas comment cela fonctionne mais si ce sont des alternatives il faut garder un seul champ.
• On peut sans doute créer un seule table des composants : on peut mélanger colles vernis et encres. On aurait un identifiant (si tu mets des noms et des numéros, il est plus logique que la clé soit sur le numéro), un type (colle, vernis, encre...) et d'autres infos.
  Si tu ne veux pas mélanger il faut une table de chaque type mais cela ne s'impose pas que si les données propres à chaque type de composant sont très différentes
• Customer dans la table Articles : même si le carton est initialement crée pour un client, il peut un jour être vendu à un autre, donc je ne mettrait pas l'info dans la table Articles
• Pour la table structure : là aussi prévoir 4 champs layers n'est pas bon. Il faut un champ nombre de layers et une seconde table pour détailler chaque layer (comme pour cartons et composition ci-dessous)
• Il faut une table Composition où tu détailleras tous les composants entrant dans la fabrication d'un carton :
  • ID du carton
  • ID du composant,
  • Place du composant (extérieur, intérieur pour encre, entre quel et quel layer pour la colle, etc)
  • il y aura dans la table un enregistrement par composant
• Tu sembles avoir fait des relations orientées et non des relations de 1 à n. Il faut des relations non orientées avec intégrité référentielle
• Même si les données sont éclatées entre la table Articles et la table Composition on peut saisir tous en même temps grâce à un formulaire imbriquant un sous formulaire.

Bon courage

 

[Duracell]

Re : Relations multiples

Bonjour Chris,
Merci beaucoup d'avoir pris le temps de m'aider.
Je vais modifier ma base comme tu me l'as indiqué. Je ne suis pas sûre de savoir créer correctement mon formulaire mais je reviendrais si tel est le cas.

merci encore

 

[Duracell]

Re : Relations multiples

Bonjour,
J'ai modifié ma base suivant tes conseils Chris sauf pour la Structure et les clients: un produit ne peut être vendu qu'à un client, la table Structure est organisée différement pour d'autres raisons.
Je ne peux pas activer l'intégrité référenciel à toute mes relations. Est-ce important?
Ci-joint l'aperçu de ma nouvelle base. La qualité de l'image n'est pas meilleure que la précédente.

Merci

 

[chris]

Re : Relations multiples

Bonjour

Oui l'image est très peu lisible.
Pour les relations : les exceptions sont rares, en principe on doit pouvoir mettre une intégrité sur tout. C'est que qui va garantir la cohérence de l'ensemble.
A priori à modifier :

• de Structures vers Articles il devrait y avoir une relation de 1 à n,
• de même pour la table située à gauche (Flex quelque chose on dirait)
• et pour la table Product (pack ou ...) vers Articles.
• Pour les tables de composants, vernis, cires, etc vers Ingrédients (je crois lire) : on ne peut mettre l'intégrité car ce dont des alternatives.
  Je pense qu'il serait mieux de mettre la clé primaire de ces tables sur le numéro plutôt que sur le nom, sauf si ce numéro est un code fournisseur par exemple non stable dans le temps.
  Pour la table ingrédients la clé primaire sur 2 champs ne marchera pas si tu détailles deux utilisations du même composant (2 couches de la même colle ou du même vernis).
  Si c'est le cas il faut ajouter le champ Place dans la clé.
  Il serait sans doute utile de créer une table des Places possibles pour contrôler la saisie.
• Dans Articles, il serait peut-être bien d'avoir le nombre de layers pour contrôler que le nombre de colles saisi = nombre de layers - 1

Pour la partie en haut à gauche je ne sais pas de quoi il s'agit (cela semble écrit test) donc pas d'idée. De même qu'entre Structures à la table située à sa droite.

Si tu n'arrives pas à créer la relation avec intégrité cela peut provenir de :

• clé primaire mal choisie
• taille et ou type des champs à mettre en relation différents
• tables non vides et données présentes du côté n mais pas du côté 1
• relation demandée dans le mauvais sens

La relation doit toujours être établie entre le clé primaire côté 1 : ce n'est pas la cas sur ton image entre Structure et la table (? test) à droite.

Voilà, voilou...

 

[Duracell]

Re : Relations multiples

Bonjour,
J'ai modifié ma base. L'intégrité référencielle est applicable partout ou presque.

Il me manque des informations, c'est pour çà que la table Flexivac n'est pas encore correctement reliée et en effet, la position des ingredients est à mettre dans la clé primaire mais je n'ai pas l'information pour tous mes produits pour l'instant.

Pourquoi les relations doivent colmporter la clé primaire. Entre Structure et OveralMigrationTest, c'est impossible car il y a plusieurs test par structure et les structures sont regroupé en Sur-structure.

Aujourd'huit je vais tenter de refaire mes requêtes et je reviens.

Merci

 

[chris]

Re : Relations multiples

Bonjour

Pourquoi les relations doivent colmporter la clé primaire. Entre Structure et OveralMigrationTest, c'est impossible car il y a plusieurs test par structure et les structures sont regroupé en Sur-structure.

Car on doit identifier à coup sûr l'enregistrement lié : par exemple pour une facture elle doit être lié à un et un seul client qui est identifié par la clé primaire de la table clients. Aucune confusion n'est alors possible.

Il n'y a jamais de relations de plusieurs à plusieurs : cela indique qu'il manque une table entre les 2.
L'image est plus nette : a priori ta table overallMigration semble mélanger les types de tests et le passage des tests.
On doit avoir d'un côté les types de test et de l'autre les tests que tu fais subir à chacune de tes structures, par exemple
ID structure
ID type test
Date test
Résultat test
Dans cette table il y aura un enregistrement par test subi par une structure.
Elle sera reliée à Structures et à Typetests en étant le côté n pour les deux (1 structure vers n test subis) et (1 type test vers n réalisations de ce test)

 

[Duracell]

Re : Relations multiples

Re,
Merci Chris, mais le simulant de test dépend des produits emballés (il peut y avoir plusieurs types de produits par structure).
Les conditions de test dépendent de la température d'utilisation (pouvant être différente pour un même type de produit emballé).

C'est plus compliqué qu'il n'y parraît.
Le but de ma table OveralMigrations est d'enregistrer les tests. ensuite, il faut tester si c'est conforme.
Je cherche aussi à plannifier les tests: une requête doit me calculer la date du prochain test pour chaque structure en fonction d'un délai. Elle doit me donner les conditions de test et les simulants ainsi que les numéros de produit (Fert) à tester.
J'essaie en ce moment de mettre en place les requêtes nécessaires. Les question viendront au cas par cas.

Toutes les relations sont maintenant de 1 à n. Je n'ai pas imposé l'intégrité référencielle entre les table TestStructure et OveralTestMigration pour permettre à l'utilisateur d'entrer d'autre tests ne consernant pas ces TestStructure (à la demande du client).


J'ai joint l'image de ma base. Je ne suis pas sûr que ce soit correct. La table simulants ferme une boucle de relation. Est-ce que ça ne va pas crer des interférences?


Une autre question: ma table Testreport me permet de faire le lien avec le rapport de test en PDF que j'ai inséré en objet OLE: Est-ce correct?

Ma table flexivac représente une relation avec une autre base. Comment relier deux bases?

Merci