Discussion :

[mrfof]

Salut tout le monde

Je cherche vos avis concernant un MCD de GPAO

Voici les règles de gestion :

Chaque produit a une ou plusieurs nomenclatures et gammes. Chaque nomenclature et gammes possède des détails nomenclature et détails gammes.

Les détails nomenclatures sont concerné les produits alors que les détails gammes par les opérations.

Chaque opération est exécutée sur une machine et a un coût horaire.

Chaque OF concerne un produit et une nomenclature et gamme. Un ou plusieurs employés peuvent travailler pendant un ou plusieurs OF.

Chaque employé a une catégorie d’employé.

Voici le model en image :



Dans l'application interface que j'utilise est la suivante (toujours pour que ça soit claire)



Merci

[escartefigue]

Bonjour,

Voici mes premières remarques

Chaque produit a une ou plusieurs nomenclatures et gammes. Chaque nomenclature et gammes possède des détails nomenclature et détails gammes.

Je ne suis pas expert en fabrication, mais je suis à peu près certain que la gamme de fabrication et la nomenclature doivent être deux "individus" différents ("individus" au sens merisien, c'est à dire objet de gestion intéressant dans votre univers)
Rectifiez si je me trompe, mais
La nomenclature : c'est la décomposition d'un article en composants, eux mêmes décomposés en sous-composants et ainsi de suite
La gamme : c'est le séquencement des opérations nécessaires à la fabrication d'un produit manufacturé. Pose des outils adhoc, réglage des machines, ordre d'approvisionnement des composants et des consommables...
Si c'est bien le cas, il faut donc décrire les règles relatives aux produits et gammes d'une part et aux produits et nomenclatures d'autre part, ce qui donnerait :

R01a : un produit est concerné par au moins une nomenclature
R01b : une nomenclature concerne un et un seul produit

Notez que j'ai ajouté des identifiants à vos règles, c'est bien plus facile ensuite de parler de telle ou telle règle.
Notez également que j'ai ajouté la règle pour aller de nomenclature vers produit, en effet, entre deux individus, il faut avoir la règle aller et la règle retour Ici, j'ai rédigé une règle "d'instinct" faute de directive de votre part, à corriger si besoin

même logique pour les gammes
R02a : un produit possède au moins une gamme
R02b : une gamme est possédée par un et un seul produit

Les détails nomenclatures sont concerné les produits alors que les détails gammes par les opérations.

Cette règle de gestion, ou plutôt ces règles, car il faudra décomposer, corrobore le fait que gamme et nomenclature vivent leur vie séparément
Sur le même principe que plus haut, numérotez vos règles de gestion et pensez au trajet aller et retour

Chaque opération est exécutée sur une machine et a un coût horaire.

idem qu'en est-il pour aller de machine vers opération ? très certainement qu'une machine autorise une à plusieurs opérations, mais il faut l'écrire et numéroter la règle



La relation entre OF et gamme/nomenclature m'interpelle, je pense que l'OF concerne plutôt le produit : ordre de fabriquer tant de pièces de tel produit. Règles de gestion à rédiger dans ce sens donc



En tout vous avez fait l'effort de rédiger les règles de gestion, même si vous devez les compléter et les numéroter, c'est un bon début
il y a tant d'exemples de MCD postés sans la moindre règle de gestion que je ne les compte plus

[fsmrel]

Bonsoir mrfof,

Outre les observations toujours très complètes et judicieuses d’escartefigue, je préciserai un point technique de modélisation déjà abordé avec vous.

Comme dans votre discussion précédente, on est en présence d’une boucle, impliquant cette fois-ci PRODUIT, NOMENCLATURE_GAMME et DETAIL_NOMENCLATURE.

En conséquence, on peut associer une instance dn1 de DETAIL_NOMENCLATURE à une nomenclature ng1, laquelle fait référence à un produit p1, tandis que dn1 ferait directement référence au produit p2 (association AVOIR entre PRODUIT et DETAIL_NOMENCLATURE). Pour empêcher l’anomalie de se produire, le minimum syndical technique est d’identifier NOMENCLATURE_GAMME relativement à PRODUIT :

    [PRODUIT]----0,N----(AVOIR)----(1,1)----[NOMENCLATURE_GAMME]

D’où le MLD cible permettant d’interdire l’anomalie (à adapter en fonction des observations d’escartefigue) :

[escartefigue]

Judicieuse remarque de François (FSMRel)

Et quelques éléments supplémentaire qui m'avaient échappé en première lecture :

• dans l'entité-type OF, le type de la quantité est incorrect, à remplacer par du décimal et compléter le cas échéant avec une unité de mesure de la quantité (certaines pièces sont peut être parfois fabriquées à l'unité, parfois à la centaine en fonction de l'OF...à vérifier car c'est courant dans l'industrie)
• le coût horaire positionné dans la catégorie d'employés c'est très suspect : tous les salariés d'une même catégorie sont payés exactement au même salaire, touchent les mêmes primes, ont les mêmes droits à congés ?
• dans l'entité-type detailnomenclature vous avez cette fois ci choisi de l'integer pour la quantité, pourquoi pas sous réserve que celle-ci soit toujours entière. Cela étant, je ne comprends pas ce que représente cette entité-type quelques explications seraient les bienvenues
• dans opération, si on a un coût horaire, il faut alors y ajouter une durée sans laquelle aucun calcul de coût ne sera possible

D'une façon générale, vérifiez le typage de tous les attributs, par exemple du varchar(50) systématique pour tous les attributs alpha n'est pas une bonne chose.
Le choix d'un typage adapté est important à tout point de vue (validité du contenu, performance des requêtes, économie de place disque et de charge réseau)
C'est sans doute un peu prématuré à ce stade, mais il faudra y penser avant de passer au MPD
Qui dit mesure, dit souvent unité de mesure associée. S'il n'y en a pas c'est que vous avez vérifié que cette unité est implicite et invariante.

Ce sera tout pour ce soir, bon courage pour la suite

[mrfof]

Salut tout le monde
Je me corrige moi même

Chaque produit a une ou plusieurs nomenclatures et gammes. Chaque nomenclature et gammes possède des détails nomenclature et détails gammes.

Un produit peut ne pas avoir de nomenclature & gamme (lorsqu’il n’est pas fabriqué)

Je ne suis pas expert en fabrication, mais je suis à peu près certain que la gamme de fabrication et la nomenclature doivent être deux "individus" différents ("individus" au sens merisien, c'est à dire objet de gestion intéressant dans votre univers)

je suis d’accord avec vous. D’après la définition de nomenclature et gamme, en réalité c’est des entité-type séparés.

Dans mon cas, l’entité-type gamme n’a pas de liaison directe avec produit.

Explication :

Un produit destiné à être fabriqué peut avoir une ou plusieurs nomenclature vu que la nomenclature est comme une recette, on doit préciser les étapes qui vont avec (gamme).

Donc ça revient à dire que :

1 : Chaque produit peut avoir zéro ou plusieurs nomenclatures;
2 : Chaque nomenclature est associé a un et un seul produit.

11 : Chaque nomenclature ne possède qu’une et une seule gamme,
22 : Chaque gamme ne peut être associée qu’à une et une seule nomenclature.


A savoir qu’ici je parle des entêtes gamme et nomenclature

Exemple :

Entête nomenclature 001 : code, nom, quantité de référence (cette quantité désigne le nombre de produit qu’on obtient après application de cette nomenclature lors d’un OF)

Entête gamme 001 : code, nom

Raison pour laquelle j’ai fusionné les deux entités-type, et là on parle de nomenclature & gamme de façon globale et non de façon séparée.

idem qu'en est-il pour aller de machine vers opération ? très certainement qu'une machine autorise une à plusieurs opérations, mais il faut l'écrire et numéroter la règle

Pour les opérations :

111 : Chaque opération est exécutée sur zéro ou une machine;
222 : Chaque machine peut autoriser plusieurs opérations.

La relation entre OF et gamme/nomenclature m'interpelle, je pense que l'OF concerne plutôt le produit : ordre de fabriquer tant de pièces de tel produit. Règles de gestion à rédiger dans ce sens donc

Pour l'OF :
Vu qu’un produit peut avoir plusieurs nomenclature & gamme de fabrication, pour faire un OF tu dois dire le produit, la quantité, et nomenclature & gammes à utilisé. Si chaque produit ne peut avoir qu’une seule nomenclature, tu n’as pas besoin de préciser nomenclature. Mais tel n’est pas le cas pour moi.

Je changerai mes types comme vous venez de dire.
Vous avez aussi parlé de l’unité pour OF, chaque produit possède une unité. (Unité est une entité-type qui est en relation avec produit)

le coût horaire positionné dans la catégorie d'employés c'est très suspect : tous les salariés d'une même catégorie sont payés exactement au même salaire, touchent les mêmes primes, ont les mêmes droits à congés ?

Le coût horaire dans catégorie employé me sert à calculer le coût de l’OF. Pour le faire, je suis obligé de connaitre le coût horaire des participants par catégorie pour l’OF.

Pour les opérations, j’ajouterais aussi une durée tout ça pour calculer le coût de l’OF

Comme dans votre discussion précédente, on est en présence d’une boucle, impliquant cette fois-ci PRODUIT, NOMENCLATURE_GAMME et DETAIL_NOMENCLATURE.

Je me souviens de vos conseils et je n’aurai plus de problème à ce niveau. Avec mon MLD et mon code SQL je l’appliquerais.

Ici je vois la nécessité car :

Entité-type NOMENCLATURE_GAMME n’est qu’une entête, les détails sont dans entité-type DETAIL_NOMENCLATURE et DETAIL_GAMME.
Et c’est dans DETAIL_NOMENCLATURE qu’on peut savoir quel produit est composé de quels produits avec les quantités requises.



Je vous remercie tous pour les interventions.

Maintenant ce que je vous demande est que vu ma situation est ce que c’est une bonne idée de fusionner les entêtes nomenclature et gammes et mettre en place les entités-type détails comme sur mon model, ou je dois les séparés et faire une relation de type 1,1 entre les deux ?

[fsmrel]

Bonsoir mrfof,

Maintenant ce que je vous demande est que vu ma situation est ce que c’est une bonne idée de fusionner les entêtes nomenclature et gammes et mettre en place les entités-type détails comme sur mon model, ou je dois les séparés et faire une relation de type 1,1 entre les deux ?

Vous avez écrit :

« Chaque nomenclature ne possède qu’une et une seule gamme. »

Il y a une légère ambiguïté due à l'emploi de la forme négative. Si une nomenclature possède au moins une gamme, la formulation de la règle serait plutôt celle-ci :

« Une nomenclature possède au moins et au plus une gamme. »

Vous avez écrit :

« Chaque gamme ne peut être associée qu’à une et une seule nomenclature. »

Ce qui n’interdit en rien de supposer qu’une gamme peut ne pas être associée à une nomenclature. Là encore qu’en est-il ? 0,1 ? 1,1 ?

De vos réponses dépend la modélisation des concepts de gamme et nomenclature. Soit on a injection (fusion des concepts impossible), soit on a bijection (fusion des concepts possible, mais l’entité-type qui en résulte doit comporter des attributs distincts pour la nomenclature et pour la gamme).

[mrfof]

Bonjour Fsmrel

Excusez si j’ai mal formulé

Ce qui n’interdit en rien de supposer qu’une gamme peut ne pas être associée à une nomenclature. Là encore qu’en est-il ? 0,1 ? 1,1 ?

Nomenclature -1,1---------------(posseder)-----------1,1-Gamme

1 : Une nomenclature possède au moins et au plus une gamme
2: Une gamme appartient au moins et au plus à une nomenclature

De vos réponses dépend la modélisation des concepts de gamme et nomenclature. Soit on a injection (fusion des concepts impossible), soit on a bijection (fusion des concepts possible, mais l’entité-type qui en résulte doit comporter des attributs distincts pour la nomenclature et pour la gamme).

Si vous pouvez m'éclairer sur ce dernier point que vous avez évoqué.

Merci

[fsmrel]

Nomenclature -1,1-------(posseder)-------1,1-Gamme

1 : Une nomenclature possède au moins et au plus une gamme
2: Une gamme appartient au moins et au plus à une nomenclature

Dans votre cas, il y a donc bijection.

A contrario, en supposant qu’une nomenclature pourrait ne pas avoir de gamme, alors on aurait injection :

Nomenclature-0,1-------(posseder)-------1,1-Gamme

Dans ce cas, fusionner les deux entités-types conduirait à terme à laisser le bonhomme NULL (symbolisé ci-dessous par le marqueur ??) ficher la zoubia dans la table SQL correspondante, c’est l’inhibiteur des moteurs relationnels, celui qui viole les théorèmes de la théorie relationnelle (voyez par exemple La normalisation et le bonhomme NULL et surtout les écrits de C.J. Date).

Dans l’exemple qui suit, pour le produit 1 tout va bien, par contre pour le produit 2, rien ne va plus car la nomenclature cn2 n’a pas de gamme...

NOMENCLATURE_GAMME (produitId   idNG   codeNG   nomNG    qteReference   codeGamme   nomGamme)
                    1           1      cn1      nomenc1  q1             cg1         gamme1
                    2           2      cn2      nomenc2  q2             ??          ?? 

Je rappelle aussi que NULL n’est pas une valeur, mais une sorte de marqueur totalement étranger à la théorie relationnelle (le Modèle Relationnel de Données de Codd). Pour leur part, les auteurs de la norme SQL sont tombés dans le piège en voulant rendre équivalents UNKNOWN (qui est une valeur en logique trivalente) et NULL qui n’est pas une valeur, aussi le rouge de la confusion a-t-il dû envahir leurs joues par la suite, mais les écrits restent...

Bref, pour éviter les ennuis, dans le cas de l’injection il ne faut pas fusionner les entités-types. Je vous renvoie à cette occasion au billet Join, le tueur des dinosaures.


Pour en revenir à la bijection

En théorie, on peut conserver les deux entités-types, c’est merisement et correct, et les platoniciens sont d’accord. Mais du point de vue des aristotéliciens, c’est une autre affaire, car ils mettent les mains dans le cambouis, et cette fois-ci montrent qu’on risque bien des ennuis, je vous renvoie au billet que j’ai écrit à ce sujet (Merise : cardinalités 1,1 ---- 1,1).

Le plus sage pour l’aristotélicien est de procéder à la fusion des entités-types (la coalescence pour être à la mode), ça simplifie tout et le bonhomme NULL ne peut pas se manifester puisqu’une nomenclature a nécessairement une gamme :

NOMENCLATURE_GAMME (produitId   idNG   codeNG   nomNG    qteReference   codeGamme   nomGamme)
                    1           1      cn1      nomenc1  q1             cg1         gamme1
                    2           2      cn2      nomenc2  q2             cg2         gamme2

MLD :

Vous noterez que {codeGamme} doit être clé candidate de la table NOMENCLATURE_GAMME, puisqu’une nomenclature n’a qu’une gamme.

En passant, si vous estimez qu’escartefigue et moi-même vous rendons service, n’hésitez pas à « liker » les messages qui vous sont utiles

[mrfof]

En théorie, on peut conserver les deux entités-types, c’est merisement et correct, et les platoniciens sont d’accord. Mais du point de vue des aristotéliciens,.....

Donc je suis aristotélicien ?

En passant, si vous estimez qu’escartefigue et moi-même vous rendons service, n’hésitez pas à « liker » les messages qui vous sont utiles

Je ne savais pas. Je vais liker vos explications qui m'ont aidés.

J'ai bien compris vos explications et je vous remercie tous.

[fsmrel]

Donc je suis aristotélicien ?

Au moins en bonne voie pour le devenir