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

[narutobaka]

Bonjour

J'essaye d'avancer sur le schéma EA associé à la gestion de mon formulaire.

en espérant des réactions constructive

merci d'avance

[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.

[billharry]

OK,

je te prépare une réponse

[billharry]

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.

Si tu as une table de fournisseur, je te conseille une saisie/conversion en majuscule ou minuscule, comme ça le format sera toujours le même.
Avec un écran de recherche du style le nom commence par ... (comme ça pas besoin de mettre le nom complet, donc moins d'erreur d'approximation), recherche par ville ou département... (une peu comme pagejaune )

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 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.

Juste pour info un MCD est un Modèle Conceptuel de Données, donc un outil pour modéliser les concpets que sont les Entités et Relations donc MCD=EA.
Ton dernier graphe est un MPD (Modèle Physique de Données) qui sert à modéliser les objets physiques, donc les tables, vues etc...

La différence entre 1,N et 0,N est sémantique et se retrouve plus au niveau des contrôles de saisie dans le logiciel et du code qu'au niveau de la base de données.
1,N signifie que pour 1 utilisateur tu as au minimum 1 demandeur. Il ne peut donc pas exister un utilisateur qui n'est pas demandeur.
0,N signifie qu'il peut n'y avoir aucun demandeur pour un utilisateur donné.
Relationnellement parlant, cela signifie que pour la relation 1,N la transaction gérant l'insert pour la création de l'utilisateur comprend également l'insert pour la création du demandeur (ils sont donc créés en même temps). Pour la relation 0,N il s'agit de 2 transactions distinctes

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.

C'est un choix, je le respecte

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

Tout dépend de ce que tu as besoin de stocker en base.
Dois-tu conserver la trace de chaque participation à la saisie du bon? Si oui, il vaut mieux avoir une relation saisie avec un attribut date_saisie entre les différentes entités intervenantes et le bon de peinture

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.

La relation saisie peut être utilisée

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.

En UML tu as le diagramme d'état qui te permet de mieux suivre ça.
Dans ton cas tu peux prévoir une entité Etat liée au bon pour te permettre de voir où en est chaque bon
N'hésite pas à faire le diagramme de traitement pour mieux visualiser les acteurs, les états et pour bien clarifier les choses avec ton responsable.

Bon courage

[narutobaka]

Bonjour,

Et encore une fois merci à toi de prendre du temps pour examiner mon "casse tete chinois"

Si tu as une table de fournisseur, je te conseille une saisie/conversion en majuscule ou minuscule, comme ça le format sera toujours le même.
Avec un écran de recherche du style le nom commence par ... (comme ça pas besoin de mettre le nom complet, donc moins d'erreur d'approximation), recherche par ville ou département... (une peu comme pagejaune )

Je pense que si je crée une table pour les fournisseurs, il s'agira d'une table préremplit et mise à jour. L'utilisateur ne pourra que choisir dans une une liste de choix le fournisseur.
Car même avec un écran de recherche, il faudra stocker préalablement les données pour qu'à la saisie des premiers caractères, une liste de choix s'affiche.
A moins de laisser les utilisateurs saisir les fournisseurs, et que dans le cas ou un fournisseur n'a pas encore été saisie, l'utilisateur crée l'entrée dans la base de donné. Si ensuite un autre utilisateur saisie les premiers caractères du précédents fournisseurs saisies il pourra le choisir. Le soucis c que rien n'empêchera l'utilisateur de générer une nouvelle entrée et donc on retourne dans le cas des doublons.

1,N signifie que pour 1 utilisateur tu as au minimum 1 demandeur. Il ne peut donc pas exister un utilisateur qui n'est pas demandeur.
0,N signifie qu'il peut n'y avoir aucun demandeur pour un utilisateur donné.
Relationnellement parlant, cela signifie que pour la relation 1,N la transaction gérant l'insert pour la création de l'utilisateur comprend également l'insert pour la création du demandeur (ils sont donc créés en même temps). Pour la relation 0,N il s'agit de 2 transactions distinctes

C'est plus clair dans ma tête. Il faudra donc gérer cette différence par programme.
Le schéma que je présente par contre est fait avec designer Fork et il fait tout seul le passage au modèle physique mais à la base je travaille encore sur le Schéma EA. Je sais pas si il y a un moyen de l'empêcher de passer en modèle physique

Tout dépend de ce que tu as besoin de stocker en base.
Dois-tu conserver la trace de chaque participation à la saisie du bon? Si oui, il vaut mieux avoir une relation saisie avec un attribut date_saisie entre les différentes entités intervenantes et le bon de peinture

En effet il faut garder une trace de participation à la saisie du bon.
Par exemple la date de saisie pour une partie peut etre differente de la date saisie pour une autre partie. L'utilisateur pourra aussi être différent en fonction des parties.

J'avoue cependant avoir du mal à voir comment gérer l'attribut date de la relation saisie.
A savoir comment je vais devoir le gérer en passant au modèle Physique de donnée.

En UML tu as le diagramme d'état qui te permet de mieux suivre ça.
Dans ton cas tu peux prévoir une entité Etat liée au bon pour te permettre de voir où en est chaque bon
N'hésite pas à faire le diagramme de traitement pour mieux visualiser les acteurs, les états et pour bien clarifier les choses avec ton responsable.

Je viens de recevoir cette reponse de l'un de nos formateur

Bonjour,


Je ne pense pas que ce schéma soit particulièrement judicieux. Il ressemble plutôt à un schéma des cas d’utilisation en UML. Tu as établit des relations entre les 2 « cotés » du schéma et il serait peut-être plus correct de vérifier les différentes imbrications entre les entités…

N’hésites pas à m’envoyer une autre vérsion.

En fait avant de passer au schema EA, j'ai fait une analyse ,je joins d'ailleur les différents cas.

Maintenant je ne sais pas si il s'agit d'un schéma des cas d'utilisations UML.
Et surtout je ne sais pas encore comment le traduire dans le schema EA.

En tout cas un enorme merci pour ton aide

j'ai encore du pain sur la planche et je n'est pas encore bien en main la BDD.

++

[billharry]

Et encore une fois merci à toi de prendre du temps pour examiner mon "casse tete chinois"

pas de problème. Ca fait du bien de travailler sur différents problèmes pour revoir ses connaissances et ça permet de s'améliorer

Je pense que si je crée une table pour les fournisseurs, il s'agira d'une table préremplit et mise à jour. L'utilisateur ne pourra que choisir dans une une liste de choix le fournisseur.
...
A moins de laisser les utilisateurs saisir les fournisseurs, et que dans le cas ou un fournisseur n'a pas encore été saisie, l'utilisateur crée l'entrée dans la base de donné. Si ensuite un autre utilisateur saisie les premiers caractères du précédents fournisseurs saisies il pourra le choisir. Le soucis c que rien n'empêchera l'utilisateur de générer une nouvelle entrée et donc on retourne dans le cas des doublons.

Prévoie un rôle d'administrateur. Ceux qui auront ce rôle seront responsables de la saisie des données fournisseurs et donc seront garants de la cohérence des données.
Physiquement, le rôle d'administrateur peut être donné en positionnant un flag dans la table des utilisateurs (donc un attribut admin, pour vérifier s'il peut saisir ou non...)

Le schéma que je présente [...] est fait avec designer Fork et il fait tout seul le passage au modèle physique mais à la base je travaille encore sur le Schéma EA. Je sais pas si il y a un moyen de l'empêcher de passer en modèle physique

Je ne connais pas ce logiciel, donc je ne peux malheureusement pas t'aider.

En effet il faut garder une trace de participation à la saisie du bon.
Par exemple la date de saisie pour une partie peut etre differente de la date saisie pour une autre partie. L'utilisateur pourra aussi être différent en fonction des parties.
J'avoue cependant avoir du mal à voir comment gérer l'attribut date de la relation saisie.
A savoir comment je vais devoir le gérer en passant au modèle Physique de donnée.

Je crois comprendre que les demandeurs sont des utilisateurs, tout comme les différentes entités de contrôle.
Si tel est le cas, tu peux créer la relation
bon_peinture-1,N----Saisie----0,N-Utilisateur
avec l'entité saisie ayant l'attribut date_saisie
Physiquement tu auras une table avec une clé primaire id_SAISIE (clé technique), une colonne saisie_date et une clé unique id_BON_PEINTURE et id_UTILISATEUR

En fait avant de passer au schema EA, j'ai fait une analyse ,je joins d'ailleur les différents cas.

Maintenant je ne sais pas si il s'agit d'un schéma des cas d'utilisations UML

Il ne s'agit pas d'un schéma normalisé, mais le principale est qu'il soit compréhensible par tous.
Un modèle conceptuel de traitement te permettrait de mieux organiser tes enchainements et te permettrait d'y voir plus clair en ayant tout dans un seul schéma (cherche des cours sur merise pour t'aider un peu)

En tout cas un enorme merci pour ton aide

j'ai encore du pain sur la planche et je n'est pas encore bien en main la BDD.

++

De rien, et tiens moi au courant de tes avancées

[narutobaka]

Bonjour,

Je reprends mon projet suite à une alternance dans ma formation.

J'ai discuté de mon schéma avec mes formateurs qui m'ont conseillés de regrouper en une seule table, les différentes parties de mon formulaire.
Je joins le dernier schéma.

Prévoie un rôle d'administrateur. Ceux qui auront ce rôle seront responsables de la saisie des données fournisseurs et donc seront garants de la cohérence des données.
Physiquement, le rôle d'administrateur peut être donné en positionnant un flag dans la table des utilisateurs (donc un attribut admin, pour vérifier s'il peut saisir ou non...)

La gestion des utilisateurs et leur droit sont gérés avant leur insertion dans la base. En fait mon logiciel intranet est un module d'un ensemble gérant la sécurité et les accès. L'authentification se fait directement depuis active directory.

Je ne connais pas ce logiciel, donc je ne peux malheureusement pas t'aider.

Quel logiciel de représentation de schema EA utilises-tu?

Il ne s'agit pas d'un schéma normalisé, mais le principale est qu'il soit compréhensible par tous.
Un modèle conceptuel de traitement de permettrait de mieux organiser tes enchainements et te permettrait d'y voir plus clair en ayant tout dans un seul schéma (cherche des cours sur merise pour t'aider un peu)

D'après ce que j'ai cru comprendre il ne semble pas exister de régle de passage d'un MCT vers un schéma EA.
J'ai essayé d'en commencer un. Cependant j'avoue que je patauge encore. Je suis en train de chercher des exemples avec des cas concrets. Par contre je voulais savoir si il fallait représenter les cas dans différents schémas ou les représenter dans un et un seul schéma?

J'ai réussit je pense, à faire une représentation dans ma base de l'enchainement des étapes en fonction du type de bon, cependant je gérerai certains enchainement par programme.

Par contre je ne sais pas si je dois lier la partie du formulaire à celle de gestion des étapes/type_bon /Tache.

Encore merci pour ton aide.

cordialement

[billharry]

J'ai discuté de mon schéma avec mes formateurs qui m'ont conseillés de regrouper en une seule table, les différentes parties de mon formulaire.

C'est un choix.
J'suis pas pour, car ça centralise les besoins en performance sur une table (foie de DBA)

Quel logiciel de représentation de schema EA utilises-tu?

Power AMC, sinon Poseidon pour UML

D'après ce que j'ai cru comprendre il ne semble pas exister de régle de passage d'un MCT vers un schéma EA.

Effectivement, mais ça aide à fixer les idées et à faire ressortir des besoins et donc des concepts

Par contre je voulais savoir si il fallait représenter les cas dans différents schémas ou les représenter dans un et un seul schéma?

Le plus lisible est de faire un diagramme qui lie/enchaine les différent cas, et ensuite un diagramme par cas

Par contre je ne sais pas si je dois lier la partie du formulaire à celle de gestion des étapes/type_bon /Tache.

A chaque étape tu as un bon, une tache, donc c'est un concept à part entière, donc une entité...

[narutobaka]

Bonjour,

Je reviens sur l'analyse de ma base de donnée.

C'est un choix.
J'suis pas pour, car ça centralise les besoins en performance sur une table (foie de DBA)

Je suis en train justement de réflechir au avantage et inconvénient de revenir sur un schéma en éclatant la table Bon_peinture comme je l'avais fait au départ.

Je posterai ma réflexion par la suite.

Je suis preneur de toute élément me permettant de faire une analyse plus fine et le cas échéant de retravailler ma base

merci d'avance pour votre aide.

+++

[narutobaka]

bonjour,

Voilà mon analyse quand à la nécessité d'éclater la table bon_peinture.

1- Un certain nombre de champs resteront vide dans la table si elle reste en un seul bloque

2- Evolution de la base en cas de nécessité d'ajouter une nouvelle partie au bon.
Si on éclate la table il suffira de recréer une clef étrangère et de créer une nouvelle table
Si on garde une table unique on rajoute directement les champs dans la table => on se retrouvera avec un certain nombre de champs a vide pour rien

3- Taille maximum d'une ligne de 8Ko sous Mssql 2005

4- On ne peut utiliser qu'un timestamp par table.

voila voila

Si qqn à d'autre remarque sur ce point je suis preneur

++ all