Discussion :

[RZinaoui]

bonjour,
Je l'ai téléchargé
j'ai essayé de faire de mon mieux mais je n'ai pas pu faire la relation ternaire. Je ne sais pas comment peut on la réaliser sur ce logiciel. Elle existe entre ARTICLE, UTILISATION et FORME.

[fsmrel]

Bonjour,

Vous créez la table UTILISER (vide donc).

Vous tirez un lien identifiant entre UTILISER et ARTICLE en cliquant d’abord sur UTILISATION puis sur ARTICLE : automatiquement MWB recopie la clé primaire d’ARTICLE dans UTILISER.



Vous recommencez l’opération pour tirer un lien identifiant entre UTILISER et FORME.

Vous recommencez l’opération pour tirer un lien identifiant entre UTILISER et UTILISATION.

[RZinaoui]

Merci fsmrel,

[fsmrel]

Bonsoir RZinaoui,

Votre post-scriptum était hors charte et un modérateur a évidemment fait le ménage. Vous pouvez néanmoins faire figurer à nouveau votre diagramme MySQL Workbench qui est tout à fait légal.

Et lisez attentivement la charte DVP...

[RZinaoui]

Bonsoir,
Je comprends : )
Voilà la partie qui concerne la FORME et la CONVERSION ainsi que la relation ternaire entre ARTICLE, FORME et UTILISATION.

Qu'en pensez-vous les lions ?

[Kropernic]

Bah du coup, y a pas le mld complet.

Mais déjà, ça ne me plait pas trop. La table conversion est sensée est une table résultante d'une association réflexive plusieurs à plusieurs et il n'y a qu'une seule liaison... Rien que ça déjà, ça pue ^^

[RZinaoui]

Bonjour Krop
Oui, je n'ai pas fait gaff, voilà le MCD ainsi que le MLD:
MCD


MLD

[fsmrel]

Bonjour,


Quelques précisions avant de regarder cette histoire de formes.

Merise 2 est simplement la 2e version de Merise (1). C'est une mise à jour de la norme (est-ce le bon terme) Merise.

Dans la FAQ Merise, D. Nanci raconte la genèse de la méthode et ce qui la caractérise.

j'utilise à présent MySqlWorkBench qui est certes beaucoup moins complet que PowerAMC (j'imagine que PowerMCD en est un dérivé) mais qui présente l'avantage d'être gratuit. Par contre, lui ne fait pas de MCD. Il faudra modéliser directement à l'étape du MLD.

DB-MAIN (gratuit) permet de modéliser des MCD (et permet de prendre en compte l’héritage, l’identification relative, les CIF et tout ça...) C’est un AGL sérieux, de l’Université de Namur.



Dans les gratuits, il y a encore Open ModelSphere qui permet de faire des MCD merisiens (un peu pénible lors du passage au MLD).

On parle donc de la relativité d'une clé étrangère par rapport à une clé primaire qu'on trouve en MLD.

Évitez d’interpréter les concepts et de faire des mélanges quant aux niveaux.
L’identification relative est définie au niveau conceptuel. Quand vous parlez de clé étrangère, vous parlez de contrainte référentielle au niveau MLD ou SQL et, lors du passage d'un niveau à l'autre, la conséquence de l’identification relative (comme de l’héritage) est que la clé primaire de la table référencée correspond à un sous-ensemble de la clé primaire de la table référençante (sous-ensemble strict dans le cas de l’identification relative).

j'aurai besoin d'un écran Plasma pour ce MCD + quelques jours de planification pour placer les entités au bon endroit. C'est trop !

Ne vous inquiétez pas, un MCD ça s’urbanise : on en fait des sous-ensembles auxquels on affecte autant de chefs se projets qui évidemment se synchronisent pour que ça ne soit pas la foire dans la base de données.

Si j’ai bien compris, la CIF est la seule méthode qui pourrait nous permettre de récupérer cette information.

Avec MySQL Workbench, les CIF sont traitées de façon très simple, car l’en-tête d’une table contient l’ensemble des attributs (colonnes) parties prenantes dans cette affaire.

Ainsi, la CIF


Y est ainsi exprimée :



Ce qui montre bien que FournisseurId ne fait pas partie de la clé primaire de la table DEMANDE_ARTICLE.

[RZinaoui]

Bonjour,

Quelques précisions avant de regarder cette histoire de formes.

J'attend votre intervention avec impatience

Évitez d’interpréter les concepts et de faire des mélanges quant aux niveaux.
L’identification relative est définie au niveau conceptuel. Quand vous parlez de clé étrangère, vous parlez de contrainte référentielle au niveau MLD ou SQL et, lors du passage d'un niveau à l'autre, la conséquence de l’identification relative (comme de l’héritage) est que la clé primaire de la table référencée correspond à un sous-ensemble de la clé primaire de la table référençante (sous-ensemble strict dans le cas de l’identification relative).

C'est bien compris : )

Ne vous inquiétez pas, un MCD ça s’urbanise : on en fait des sous-ensembles auxquels on affecte autant de chefs se projets qui évidemment se synchronisent pour que ça ne soit pas la foire dans la base de données.

Ce qui montre bien que FournisseurId ne fait pas partie de la clé primaire de la table DEMANDE_ARTICLE.

Oui je vous capte, vous avez bien expliqué la CIF avant .. Merci encore une fois

[Kropernic]

Pour l'association convertir, en l'état, j'ai un souci...

En l'état, on va savoir par exemple qu'un paquet peut être converti en barrette(s) ou en mètre(s) (ou en autre chose) mais on a aucune idée du combien...

Avant de vous donner une solution toute faite, je vous laisse méditer là-dessus.

[RZinaoui]

En l'état, on va savoir par exemple qu'un paquet peut être converti en barrette(s) ou en mètre(s) (ou en autre chose) mais on a aucune idée du combien...

Non, il n'y qu'une seule forme de sortie pour chaque article.
Soit il sort sous forme d'unité (Pompe, vérin, filtre, etc) ou bien en détails (huile, diesel, câble, etc)
Pour le combien, je crois que je devais ajouter une propriété appelée Quantité qui va stocker cette information.

P.S: Je pense que c'est pour cette raison que j'ai mis spontanément une relation un à plusieurs au début car une forme peut être convertit en une seule forme

[Kropernic]

Vous ne comprenez pas où je veux en venir...

Vous commandez un article X (disons du pétrole pour l'exemple) et vous recevez 5 barils.

Vu que vous distribuez le pétroles non pas par barils mais par litre, il faut pouvoir faire la conversion.

C'est bien beau de savoir qu'un baril "devient" des litres mais faut-il encore savoir combien.

Sinon comment allez-vous faire pour savoir quelle quantité de pétrole (en litre) vous avez encore en stock.

[RZinaoui]

Je vais expliquer ma manière de voir les choses et c'est à vous de juger ...
Considérons ce schéma:


Prenons un article X:
D'après ce MCD, l'article X se trouve sous une forme Y. Supposons que cette forme est: Un paquet (supposons qu'un paquet contient 100 éléments)
Dans la table ARTICLE, on va faire:
ArticleId: X
FormeId: 1

Dans la table FORME, on aura:
FormeId:1
FormeQteIn: unité (càd qu'un paquet correspond à une unité)

Dans la table CONVERSION, on aura:
ConversionId:1
FormeId:1
ConversionQteOut: 100

On a fait donc la conversion. Pour savoir combien d'éléments on a utilisé de l'article X, la propriété Quantité_utilisée de l'association Utiliser va nous en informer.

Qu'en pensez-vous ?

[Kropernic]

Il y a définitivement quelque chose qui ne me plait pas avec cela.

J'ai actuellement du pain sur la planche de mon propre côté. J'y regarderai en détail dès que j'aurai un peu de temps à y consacrer.

En attendant, je vous laisse faire murir ce concept et je guette l'intervention de fsmrel.

[RZinaoui]

Vous m'avez oublié
Je sais que vous êtes occupés, mais ce MCD touche à sa fin .. Merci de m'aider pour le reste .

[fsmrel]

Bonsoir,


Je ne vous oublie pas, mais j'ai été particulièrement occupé hier et aujourd'hui et n'ai pu consacrer qu'un peu de temps à hmimoud.

Vous avez fait figurer le prix unitaire des articles au niveau d’ARTICLE, tandis que pour ma part je l’ai fait figurer au niveau de FOURNIR (cf. le message #50) : si donc deux fournisseurs fournissent le même article, vous devrez en fait définir deux articles car les prix ne sont pas nécessairement les mêmes pour des fournisseurs différents. Quelle est votre position ?

Il n'y qu'une seule forme de sortie pour chaque article.
Soit il sort sous forme d'unité (Pompe, vérin, filtre, etc.) ou bien en détails (huile, diesel, câble, etc.)

D’accord, un article a une seule forme dans le cas des sorties, mais qu’en est-il en entrée ? Un article peut-il avoir plusieurs formats possibles en entrée ?

Dans votre dernier MLD, l’association « Se trouver » connectant ARTICLE et FORME caractérise-t-elle la forme de l’article en sortie ? (Je rappelle que vous avez écrit qu’un article n’a qu’une forme de sortie). Si ce n’est pas le cas, l’association « Se trouver » caractériserait donc la forme en entrée de l’article, c'est-à-dire qu’un article n’aurait qu’une forme en entrée... Merci de répondre avec précision.

Votre table UTILISER a pour clé primaire {ArticleId, UtilisationId, FormeId}, en vertu de quoi à un article peuvent correspondre plusieurs formes, or il s’agit manifestement de formes en sortie : si c’est bien cela, alors il y a une contradiction avec votre énoncé : « Il n'y qu'une seule forme de sortie pour chaque article ».

L’association réflexive CONVERTIR me fait tiquer, car elle exprime une nomenclature. Je verrais plutôt une table des formats en entrée plus une table des formats en sortie et une association entre les deux pour définir la quantité correspondante (cardinalités max à fournir et justifier par règles de gestion) :

[FORMAT_ENTREE]--1,?-----(CONVERTIR{Quantite})----1,? --[FORMAT_SORTIE]

Quel inconvénient y voyez-vous ?

[RZinaoui]

Bonsoir,
Vous avez fait figurer le prix unitaire des articles au niveau d’ARTICLE, tandis que pour ma part je l’ai fait figurer au niveau de FOURNIR (cf. le message #50) : si donc deux fournisseurs fournissent le même article, vous devrez en fait définir deux articles car les prix ne sont pas nécessairement les mêmes pour des fournisseurs différents. Quelle est votre position ?

Oui vous l'avez déjà expliqué dans le message #14 et je l'ai bien compris. Je suis tout à fait d'accord avec toi et je ne me rappelle pas l'avoir mis comme propriété de l'entité-type ARTICLE après ton message #14.

D’accord, un article a une seule forme dans le cas des sorties, mais qu’en est-il en entrée ? Un article peut-il avoir plusieurs formats possibles en entrée ?

Aux dires du responsable du magasin, un article n'a qu'une seule forme d'entrée.

Si ce n’est pas le cas, l’association « Se trouver » caractériserait donc la forme en entrée de l’article, c'est-à-dire qu’un article n’aurait qu’une forme en entrée... Merci de répondre avec précision.

Voilà c'est ça, un article n'a qu'une seule forme d'entrée et je l'ai précisé par les cardinalités (1.1)
Pour cette association, j'y ai pensé comme ça: Un article se trouve dans le stock sous une forme (celle de son entrée) mais il en sort sous une autre forme. Par exemple, on peut trouver l'huile sous forme des bidons (1.1) mais plusieurs articles peuvent être sous la forme d'un bidon (1.n)

Votre table UTILISER a pour clé primaire {ArticleId, UtilisationId, FormeId}, en vertu de quoi à un article peuvent correspondre plusieurs formes, or il s’agit manifestement de formes en sortie : si c’est bien cela, alors il y a une contradiction avec votre énoncé : « Il n'y qu'une seule forme de sortie pour chaque article ».

Oui effectivement, ça ressemble bien à l'exemple de: pour 1 demande et 1article ==> un seul fournisseur !
Le problème que j'avais rencontré c'est que PowerAMC n'offre pas la possibilité de faire une CIF sauf si j'utilise une liaison avec une couleur rouge comme vous l'avez fait pour m'expliquer .

L’association réflexive CONVERTIR me fait tiquer, car elle exprime une nomenclature. Je verrais plutôt une table des formats en entrée plus une table des formats en sortie et une association entre les deux pour définir la quantité correspondante (cardinalités max à fournir et justifier par règles de gestion) :
Quel inconvénient y voyez-vous ?

ça doit être comme ça:

[FORMAT_ENTREE]--1,1-----(CONVERTIR{Quantite})----1,1 --[FORMAT_SORTIE]

Si vous regardez mon message #65, vous remarquez que j'ai mis FormeID dans la table ConversionID parce que j'ai pris en considération que la relation existant entre les deux tables était un à un mais Krop avait autre chose à me dire !

Cordialement

[fsmrel]

Bonsoir,

Aux dires du responsable du magasin, un article n'a qu'une seule forme d'entrée.

Soit, mais « Verba volant, scripta manent » : Il faut que le responsable du magasin signe cette règle, lui mette un coup de tampon, car plus tard s’il se plaint parce qu’il n’y a qu’une forme en entrée pour un article, s’il rouspète, il ne devra s’en prendre qu’à lui-même plutôt qu’au seul RZinaoui (je parle d’expérience, et croyez-moi ça calme l’interlocuteur quand il prend conscience qu’on n’a fait qu’appliquer sa position du moment...)

Ça doit être comme ça :

[FORMAT_ENTREE]--1,1-----(CONVERTIR{Quantite})----1,1 --[FORMAT_SORTIE]

Là encore, le responsable du magasin doit donner un coup de tampon...

A ce stade, les règles de gestion sont donc les suivantes :

(R1) Un article a une seule forme en sortie ;
(R2) Une forme en sortie correspond à une seule forme en entrée ;
(R3) Une forme en entrée correspond à une seule forme en sortie.

On infère :

(R4) Un article a une seule forme en entrée.

L’entité-type FORME pourrait devenir la suivante :



ConversionQteOut représentant par exemple le nombre d’unités (en sortie) de telle forme (en entrée) : il s’agit de votre attribut ConversionQteOut repris de votre exemple que je reformule ainsi :

FormeId = 1
FormeEntreeLibelle = 'paquet'
FormeSortieLibelle = 'crayon'
ConversionQteOut = 100

Association avec ARTICLE :

[ARTICLE]--1,1----(Correspondre)----0,N--[FORME]

La patte connectant UTILISER et FORME n’ayant plus lieu d’être, votre ternaire UTILISER devient une binaire :

[UTILISATION]--0,N----(UTILISER{Qte})----0,N--[ARTICLE]--1,1----(Correspondre)----0,N--[FORME]

On comprend le poids de la décision que prend le patron du magasin en signant....

[RZinaoui]

Bonsoir,
Soit, mais « Verba volant, scripta manent » : Il faut que le responsable du magasin signe cette règle, lui mette un coup de tampon, car plus tard s’il se plaint parce qu’il n’y a qu’une forme en entrée pour un article, s’il rouspète, il ne devra s’en prendre qu’à lui-même plutôt qu’au seul RZinaoui (je parle d’expérience, et croyez-moi ça calme l’interlocuteur quand il prend conscience qu’on n’a fait qu’appliquer sa position du moment...)

Qu'il assume sa part de responsabilité mais après ces jours passés au magasin, j'ai remarqué que les articles ont une seule forme d'entrée et une de sortie. S'il y'aurait un cas particulier, qu'il s'en débrouille !

L’entité-type FORME pourrait devenir la suivante :

Pour FormeEntrée et FormeSortie, je les ai mis séparément comme propriétés des associations UTILISER et LIVRER au départ de ma modélisation (page 1) .. c'est à dire qu'on est arrivé enfin à l'idée que j'avais au début mais d'une manière structurée ...

[RZinaoui]

Voilà c'est terminé
Un grand merci à nos chers experts fsmrel et Krop pour leur soutien, MERCI BIEN.
J'avoue que sans votre aide, je n'aurai peut pas pu aboutir à mon objectif ...
Pour le coté technique du projet, j'ai encore du travail à faire pour apprendre d'autres trucs en SQL SERVER en l'occurrence les TRIGGERS.

MERCI INFINIMENT