Discussion :

[narutobaka]

Bonjour

Je travail actuellement sur un schéma EA :

voici en gros à quoi ce rapporte ce schéma EA :

Un utilisateur crée un nouveau bon peinture. Il est le « demandeur » du bon peinture. Il saisit les informations obligatoires : date, nom du demandeur, nombre, numéro de BB, teinte, ref et delais permettant le traitement de la pièce. Il peut aussi indiqué le secteur, le code R3, le nombre de pièce urgente, la désignation complète le fournisseur et une observation qui sont des informations falcultatives.

Il existe un cas « particulier » : la demande pour pièce abîmé sur chaine. L’utilisateur du magasin indiquera pour ce cas si la pièce abîmée est disponible ou non en magasin :

Si elle disponible :
- il y aura un echange de pièce.
- La production qui est le demandeur dans ce cas la récupérera la pièce et indiquera les informations réservés au destinataire de la pièce : Date, et nom, données obligatoire puis le secteur et une observation qui sont des informations facultatives

Si elle ne l’est pas la pièce reprend le processus normal.

Un utilisateur peinture saisit les informations et indique si le bon est valide ou non : elle indique la date et son nom puis indique si la partie demandeur est valide :
Si le bon est valide elle indique un délai de traitement de la pièce.
Sinon elle attend la modification du bon .

Un utilisateur peinture suite au traitement de la pièce remplit les indications observations et temps passé pour le traitement de la demande.

Enfin l’utilisateur destinataire remplit les informations de la partie destinataire : Date, et nom, données obligatoire puis le secteur et une observation qui sont des informations facultatives

Le traitement du bon peinture est terminé

Voici mon schéma EA : en pièce jointe.

J'ai déjà une question pour le passage au MCD concernant les clefs étrangères :

Selon mon schéma et les cardinalités quel sont la / les clés étrangères que je devrai indiquer dans la table BON_PEINTURE. Devrai-je juste indiqué la clé primaire de chacune des parties du bon ? ou le couple id_utilisateur/id_partie_du_bon

Je sais pas si j'ai été clair.

N'hésitez pas à demander des précision.

Je vous remercie d'avance pour vos propositions constructives

cordialement

[billharry]

Salut,

Je n'ai vu ton post que aujourd'hui, donc voici mes premières remarques

Un utilisateur crée un nouveau bon peinture. Il est le « demandeur » du bon peinture. Il saisit les informations obligatoires : date, nom du demandeur, nombre, numéro de BB, teinte, ref et delais permettant le traitement de la pièce. Il peut aussi indiqué le secteur, le code R3, le nombre de pièce urgente, la désignation complète le fournisseur et une observation qui sont des informations falcultatives.

Pour le fournisseur, il n'y a pas de liste, il tape ce qu'il veut?

Un utilisateur peinture saisit les informations et indique si le bon est valide ou non : elle indique la date et son nom puis indique si la partie demandeur est valide

Je n'arrive à pas à trouver l'état "validité", hors ça semble être important, car ça définit le res te du processus

Le processus de traitement n'est pas aisé. Il sera utile que tu fasse un modèle de traitement; ça pourrait aider (toi comme les lecteurs) à mieux comprendre

[narutobaka]

Bonjour

Et merci d'avoir réagit à mon post.

Pour le fournisseur, il n'y a pas de liste, il tape ce qu'il veut?

Pour l'instant non il s'agit d'une donnée qui est saisie par l'utilisateur sans liste. Si par contre plus tard je dois le gerer via une liste de choix je devrais créer une table de fournisseur mais pour l'instant ce n'est pas prévu.

Le processus de traitement n'est pas aisé. Il sera utile que tu fasse un modèle de traitement; ça pourrait aider (toi comme les lecteurs) à mieux comprendre

En effet le modèle de traitement n'est pas aisé, même pour moi. De plus certain élément reste à valider par le chef du projet qui profite encore pour quelque jour de ses vacances.

Je vais résumer le modéle de traitement :

1 / Un utilisateur initialise la création du bon et remplit la partie demandeur
1'/ Cet utilisateur saisit aussi la tache associé à ce bon parmis les choix possibles du type de bon (le type de bon définissant les taches possibles)

2/ Un message d'alerte mail prévient la peinture de la création d'un nouveau bon pour validation.

- Si le bon n'est pas validé par la peinture ( attribut controle de la table controle_peinture), le demandeur du bon est avertit par mail et on repart en 1 /

- Si le bon est validé par la peinture le demandeur du bon est avertit par mail avec certaines précisions sur le traitement et le bon passe a l'étape suivante

3/

Cas général :
La peinture remplit la partie peinture du bon suite au traitement


3'/

Cas particulier d'une demande faite par la production :
Le magasin est prévenu par mail, et indique dans la partie contrôle du magasin si la pièce est en stocke.

4'/

* Si la pièce est en stocke en magasin, il y a un échange effectué.
-La pièce abimé reprend le cursus normale de traitement 3/
Dans ce cas la ce n'est donc plus la pièce abimé qui retourne sur chaine, la pièce abimé une fois peinte retournera en stock.

- Le destinataire_prod de la pièce saisie les informations du DESTINATAIRE_PROD


* Si la pièce n'est pas en stocke la pièce abimé reprend le cursus normale de traitement 3/.

4/ Le destinataire de la pièce saisie la partie DESTINATAIRE du bon est finalise la demande.

Concernant le modèle de traitement je me pause d'ailleur des questions quand à son "stockage" ou plutot sa gestion de passage entre les phases. A savoir si je le gère via le code php, ou via une "structure" dans la base de donnée qui permettrai de rendre l'application plus fléxible et de faire des modifications sans avoir besoin de modifier la programmation php.

Mon Schéma EA est loin d'être finalise , et c'est bien pour cela que je demande des avis sur ce forum.

Merci de votre attention

[billharry]

Merci pour les précisions, je regarde ça

[billharry]

Pour l'instant non il s'agit d'une donnée qui est saisie par l'utilisateur sans liste. Si par contre plus tard je dois le gerer via une liste de choix je devrais créer une table de fournisseur mais pour l'instant ce n'est pas prévu.

Un conseil, mieux vaut intégrer cette table maintenant, surtout que tu enregistres déjà les valeurs saisies.
Mettre à jour un modèle une fois que l'application est utilisée est toujours complexe et cher (réfères toi aux divers coûts de maintenance et développement et tu verras).

1 / Un utilisateur initialise la création du bon et remplit la partie demandeur

* Je suppose que demandeur.date_demandeur est équivalente à la date de création. Si tel est le cas, OK.

* Attention à la cardinalité de ta relation utilisateur--demandeur. Il peut y a voir un utilisateur qui n'est pas demandeur. Si cet utilisateur vient juste d'être ajouté, il n'est pas encore demandeur. Hors dans ta cardinalité, cette situation est impossible (un utilisateur est au moins 1 fois demandeur...)

* Je ne comprends pas la cardinalité de la relation bon_peinture--demandeur... Un demandeur peut faire plusieurs bons de peinture? mais alors quelle est la différence avec l'utilisateur. J'avais cru comprendre 1 demandeur par bon de peinture...

1'/ Cet utilisateur saisit aussi la tache associé à ce bon parmis les choix possibles du type de bon (le type de bon définissant les taches possibles)

ça me semble OK

2/ Un message d'alerte mail prévient la peinture de la création d'un nouveau bon pour validation.

Faut-il enregistrer l'envoi du mail pour avoir une trace?
Si oui, il faut créer une entité mail associée au bon de peinture

- Si le bon n'est pas validé par la peinture ( attribut controle de la table controle_peinture), le demandeur du bon est avertit par mail et on repart en 1 /

Faut-il enregistrer l'envoi du mail pour avoir une trace?
Si oui, il faut associer l'entité mail citée ci-dessus associée au contrôle de peinture

- Si le bon est validé par la peinture le demandeur du bon est avertit par mail avec certaines précisions sur le traitement et le bon passe a l'étape suivante

L'entité mail devient franchement indispensable, car ça revient régulièrement, c'est donc un besoin fort => donc une entité
Il faut associer l'entité mail citée ci-dessus associée au contrôle de peinture

3/ Cas général :
La peinture remplit la partie peinture du bon suite au traitement

ça me semble OK

3'/ Cas particulier d'une demande faite par la production :
Le magasin est prévenu par mail, et indique dans la partie contrôle du magasin si la pièce est en stocke.

Le mail, toujours le mail... à associer au magasin, au bon...
Il faut donc prévoir des relations de type destinataire et de type envoyeur

4'/
* Si la pièce est en stocke en magasin, il y a un échange effectué.
-La pièce abimé reprend le cursus normale de traitement 3/
Dans ce cas la ce n'est donc plus la pièce abimé qui retourne sur chaine, la pièce abimé une fois peinte retournera en stock.

Je ne vois pas de trace de l'échange. Je pense qu'il faut prévoir une entité échange

- Le destinataire_prod de la pièce saisie les informations du DESTINATAIRE_PROD

ça me semble OK

* Si la pièce n'est pas en stocke la pièce abimé reprend le cursus normale de traitement 3/.

ça me semble OK

4/ Le destinataire de la pièce saisie la partie DESTINATAIRE du bon est finalise la demande.

ça me semble OK

Concernant le modèle de traitement je me pause d'ailleur des questions quand à son "stockage" ou plutot sa gestion de passage entre les phases. A savoir si je le gère via le code php, ou via une "structure" dans la base de donnée qui permettrai de rendre l'application plus fléxible et de faire des modifications sans avoir besoin de modifier la programmation php.

La flexibilité est primordiale, car ça réduit le coût des développements futurs.
En plus je suis DBA, donc je préfère la solution base de données :D

J'espère que ces quelques remarques vont t'aider

[narutobaka]

Bonjour,

et encore merci à toi de me faire par de tes remarques constructives.

Un conseil, mieux vaut intégrer cette table maintenant, surtout que tu enregistres déjà les valeurs saisies.
Mettre à jour un modèle une fois que l'application est utilisée est toujours complexe et cher (réfères toi aux divers coûts de maintenance et développement et tu verras).

Je suis tout à fait d'accord.
Si par la suite la liste des fournisseurs devait être remaniée, il suffirait de faire une correspondance entre les anciens intitulés saisis par les utilisateurs et les nouveaux, leur relation dans la partie du bon demandeur n'étant pas affectée.
Par contre le traitement, lui le serait, si l'on repassait par un mode de choix dans une liste de sélection, en passant d'un simple champs texte à une liste de choix.

Le soucis avec les fournisseurs, vu qu'il s'agit d'une donnée saisie par l'utilisateur, comment gérer le problème de syntaxe approchée pour le nom d'un même fournisseur :
-Ce dernier pourrait être saisie tout en majuscule ou juste avec la première lettre en majuscule ( ceci n'est pas le cas le plus embetant il suffirait de tout passer en majuscule avant l'insertion dans la BDD)
-La saisie pourrait être faite avec des abbréviations ou des caractères spéciaux "&" à la place de "et" etc .

On pourrait se retrouver avec plusieurs syntaxes pour le même fournisseur et ainsi avec une table fournisseur complètement ingérable.

J'en arrive à l'idée que pour les fournisseurs, l'utilisateur fasse un choix parmis une liste proposée. Il faut que j'en reparle avec le chef de projet pour faire le choix.

* Je suppose que demandeur.date_demandeur est équivalente à la date de création. Si tel est le cas, OK.

En effet il s'agit bien de la date de création du bon peinture.

* Attention à la cardinalité de ta relation utilisateur--demandeur. Il peut y a voir un utilisateur qui n'est pas demandeur. Si cet utilisateur vient juste d'être ajouté, il n'est pas encore demandeur. Hors dans ta cardinalité, cette situation est impossible (un utilisateur est au moins 1 fois demandeur...)

Je voulais savoir si une cardinalité O,N à la place d'une cardinalité 1,N affecterai le passage de la clef étrangère. Je m'inspire du cours de Bdd http://www.isima.fr/~rey/cours/ea/IntroductionEA.pdf page 17 pour le passage du schéma EA au MCD et ce cas avec O,N d'un coté de la relation et 1,1 de l'autre n'est pas abordé.
Car en effet il y a des utilisateur qui ne seront jamais demandeur. Je vais revoir ce point et voir qu'elle modification ça implique.

* Je ne comprends pas la cardinalité de la relation bon_peinture--demandeur... Un demandeur peut faire plusieurs bons de peinture? mais alors quelle est la différence avec l'utilisateur. J'avais cru comprendre 1 demandeur par bon de peinture...

La table demandeur représente la partie demandeur du formulaire.
Il existe effectivement une seule partie demandeur par bon_peinture. Ca devrait donc être une relation 1,1--1,1.
Mais il s'agit d'un cas qui ne devrai pas exister d'après ce que j'ai compris.
Le soucis c que je suis obliger de différencier les différentes parties du formulaire, car ces différentes parties ne sont pas saisies par les mêmes utilisateurs. L'utilisateur X remplit la partie demandeur, l'utilisateur Y remplit la partie peinture etc.
A vrai dire j'avais utilisé la relation (bon_peinture) 1,1--1,n(demandeur) pour avoir un lien grâce aux clefs étrangères.

Je ne sais pas si il existe un autre moyen d'exprimer cette relation :

Un utilisateur remplit la partie demandeur du bon peinture.
Et surtout comment exprimer que l'utilisateur saisissant la partie demandeur du bon peinture sera différente de la personne saisissant la partie peinture ou destinataire

Faut-il enregistrer l'envoi du mail pour avoir une trace?
Si oui, il faut créer une entité mail associée au bon de peinture

Concernant l'envoie de mail, oui il s'agit d'un élément important du projet. Entre chaque phase de saisie du bon il s'agit du support d'information permettant d'indiquer l'état d'avancement du bon :

J'ai d'ailleur oublié le mail envoyé aux destinataires dans le point 4' et le point 4.

Il est vrai que je n'ai pas encore réfléchit aux données nécessaires à stocké pour les envoies de mail et aux relations entre la table mail et les autres éléments de la base de donnée. Il faut que je réflechisse encore à ce point

Envoyé par narutobaka Voir le message
3/ Cas général :
La peinture remplit la partie peinture du bon suite au traitement

Pourtant la aussi il existe un soucis au niveau de la cardinalite comme pour la relation bon_peinture--demandeur. Il s'agit du même problème et je ne sais pas non plus quel est le meilleur moyen pour le représenter.

Je ne vois pas de trace de l'échange. Je pense qu'il faut prévoir une entité échange

La seul trace de l'echange est l'état à 0 ou 1 de la valeur de controle de la Table CONTROLE_MAGASIN. Il n'y a pour l'instant pas d'autres informations.
Il faudra d'ailleur que je demande si il doit y avoir plus d'information concernant les pièces échangé.

Citation:
Envoyé par narutobaka Voir le message
Concernant le modèle de traitement je me pause d'ailleur des questions quand à son "stockage" ou plutot sa gestion de passage entre les phases. A savoir si je le gère via le code php, ou via une "structure" dans la base de donnée qui permettrai de rendre l'application plus fléxible et de faire des modifications sans avoir besoin de modifier la programmation php.

La flexibilité est primordiale, car ça réduit le coût des développements futurs.
En plus je suis DBA, donc je préfère la solution base de données

Pour la gestion du modéle de traitement je ne sais pas encore comment le représenter. Pour l'instant j'ai deux indicateurs me permettant de "savoir" ou en est le bon "le type_bon" et "l'étape". Il faut encore que je réfléchisse à la manière de stocker les étapes en fonctions des différents types de bon dans la base de donnée.

J'espère que ces quelques remarques vont t'aider

Ce qui est sur c que tes remarques m'ont apporté un autre regard sur mon schéma qui je le sais est trés loin d'être complet.

Surtout au niveau de la représentation des différentes parties du bon, je ne vois pas trop. Ca ressemble à une identification un peu comme le Cas d'un épisode par rapport à une Série. Si qqn à une idée à ce sujet pour avoir une représente logique correcte je suis preneur.