Discussion :

[methodecontrole]

Bonjour à tous !

J’ai comme projet de créer une base de données permettant de suivre un stock d'outils.

Voici mon projet actuel (en cours d’élaboration) :

Gestion de Stock.7z

Il est composé de :
- Une table T_Stock, qui contient tous mes outils avec leurs informations de base.
- Une table T_Mouvement, qui enregistre les entrées et sorties des outils.
- Une table T_Stock_Horn.
- Une table T_Stock_Plaquette.
- 2 Formulaire F_Entrée et F_Sortie, pour déclarer un mouvement d’outil (vers la table T_Mouvement, en fonction des outils contenus dans T_Stock).

Pour le moment cette base permet de répertorier tout les outils, et de gérer les mouvements.


Je souhaiterais ajouter un formulaire de recherche multicritère, afin de trouver un ou plusieurs outils adaptés en fonction de caractéristiques renseignée dans des listes déroulante.
Le problème est que ces "types" de caractéristiques varient en fonction du type d’outil, et je voudrais éviter que la table T_Stock contienne une quantité démesurée de champs, dont la plupart resteraient vides.

Pour résoudre ce problème, je pensais créer plusieurs tables, une pour chaque type d’outil, avec des champs correspondant à leurs caractéristiques spécifiques, tout en trouvant une solution pour qu’elles alimentent la table principale T_Stock.
La recherche d’outils se ferait alors dans la catégorie concernée, avec la table, le formulaire et les types de caractéristique concernée.
Les mouvements de stock continueraient à être déclarés dans la table T_Mouvement, en se basant sur les outils référencés dans T_Stock.

Cependant, étant débutant sur Access et les bases de données en général, j’ai peur que cette solution soit trop complexe ou ou bloquante en raison des relations et des redondances entre les différentes tables.

Qu’en pensez-vous ? Créer des tables pour chaque type d’outil vous semble-t-il adapté ? Ou vaudrait-il mieux chercher une autre architecture ?

Merci à tous, et bonne fêtes

[f-leb]

Bonjour,

Tu te poses les bonnes questions

C'est le genre de problèmes que l'on retrouve régulièrement, et tu trouveras des réponses dans cet article (un peu théorique) Héritage dans une base de données Access.

L'exemple de l'article est différent, une histoire d'intervenants qui sont soit des salariés, soit des indépendants, mais la nature du problème est identique : des outils qui sont soit des tournevis, soit des marteaux, soit...

Trois réponses possibles :

• Généralisation : une seule table T_Outils avec un champ TypeOutil ;
• Spécialisation totale : une table par type d'outil (une table T_marteau, une table T_tournevis, etc.) ;
• Spécialisation sur le modèle du MCD : avec des relations « un à un », la plus optimisée mais pas forcément la plus simple à gérer sous Access.

Je te laisse voir les avantages et inconvénients Le problème de ces modèles est qu'il faut modifier le schéma relationnel si tu as de nouveaux types d'outils. Combien de types d'outils tu as ?

[methodecontrole]

Salut f-leb
Je te remercie pour ces infos pertinentes !
Après avoir lu tout ça, je commence à y voir plus clair ! Même si j’avoue ne pas bien tout comprendre en détail vu mon niveau

Mais au moins, j'ai de quoi progresser !

Généralisation :
Si je comprends bien, la première solution consisterait à avoir une seule table pour tous les outils et toutes leurs caractéristiques, et à distinguer leur type uniquement dans les formulaires qui affichent uniquement les caractéristiques adaptées à chaque type d'outil ?

Cela me semble être plus simple à gérer, car moins de tables et de relations. Par contre, sans utiliser des requêtes et des formulaires, la visibilité et les modifications des données seront très pénibles ?

Spécialisation totale :
Cela semble correspondre à mon idée de tables indépendantes, et comme j'ai pu m'en rendre compte lors d'essais, la clé primaire est une contrainte pour éviter les redondances ! Tous les critères communs actuellement dans ma table principale devront être renseignés dans la table correspondant au type d'outil.

- La solution de créer différentes plages de référence pour les types d'outils paraît simple et pratique.
Par contre, cela limiterait le nombre d'outils de chaque catégorie. Sachant que je serai amené à créer beaucoup de catégories différentes, certaines bien remplies et d'autres non...

- La seconde possibilité consiste à "dénuer de sens la clé primaire".
Si je comprends bien, il s'agit de laisser des clés primaires générées automatiquement dans chaque table, et de les relier avec la table commune via une seconde clé, avec du code VBA pour générer et lier les informations ?
Cela me paraît plus pratique que la méthode de généralisation, mais quels en sont les inconvénients ? Il est question de "peut s'avérer très vite critique dès que la base est attaquée par une application tierce". J’avoue ne pas bien comprendre, il s'agit de fiabilité contre des attaques potentielles et malveillantes ?

-La dernière solution, (pour ce que j'en comprends), serait d'utiliser une table principale pour générer des clés primaires, et ensuite d'utiliser cette clé dans les tables de type outils ? Mais comme indiqué, cela oblige à rentrer d'abord une nouvelle ligne dans la table principale, puis dans la table secondaire. En cas de modification, la cohérence doit être maintenue manuellement et peut être source d'erreurs. Quelles solutions peuvent être envisagées pour automatiser et limiter les erreurs ?

Spécialisation sur le modèle du MCD :
Cela ressemble à mon idée d'avoir une table commune avec les informations communes, et des tables pour les informations complémentaires.
Pour le moment, cette solution me paraît plus compliquée. Peut-être vaut-il mieux que j'explore et comprenne mieux les premières solutions avant d'aller plus loin ?


Honnêtement, je ne saurais pas dire combien e type d'outil je vais créer exactement. Le but de la base de données est aussi dans un premier temps d'aider à y voir plus clair dans tout ça !
Mais je dirais minimum 500 tous types confondus, et ~ 10 types d'outil différent. Sachant que je serai amené à rajouter de nouvelles catégories, et pourquoi pas compter autre chose que des outils, comme de l'outillage, de la matière, différents consommables...

Si je n'utilise plus de table générale avec les informations communes, je devrais modifier mes formulaires de mouvement, afin de rechercher une référence dans plusieurs tables. Comment faire cela ?

Pour le moment, j'en suis au stade de développement, mais aussi d'apprentissage. Je cherche une architecture qui soit simple, évolutive et non bloquante pour des améliorations futures (Enfin, le meilleur compromis possible).

Pour commencer et par simplicité, je suis tenté d'utiliser la méthode de spécialisation totale, avec des plages de référence dédiées. J'ai un peu peur des contraintes d'évolution pour les nouveaux types d'outils, mais je devrais déjà pouvoir en faire pas mal avant d'être limité.
Afin de faciliter les mouvements d'entrée et de sortie, je pense à garder une table générale, qui serait alimentée automatiquement par tous les "types d'outils". Les informations communes seraient renseignées dans les tables "types", et récupérées dans la table commune.
Est-ce une bonne idée, ou est-ce plus compliqué que de rechercher dans toutes les tables avec les formulaires ?
Es-ce que les méthodes avec la "seconde clé primaire" qui fait le lien, ou la clé primaire généré par une table dédiée serait beaucoup plus compliqué?

Encore merci pour tes conseil, ça m'aide y voir plus clair

[Paprick]

Bonjour,

Le choix de la solution devra essentiellement être guidé par l'évolution possible du nombre de types d'outils... en effet, il est difficile d'imaginer qu'il faille modifier la structure de la BD à chaque nouveau type d'outils...
Théoriquement, la conception de la base doit passer par une connaissance complète du système d'information.

Quoiqu'il en soit, la première étage doit se situer au niveau conceptuel : je vous recommande donc fortement de commencer par l'élaboration du modèle conceptuel de données (MCD), le schéma relationnel pouvant ensuite être dérivé automatiquement.

Bonne continuation !

[f-leb]

[...]Mais je dirais minimum 500 tous types confondus, et ~ 10 types d'outil différent. Sachant que je serai amené à rajouter de nouvelles catégories, et pourquoi pas compter autre chose que des outils, comme de l'outillage, de la matière, différents consommables...

À chaque fois que tu rajoutes un nouveau type, il faut ajouter et bidouiller des tables, modifier les requêtes, les formulaires et les états. Et ce n'est pas l'utilisateur de la base qui va le faire, mais seulement le développeur (qui va peut-être se lasser de toutes ces modifications).

Il faut peut-être repenser le modèle et à chaque fois que tu penses avoir besoin d'ajouter une table, voir comment tu peux les transformer en lignes de tables.
Si tu as des caractéristiques, il faut une table T_caracteristique à associer à la table T_TypeOutil, puis enregistrer les valeurs des caractéristiques dans T_valeurCaracteristique à associer..., etc.

Quoiqu'il en soit, la première étage doit se situer au niveau conceptuel : je vous recommande donc fortement de commencer par l'élaboration du modèle conceptuel de données (MCD), le schéma relationnel pouvant ensuite être dérivé automatiquement.

Au hasard, avec Looping !

[marot_r]

Bonjour, juste mon point de vue basé sur mon vécu.
Perso je préfère la solution 1 seule table, plusieurs formulaires ou un seul formulaire avec des contrôles qui se cachent selon les besoins.
Il est assez facile de cacher des champs dans un formulaire, beaucoup plus que d'ajouter des tables et des requêtes.
Ça garde une structure de base simple et on peut utiliser toujours les mêmes requêtes, juste filtrées par type.
La seule attrape c'est la taille, si tu as 3 champs utilisés sur 100 pour chaque type d'outil, ça peut te faire perdre pas mal de place.
Rappel une BD Access ne peut pas dépasser 2 Go et il est prudent de rester au max à 1.9 Go voir 1.5 Go car Access gère TRÈS mal la saturation.

Une solution que j'ai du employée car j'avais vraiment une structure très variables et évolutive est la technique des attributs, avec un truc du genre
Code Article, Code Attribut, Type Attribut, Valeur Attribut (texte).
Avec une table qui défini la liste des attributs par type d'article.
C'est super souple mais c'est un peu la galère quand tu dois mettre tes données en colonne du genre
Code Article, Attribut1, Attribut2, ..., AttributN.
Ça se fait en générant les tables résultats avec du VBA mais ça reste lourd.

A+

[methodecontrole]

Bonjour à tous

Bonne année pour commencer

Merci à tous pour vos réponse, c’a m'aide à y voir plus clair et chercher dans la bonne direction !

Pour le moment je suis parti sur une table unique, avec des formulaire dédié au différent types d'outil, principalement par simplicité de programmation
Cela va me permettre de rapidement mettre en route un première version de la base de donné, avec uniquement quelques type d'outil.

Mais je garde en tête vos conseils, et je commence en parallèle à me renseigner sur le modèle MCD pour version plus évolué et complète!

Je vous donnerais des nouvelles sur l'avancement du projet !