Structurer une base de données Access

Bonjour à tous,

Dans le cadre de mon travail, je mets en place une base de données pour rassembler toute les informations de mon département. J'utilise access car il est inclus dans la suite office que chaque utilisateur a sur son PC. Je précise que je suis novice dans ce domaine.

J'ai créé une structure générale qui inclut les tables matières premières, fournisseurs, propriétés des matières premières, les produits finis, les propriétés des produits finis, modes opératoires,... Toute cette partie marche plutôt bien (et surtout comme ce que je souhaite faire). Je vous explique où se trouve mon problème:

Chaque produit fini est réalisé au départ d'une "recette" différente contenant un nombre variable de matières premières. Par exemple, je peux avoir 10% de 10 produits pour l'un un 50% de deux produits pour l'autre. J'ai fait une table contenant ingrédient 1, quantité ingrédient 1, ingrédient 2, quantité ingrédient 2,... mais n'ayant pas un nombre fixe d'ingrédient, cela pose des problèmes pour la création de mon formulaire et surtout lorsque je dois faire des requêtes.

Pourriez-vous m'indiquer comme structurer cette table ou m'indiquer où je pourrais trouver un exemple. je pense que ce que je souhaite faire n'est pas si loin d'un site d'e-commerce où on ne sais pas à l'avance le nombre d'articles dans chaque commande. Je n'arrive cependant pas à trouver d'exemple de ce genre de base de données pour m'en inspirer.

D'avance, je vous remercie.

Bonjour,
La réponse est dans la question:

Citation:

---

Envoyé par vadorthegreat

Chaque produit fini est réalisé au départ d'une "recette" différente contenant un nombre variable de matières premières. Par exemple, je peux avoir 10% de 10 produits pour l'un un 50% de deux produits pour l'autre. J'ai fait une table contenant ingrédient 1, quantité ingrédient 1, ingrédient 2, quantité ingrédient 2,... mais n'ayant pas un nombre fixe d'ingrédient, cela pose des problèmes pour la création de mon formulaire et surtout lorsque je dois faire des requêtes.

---

Il te faut ici 2 tables de plus: une table de recette (avec l'identifiant de l'article), et une table recette_ingredient qui fait le lien entre une recette et un ingrédient, dans laquelle tu peux indiquer (entre autre) la quantité de l'ingrédient en question.

Ainsi tu peux avoir autant de recettes que tu veux pour un même article, et un nombre indéfini d'ingrédients par recette.
Si besoin tu peux ajouter une contrainte d'unicité sur la table recette_ingredient, sur le couple (IdRecette, IdIngrédient), si tu veux t'assurer qu'un ingrédient n'apparait au plus qu'une seule fois par recette.

Tatayo.

Bonjour,

Tout d'abord, ACCESS est un SGBD très limité en fonctionnalités et peu performant dès que le nombre d'accès concurrents est un tant soit peut significatif.
Le choisir uniquement parce qu'il est installé sur les postes de travail n'est pas forcément une bonne chose. D'autres SGBD sont gratuits et bien mieux armés pour supporter la charge.

Ensuite, quand on étudie la réalisation d'une nouvelle BDD, il ne faut surtout pas s'intéresser aux tables, mais commencer par rédiger les règles de gestion, puis établir le modèle conceptuel des données.
C'est la seule façon de s'assurer que la BDD sera conforme aux besoin métiers. Les tables ne sont qu'une conséquence d'un MCD, pas un but en soi.

Enfin, dans une gamme de fabrication, il faut connaître les composants et les composés, sachant qu'il peut s'agir d'une récursion, (un composé pouvant lui même participer à la fabrication d'un autre composé) et que certaines étapes sont successives d'autres parallélisables, il faut donc aussi gérer la notion de séquence d'opérations.
Exemple typique en cuisine : on peut commencer à faire pré-chauffer le four pendant qu'on prépare la pâte.

Citation:

---

Envoyé par tatayo

Bonjour,
La réponse est dans la question:


Il te faut ici 2 tables de plus: une table de recette (avec l'identifiant de l'article), et une table recette_ingredient qui fait le lien entre une recette et un ingrédient, dans laquelle tu peux indiquer (entre autre) la quantité de l'ingrédient en question.

Ainsi tu peux avoir autant de recettes que tu veux pour un même article, et un nombre indéfini d'ingrédients par recette.
Si besoin tu peux ajouter une contrainte d'unicité sur la table recette_ingredient, sur le couple (IdRecette, IdIngrédient), si tu veux t'assurer qu'un ingrédient n'apparait au plus qu'une seule fois par recette.

Tatayo.

---

Tout d'abord, merci pour votre réponse.

Si je comprends bien, j'aurais une table avec une ligne par ingrédient (avec le nom de la recette qui apparaît autant de fois que le nombre d'ingrédient) puis à la suite, la même chose avec la seconde recette. Chaque ingrédient et chaque recette étant dans une table différente avec un identifiant unique.

Ai-je bien compris?

Citation:

---

Envoyé par escartefigue

Bonjour,

Tout d'abord, ACCESS est un SGBD très limité en fonctionnalités et peu performant dès que le nombre d'accès concurrents est un tant soit peut significatif.
Le choisir uniquement parce qu'il est installé sur les postes de travail n'est pas forcément une bonne chose. D'autres SGBD sont gratuits et bien mieux armés pour supporter la charge.

Ensuite, quand on étudie la réalisation d'une nouvelle BDD, il ne faut surtout pas s'intéresser aux tables, mais commencer par rédiger les règles de gestion, puis établir le modèle conceptuel des données.
C'est la seule façon de s'assurer que la BDD sera conforme aux besoin métiers. Les tables ne sont qu'une conséquence d'un MCD, pas un but en soi.

Enfin, dans une gamme de fabrication, il faut connaître les composants et les composés, sachant qu'il peut s'agir d'une récursion, (un composé pouvant lui même participer à la fabrication d'un autre composé) et que certaines étapes sont successives d'autres parallélisables, il faut donc aussi gérer la notion de séquence d'opérations.
Exemple typique en cuisine : on peut commencer à faire pré-chauffer le four pendant qu'on prépare la pâte.

---

Merci pour vos conseils.

Aujourd'hui, chacun possède un fichier excel avec ses données sur son PC (fichiers structurés différemment pour chacun). Je veux juste avoir un fichier unifié sur le serveur pour que chacun encode ses données et que ces dernières soient accessibles à tous. Aujourd'hui certains fichiers excels possèdent plus de 50 colonnes avec des redondances entre les lignes. Personne dans mon équipe n'a de notions en informatiques. L'objectif est de faire quelque chose de simple et facile d'utilisation sans avoir de background en management de base de donnée. C'est aussi pour cette raison que j'ai choisi access car justement, très limité.

C'est pour une application au sein de mon équipe de travail (équipe R&D) mais son usage n'est pas professionnelle puisque nous avons un ERP qui gère toute la production de la boîte mais que nous ne pouvons pas modifier. Aujourd'hui, j'ai créé une structure avec une vingtaines de tables qui marche bien, à l'exception du problème décrit). Il y a des formulaires avec des boutons pour guider l'opérateur jusqu'au formulaire où encoder ses résultats.

Avez-vous des conseils concernant d'autres logiciel de base de données ne nécessitant pas de connaissances approfondies dans ce domaine? In fine, je souhaite que chacun ait une liste de formulaires à remplir par essai réalisé ou nouveau produit testé. Je souhaite éviter le travail directement dans les tables qui va rebuter certains de mes collaborateurs qui galèrent sur les gros tableaux excels.

Merci d'avance.

Alors si c'est un usage avec peu d'utilisateurs et donc peu d'accès concurrents, Access peut suffire.
Il aura l'avantage de présenter des formulaires faciles à utiliser.

Pour ce qui concerne la modélisation de gammes de fabrication, il y a déjà eu d'autres sujets sur le même thème dans cette section du forum, vous pourrez peut-être vous en inspirer.

Citation:

---

Envoyé par escartefigue

Alors si c'est un usage avec peu d'utilisateurs et donc peu d'accès concurrents, Access peut suffire.
Il aura l'avantage de présenter des formulaires faciles à utiliser.

Pour ce qui concerne la modélisation de gammes de fabrication, il y a déjà eu d'autres sujets sur le même thème dans cette section du forum, vous pourrez peut-être vous en inspirer.

---

Merci pour votre retour