Discussion :

[Diestys]

Bonjour,

Je souhaite créer une base de données sur les produits chimiques d'une entreprise qui ait différentes fonctionnalités :
- Il faut que la base de données contiennent toutes les informations liées aux produits
- Il y a beaucoup d'informations sur chaque produit
- A noter qu'il y a aussi les dangers des produits, et qu'il y en a plusieurs par produits (problème de relation ...plusieurs à plusieurs?)
- Il faut que la ou les table(s) puissent être rempli via un formulaire (ne pas avoir besoin de retourner dans les tables pour remplir)
- Il faut que l'on puisse consulter certaines informations des produits directement dans access via un formulaire de menu général
- Il faut qu'on puisse créer une sorte de fiche recap des informations produit qui se génère automatiquement quand on marque le nom du produit dans le menu principale, une fiche imprimable
- Il faut que l'on puisse archiver/mettre à jour les données via une requete ou formulaire


Voila mon but !

Maintenant ma question c'est déjà savoir si tous les objectifs si dessus sont atteignables avec Access ? Mais je me suis renseigné et normalement Oui ! (ce qui fait que je garde le choix d'access !)
Du coup, je souhaite surtout savoir comment vous voyez la structure de ma base de données ? Combien de tables ? Quels types de relations ?

J'ai déjà fais plusieurs essai :
- Une table avec un maximum d'information, et que des tables "Liste" à coté pour aider à remplir la table principale
- J'ai eu des soucis pour mes relations à cause du fait qu'il y ai plusieurs dangers, phrase de danger, plusieurs EPI, par enregistrements.
Ca me faisait faire plusieurs fois apparaitre la même tables "Liste de dangers" dans les relations par exemple, et dans ma table principale : dangers 1, dangers 2, dangers 3, etc.
- Une table avec maximum d'information mais toutes les colonnes redondantes ont été séparé pour remplir des tables de jointure pour assurer les relations plusieurs à plusieurs entre les tables de dangers et produits par exemple.
- Je pense que c'est la bonne structure, mais du coup j'ai des soucis pour créer mes requetes/formulaires... notamment pour l'archivage et la mise à jour.

Bref j'aimerais votre avis pour savoir comment atteindre les objectifs ci dessus, savoir si je pars dans le bon sens ou si je dois totalement tout repenser Je peux vous fournir exactements les types de données que je souhaite dans mes tables si besoin, pour que ce soit plus clair !

Merci d'avance de votre aide !

EDIT : J'espère que je poste ce message sur la bonne section/bon forum ! Je suis un peu désespérer de trouver des personnes qui connaissent access dans mon entourage donc je m'en remet à vous ! n'hésitez pas à me dire si ce message n'a pas sa place ici

[marot_r]

Bonjour.

Oui tu vas pouvoir faire tout cela avec Access ou n'importe quelle base de données du marché.

Que vas-tu faire de ces informations. Est-ce pour une simple consultation de la fiche ou est-ce pour faire des "mélanges" ?

Au niveau structure, à priori, j'irai vers :

tblProduit
ClefProduit
CodeProduit
NomProduit

tblPropriete
ClefPropriete
NomPropiete
CodeTypeValeur (Texte, peut être TEXTE, ENTIER, REEL, BOOLEEN, MEMO)

tblProprieteProduit
ClefProprieteProduit
ClefProduit
ClefPropriete
ValeurTexte (texte, 255c)
ValeurEntier (entier long)
ValeurReel (Reel double)
ValeurBooleen
ValeurMemo (Memo)

• en relation avec tblProduit
• en relation avec tblPropriete

tblDanger
ClefDanger
NomDanger
DescriptionDanger (Mémo)

tblDangerProduit
ClefDangerProduit
ClefDanger
ClefProduit

• en relation avec tblProduit
• en relation avec tblDanger

Cette structure permet de gérer un nombre presque infini de propriétés et de dangers par produit.

A+

[Diestys]

Merci de ta réponse rapide et précise !

Je vois le genre de table, cette structure permet de former des tables jointures c'est ca ? DangerProduit par exemple serait une table de jointure, une sorte de relation plusieurs à plusieurs ?

Avec cette méthode, je vois pas trop comment je vais gérer l'archivage de mes données ?

J'avais créer une structure de ce type, ou j'avais gardé un tableau "principale" pour regrouper mes données uniques à chaque produit, et des tableau "listes" ainsi que des tables de jointures pour toutes les caractéristiques qui reviennent plusieurs fois pour un produit (genre Dangers, EPI, etc)



Qu'en pensez-vous ?

Le but est d'avoir toutes les données concernant les Produits chimiques de l'usine :
- Pouvoir ajouter des enregistrements dans les tables
- Pouvoir consulter les données, imprimer des fiches résumés, des étiquettes,
- Archiver/mettre à jour toutes les info d'un produit
- Créer une table qui résume toutes les données des produits dans un seul et même tableau (via une requete par exemple) dans le but de basculer ces données dans un autre outil si besoin plus tard.

Merci de votre aide précieuse je ne suis pas expert d'access et je suis un peu submergé mais vraiment impatient car je vois le potentiel de cet outil !

[marot_r]

Bonjour.

Ma solution est simplement plus générique que la tienne mais l'architecture est semblable.
Si ta décomposition est finale, alors garde la.
Si tu pense que tu pourrais avoir encore beaucoup d'autres type d'information complémentaires, alors peut-être qu'une solution du type :

tj_ProduitPropriete
ClefProduitPropriete
ClefProduit
ClefGroupePropriete
ClefProptiete
ValeurTexte (texte, 255c)
ValeurEntier (entier long)
ValeurReel (Reel double)
ValeurBooleen
ValeurMemo (Memo)
ValeurDateHeure

Éviterai d'avoir à ajuter des tables et modifier ton application.

Et tes listes deviendraient

Produit

Groupe Propriété

Liste des propriétés du groupe

C'est très souple mais cela a un gros défaut, il devient difficile de présenter les données "en colonne" du type Produit, Propriété1, Propriété2, ..., PropriétéN.
Et faire des recherches simultanément sur plusieurs propriétés est plus complexe.

Avec cette méthode, je vois pas trop comment je vais gérer l'archivage de mes données ?

Je ne suis pas certain de ce que tu entends pas "Archivage".
Est-ce que tu veux que les informations concernant un produit soit retire de l'application mais toujours consultable ?
Est-ce que tu veux garder un historique des différentes versions d'un même produit ?

Si tu pouvais donner un exemple cela aiderait sans doute.

Pour faire les listes tu pourras utiliser un rapport qui présente les informations de ta table principale et des sous-états qui vont présenter les informations des tables Tj-....

Cela ressemblerai à

Produit : ici les information fixes

Danger

Liste des dangers

EPI

Liste des EPI

et ainsi de suite.

De même pour avec un formulaire (et sous-formulaire) pour faire la saisie.

Combien as-tu de produits ?

A+

[Diestys]

Merci pour ces info !

Alors effectivement le but de l'archivage c'est de pouvoir garder en mémoire toutes les informations d'un produit sur une période donnée :

Exemple : l'alcool ethylique
On va avoir une FDS (fiche de données de sécurité) qui va etre créer en 2010 admettons. Elle contient pleins d'info sur le produit : les dangers, les EPI a porter, le point éclair, etc. De mon coté je vais rajouter des informations sur l'utilisation qu'on en fait dans l'usine.
En 2017 on peut très bien recevoir une nouvelle FDS de l'alcool qui va changer certaines propriété, ou alors notre utilisation de l'alcool va etre différente. Alors la je dois procédé à la mise à jour des données du tableau, mais en gardant les anciennes données et surtout la période de validité des données.
Le but est de pouvoir dire si tel ou tel salarié a été exposé a tel produit et donc tels dangers/risques pendant tel periode.

Concretement jusqu'a maintenant on utilisé un fichier excel tout basique, on avait un tableau avec toutes les informations de type : "en colonne" du type Produit, Propriété1, Propriété2, ..., PropriétéN. comme tu l'as précisé quoi !
Mais rien était automisé dans ce tableau, donc les étiquettes, les fiches simplifiés, toutes les lignes du tableau, tout ça était rempli à la mano et ca pouvait prendre énormement de temps en double saisie. L'archivage était simple par contre, une nouvelle version de FDS, une nouvelle ligne et on masquait l'autre.

La mon objectif est de passé sur une base de données access pour s'occuper de tout ça le temps de tout transférer après sur notre outil de gestion des risques (qui est en développement). Cette base sera donc une base de transition, mais aussi une base de secours.

Pour être sincère, vu que je ne suis pas expert d'access, je me dis que c'est beaucoup de boulot pour une simple base de transition secours. Mais le système actuelle ne convient pas du tout, et les possibilités que m'offrent access sont trop tentantes pour ne pas vouloir m'y intéresser. Je me rend bien compte cependant que j'ai du pain sur la planche ! c'est pas le temps passé qui m'inquiète, c'est surtout le fait de n'avoir personne qui puisse me "coacher" sur mes demandes access ! haha d'où ma venue ici

Voilà, j'espère que la situation est plus claire maintenant !

Le nombre de produit c'est environ 150-200 je pense.

La c'est vraiment cette histoire de plusieurs dangers par produit qui me met dans le jus...
Produit

Propiété1

Propiété2

Propiété N

Dangers1

Dangers2

etc.

Mais j'aime bien cette idée de rapport qui rassemble toutes les informations dans un tableau, ca me permettrait une transition simple et efficace avec l'autre outil.

EDIT : Du coup, cette base est vouer à être utiliser sur une période donnée, et garder en secours. Si je me rend compte dans les semaines qui viennent que c'est vraiment trop une usine a gaz, que c'est trop compliqué à développer (et donc adapter si besoin plus tard), j'envisagerais peut être une autre méthode de transition. Mais c'est pas mon but pour l'instant car access rempli tous les critères que je souhaite pour une transition. Je souhaite approfondir le plus possible et étudier relativement rapidement la faisabilité (avec mon niveau access) de faire cette base.

[marot_r]

OK et merci de ces explications.

Personnellement j'irai pour ajouter une date début et une date de fin à chacune des tables qui pourrait contenir plusieurs "Version".

Un truc du genre :

Tj_Dangers
Nom_Du_Prpoduit
Dangers
DateDebut (valeur par défaut 0001-01-01, même si personnellement je préfère 1901-01-01).
DateFin (valeur par défaut 9999-12-31)

Comme cela tu peux garder facilement un historique de tes dangers. Dans ton état ou ton formulaire de consultation, tu n'afficherai que celui dont la date de fin est la plus grande.

Note qu'on pourrait le gérer avec une seule date (date de début) mais cela complique la recherche quand on veut trouver quelle information était valide à une date donnée.
Il est très facile de faire [TaDateVoulue] between [DateDebut] and [DateFin], plus délicat (et moins rapide) de faire entre cette date et la date qui suit.
Évidement il faut faire attention à la saisie pour ne pas créer de recouvrement de période.

La c'est vraiment cette histoire de plusieurs dangers par produit qui me met dans le jus...

Ta structure gère déjà plusieurs dangers pour un même produit.

Ta table Tj_Dangers permet cela avec une ligne pour chaque danger et chaque période de danger (à ajouter).

• Acide sulfurique, Pictogramme_Explosif, 1901-01-01, 9999-12-31
• Acide sulfurique, Pictogramme_Explosif, 1901-01-01, 9999-12-31

A+

[Diestys]

AHHHH tu m'as donnée une idée, plutot que de gérer par date, on pourrait gérer par numéro de version ?

Je met un nouveau numéro de version dès qu'on a une nouvelle FDS, et avec ce numero de version je pourrai archiver toutes les données qui correspondent à une version non ?

Genre dans ma Tj_Danger, je pourrais archiver les enregistrements de la version 1 de l'acide sulfurique ! ca se fait ça non ?

Par contre, vu qu'il y a plusieurs ligne d'enregistrement dans ma table de jointure, ça ne sera pas possible d'afficher toutes les caractéristique d'une version d'un produit sur une seule ligne d'un tableau Archive, non ?

A+

[marot_r]

Bonjour.

Oui tu peux remplacer les dates par une version, c'est la même idée.
Ceci dit tu as parlé de recherche pour savoir si un employé avait été exposé donc je pense qu'il faut garder quelque part une notion de date.
Je vois mal faire comment faire une recherche du type "Il y a 10, quelles étaient les normes en vigueur." sans cela.

Par contre, vu qu'il y a plusieurs ligne d'enregistrement dans ma table de jointure, ça ne sera pas possible d'afficher toutes les caractéristique d'une version d'un produit sur une seule ligne d'un tableau Archive, non ?

On peut mais c'est un peu plus complexe que de présenter les infos une ligne en dessous de l'autre.
Y aurait-il un problème à avoir quelque chose comme :

En vigueur

Norme4
Norme5
Norme6

Précédemment

Norme1
Norme2
Norme3

plutôt que :

En vigueur

Norme4
Norme5
Norme6

Précédemment

Norme1, Norme2, Norme3

A+

[marot_r]

Bonjour.

Le message Problématique de structure de B.D. pour la gestion des produits chimiques aussi! a été déplacé ici https://www.developpez.net/forums/d1...its-chimiques/ pour lui donner plus de visibilité.

A+