Discussion :

[amelyfred]

Bonjour à tous,
J’ai pour mission de créer une base de données permettant de gérer les fabrications de produits chimiques.
J’ai déjà créé une base pour gérer la fabrication d’encre mais là c’est un peu différent. Étant totalement autodidacte, je voudrais progresser en essayant de reprendre à partir du début et en essayant de faire une bonne modélisation.
Je dirais que la base de données va être divisée en 2 parties.
-Une partie concerne les modes opératoires. Un mode opératoire est un descriptif de toutes les étapes à réaliser et les paramètres à respecter.
-La seconde partie concerne l’enregistrement des données de fabrication réelles.
Dans ce premier post, je voudrais avoir votre avis sur la partie mode opératoire.
Voici les règles de gestion que j’ai défini.

1. Un mode opératoire correspond à un article.
2. Un mode opératoire possède une date de rédaction et une date de validation.
3. Un mode opératoire est rédigé par un collaborateur.
4. Un mode opératoire est validé par un collaborateur.
5. Le collaborateur ayant validé le mode opératoire ne doit pas être identique au collaborateur ayant rédigé le mode opératoire.
6. Le mode opératoire peut posséder un nom et une description.
7. Un mode opératoire possède un numéro de version.
8. Un mode opératoire possède une ou plusieurs phases.
9. Une phase possède un nom de phase et un numéro de phase.
10. Une phase peut posséder un libellé.
11. Une phase peut être dépendante d’une ou plusieurs autres phases. Explication : La phase 1 et 2 peuvent être commencé en même temps mais la phase 3 ne peut commencer que si la phase 1 et 2 sont terminées.
12. Une phase est composée de 1 ou plusieurs opérations.
13. Une opération possède un nom d’opération, un libellé d’opération. Une opération peut posséder un libellé HSE.
14. Dans une même phase, les opérations doivent s’enchainer dans l’ordre du numéro d’opération.
15. Une opération est d’un type particulier. On peut avoir des opérations de maintien, des opérations de chargement de réacteur, des opérations de broyage, des opérations de vérifications,…
16. Une opération peut nécessiter l’utilisation d’un ou plusieurs EPI.
17. Un EPI peut être utilisé sur différentes opérations.
18. On peut lier un document à une opération (fiche technique ou procédure par exemple).
19. Un document peut être lié à plusieurs opérations.
20. Si une opération est de type vérification alors elle peut posséder un ou plusieurs libellés de vérification.
21. Sur une opération, on peut avoir un ou plusieurs paramètres. Sur un paramètres, on a une valeur cible et on peut avoir 1 borne mini de procédé, une borne maxi de procédé, une borne mini de spécification et une borne maxi de spécification.
22. Un paramètre est d’un seul type (poids, température, …).
23. Un paramètre possède une unité.
24. Un paramètre peut concerner un équipement.
25. Un paramètre peut concerner un composant (étrape de chargement de matière première).
26. Un composant peut être associé à un ou plusieurs pictogrammes.

Voici donc ce que j’ai modélisé avec MySql Workbench.
Qu’en pensez-vous ?
Merci d’avance pour vos remarques.
Fred

[escartefigue]

Bonjour,

Vos règles sont rédigées avec clarté, et numérotées c'est pratique et efficace

Par contre il aurait été plus facile de valider la modélisation en partant du MCD, il faut donc deviner les entités-types exprimées dans vos règles dans vos noms de tables ce qui est peu pratique
Il me semble que MySQL workbench ne permet pas de modéliser des MCD, mais il existe des logiciels gratuits et téléchargeables qui permettent de le faire.

Juste quelques remarques :

A priori, un mode opératoire n'a pas d'existence propre, il disparait si l'article disparait, vous auriez donc pu identifier le mode OP relativement à l'article (concept d'entité faible)
L'identifiant mode op serait dans ce cas le couple identifiant article + identifiant mode op

Dans l'autre sens, vous avez modélisé une cardinalité mini 1 coté article vers mode op, ne pouvez vous pas avoir d'article, nouveau par exemple, sans mode-op ?

Je crois comprendre que les tables en périphérie du modèle sont des tables de typologie. Si c'est bien le cas, il faut prévoir une cardinalité mini de zéro, toute typologie n'étant pas forcément utilisée à un instant "t"

[amelyfred]

Bonjour,
Merci pour vos réponses.
Je vais donc essayer de refaire le mcd.
Par contre, je ne comprends pas l'histoire du mode opératoire qui n'a pas d'existence propre.
Pourrais tu m'en dire un peu plus?

Merci d'avance
Fred

[escartefigue]

Bonsoir,

Une entité faible est une entité-type dont l'existence dépend d'une autre, j'avais pris pour exemple les lignes de facture (entité-type faible) qui n'ont pas de sens sans la facture à laquelle eelles sont associées (l'entité type forte)
Sauf que dans votre cas j'ai été un peu vite en besogne, certes, le mode op n'a pas de sens faute d'article, mais peut être voulez vous conserver des modes op dont les articles n'existent plus

[amelyfred]

Bonjour
J'ai donc essayer de faire le MCD

Je ne sais pas comment faire pour indiquer que le collaborateur qui rédige ne doit pas être celui qui valide le mode opératoire.

Merci d'avance pour vos remarques.
Fred

[amelyfred]

Bonjour à tous,
J'ai apporté une petite modif et je voudrais avoir votre avis.

Dans mon mode opératoire, une opération peut être de type chargement. Dans ce cas, on a un paramètre (indiquant la quantité à charger) qui est lié à un composant.
Dans ce cas particulier j'ai besoin de connaitre à quel emplacement sera consommé le composant.
Sur une même opération, le composant ne peut être consommé qu'à un seul emplacement. Mais un composant peut être consommé à des emplacements différents sur 2 opérations différentes.
J'ai donc lié l'emplacement à l'opération.
Est ce que ca vous parait cohérent?



Merci d'avance pour vos différents commentaires.
Fred

[escartefigue]

J'ai donc essayer de faire le MCD

Je n'arrive pas à déchiffrer ce qui est écrit, bizarrement le zoom est inopérant sur l'image

Je ne sais pas comment faire pour indiquer que le collaborateur qui rédige ne doit pas être celui qui valide le mode opératoire.

C'est une contrainte d'intégrité fonctionnelle (CIF) de type exclusion qui se modélise par un X cerclé reliant les 2 relations

Comme ceci :


comme je n'arrive pas à lire votre MCD, j'ai mis des noms et cardinalités "comme je le sentais", en l'occurrence 1 seul valideur maxi, plusieurs rédacteurs possibles

[amelyfred]

OK Merci

C'est quand j'export mon MCD que ca devient illisible.
Je vais essayer de faire autrement
Fred

[amelyfred]

Bonjour
J'utilise JMerise mais je n'arrive pas a avoir une image plus sympa.
Avez vous une idée pour avoir une image plus sympa?
Fred

[escartefigue]

Bonjour,

Peut être tout simplement en découpant votre MCD en 2 parties ?

[amelyfred]

Est ce plus lisible?

[escartefigue]

Désolé mais non, toujours pareil, le zoom est inopérant quelque soit le navigateur

[Zizoua]

Bonsoir!
Si vous faites une capture d'écran puis vous collez dans paint sans modification, il sera peut être claire.
Merci par avance.

[amelyfred]

Bonjour,
J'ai fait 2 copies ecran :




J'ai essayé le zoom et ca marche.

Fred

[amelyfred]

Bonjour à tous,
Je reviens vers vous pour une autre partie de mon projet pour lequel j'ai dû mal à trouver la meilleur façon de modéliser.

-Nous avons donc un mode opératoire qui est composé de 1 ou plusieurs phase.
-Chaque phase est elle même composée d'une ou plusieurs opérations.
-Sur une opération, il peut y avoir plusieurs paramètres.
-Un paramètre va avoir notamment 1 valeur de spec mini et une valeur de spec maxi.
-Un produit fabriqué possède une numéro de lot, une date de début de fabrication, une date de fin de fabrication.
-Ce produit est fabriqué selon un seul mode opératoire.
OK donc voilà ce que ça donne actuellement :


Voilà ce que je souhaite modéliser.
En général, on fabrique plusieurs produits avec le même mode opératoire à la suite. On appelle cela une campagne. Chaque produit aura un numéro de lot différent.
Sur une campagne, on peut être amené à ajuster certains paramètres d'opérations. Si un paramètre est spécifié alors c'est ce dernier qui devra être pris en compte et non celui indiqué dans le mode opératoire.
Voici un exemple :
Pour fabriquer le produit A, je dois avoir une température comprise entre 10 et 20°C (spec mini et spec maxi)
J'ai une campagne prévue pendant laquelle je dois fabriqué 4 produits A (Lot1/Lot2/Lot3/Lot4)

Et donc je souhaite que pendant cette campagne, la température de fabrication soit comprise entre 10 et 15°C pour la fabrication du lot 1 et 2 et entre 15 et 20°C pour la fabrication du lot 3 et 4.

Voilà ce que j'ai essayé de modéliser mais je ne sais pas si c'est la meilleure solution.



Merci d'avance pour votre aide précieuse.
Fred

[escartefigue]

Bonjour,

Désolé je suis très peu dispo en ce moment, submergé par un tsunami d'incidents à résoudre

Juste quelques remarques très rapides

- Vous n'abordez pas la nomenclature, or c'est l'une des mamelles incontournables de la gestion de production, ce sous-ensemble est il traité dans une autre BDD ?
a ajouter d'urgence sinon (avec probablement de gros impacts sur le MCD)
- Attention aux synonymes, vous parlez d'équipements dans les règles, et une entité-type "materiel" semble y correspondre dans le schéma, st-ce bien la même chose
- Attention aussi au format des données, le float a pour vocation de stocker des grands nombres sous forme de puissance de 10, mais il est peu précis, je ne pense pas que ce soit adapté pour gérer des quantités à produire.
- vu que les mode op ont des versions, on peut supposer que certaines versions qui étaient valides ne le sont plus, remplacées par de nouvelles version, il faudrait donc qu'un attribut "code validité" et/ou une date de fin de validité soient ajoutés dans l'entité-type "mode operatoire" (le fait qu'il ait été validé à un moment, visible dans la relation avec le collab, ne suffisant pas)
- la cardinalité de la règle 18 (1) ne correspond pas à celle du schéma (n)

[amelyfred]

Bonjour
Merci pour tes réponses.
-La nomenclature est gérée dans l'ERP. Dans la nomenclature, on somme par composant, alors que dans cette application un même composant peut être utilisé sur plusieurs opérations. De même, dans notre ERP, la nomenclature tient compte des composants qui vont entrés dans le nettoyage des appareils. Et l'application que je développe ne prend pas cela en compte. Donc oui j'en ai tenu compte et je pensais que 'lon n'en avvait pas besoin mais je vais me reposer la question.
-Effectivement je n'avais pas vu que j'employais 2 terme pour la même chose. Je vais donc rectifier.
-Pour le type de données. Il vat mieux que je mette en décimal alors?
-Bien vu pour les versions, je m'étais appercu qu'il manquait quelque chose et j'avais ajouté une entité EtatModeOp mais ton idée de date de validité me semble intéressante.
-Ok : en fait c'est que l'on peut lié plusieurs documents à une même opération.

Encore merci et bon courage pour ton tsunami ;-)

Je reviens vers vous si j'ai d'autre question.

Fred