Discussion :

[Kropernic]

Bon, j'ai encore modifier 2 ou 3 choses.

J'ai transformé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GIFT-0,1----DETRUIRE----0,n-CENTRALE

en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GIFT-0,1----CONCERNER----1,1-DESTRUCTION-1,1----EFFECTUER-0,n-CENTRALE

J'ai fait pareil pour activer que j'ai transformer en activation à la différence qu'un gift peut être activé plusieurs fois (une activation correspond à une vente offline).

Je pense que ce sera plus clair de cette manière et cela résoud mon problème de table intermédiaire non créée (j'avais trouvé ce topic où fsmrel donnait la solution mais j'avais tjs des soucis...)

Voilà donc à quoi j'arrive (cfr. pièce jointe). Je pense que ça commence à se rapprocher d'une version finale (pas trop tôt !).

Plus qu'à ajouter un petit module pour les commandes que la centrale passe chez le fournisseur et ce que le fournisseur livre à la centrale.

Après ça, je pense que ça devrait être bon

[Kropernic]

Une question sur le MLD pour changer (mais p-e devrais-je la poser dans le forum power amc...).

Sur base du MCD de mon message précédent, je demande la génération du MLD et j'obtiens le schéma se trouvant en pièce jointe.

Pourquoi est-ce que j'obtiens deux relations CONCERNER et CONCERNER2 entre les entités-types GIFT et DESTRUCTION ?

Cela s'explique-t-il d'un point de vue conceptuel ou bien est-ce un caprice de power amc ?

[CinePhil]

En vrai MCD, ça va mieux !

1) Il manque les cardinalités de l'association PRECISER entre TELEPHONE et TYPETEL.

2) Une adresse peut n'être localisée dans aucun pays ?
Et tu n'as pas externalisé la "CITY" !

adress -1,1----localiser----0,n- city -1,1----situer----0,n- pays

3) Tu n'as pas passé l'association DEPLACER en entité DEPLACEMENT. C'est volontaire ?

Je n'ai pas regardé en détail les types des propriétés mais ça ne semble pas déconnant à première vue. Rien ne m'a sauté aux yeux.

Pourquoi est-ce que j'obtiens deux relations CONCERNER et CONCERNER2 entre les entités-types GIFT et DESTRUCTION ?

C'est bizarre en effet car les deux associations ont des cardinalités 0,1 - 1,1 mais inversées, ce qui ne correspond pas au MCD.

Normalement, il devrait simplement mettre une clé étrangère référençant GIFT dans DESTRUCTION.

[Kropernic]

1) Tiens, bizarre ça...

2) On va mettre ça sur le compte de la fatigue *siffle*

3) Je crois qu'il y a encore quelque chose qui me chiffonne au niveau des déplacements mais je n'arrive pas bien à mettre le doigt dessus...

Je n'ai pas regardé en détail les types des propriétés mais ça ne semble pas déconnant à première vue. Rien ne m'a sauté aux yeux.

C'est déjà ça ^^

C'est bizarre en effet car les deux associations ont des cardinalités 0,1 - 1,1 mais inversées, ce qui ne correspond pas au MCD.

Normalement, il devrait simplement mettre une clé étrangère référençant GIFT dans DESTRUCTION.

Ca me rassure, j'avais anticipé la même chose. Fsmrel si tu nous lis...

[fsmrel]

Bonsoir,

Un gift est en fait un gift-cheque ou une gift-card

Avant d’en fournir la typologie, quel mot français est proposé pour « gift » ? « cadeau » suffit ?

Je me demande si je ne devrais pas plutôt utiliser un héritage car depuis hier j'ai un nouvel attribut dans gift qui est sert à savoir si un gift est rechargeable ou non mais cela dépend en fait du type de gift.

Avant d’envisager des choix techniques de modélisation, il faut stabiliser les règles de gestion, sinon c’est le gadin pratiquement assuré.

Un gift-cheque par exemple ne sera jamais rechargeable alors qu'une gift-card le sera toujours sauf dans certains cas.

Quels sont ces certains cas ?


En attendant, ça serait bien de compléter le tableau ci-dessous, permettant de savoir quel statut est applicable (oui/non) à quel type de gift.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
----------|-------------|---------------|
          |  Gift card  |  Gift cheque  |
----------|-------------|---------------|
Utilisé   |             |               |
Rechargé  |             |               |
Volé      |             |               |
Perdu     |             |               |
Retrouvé  |             |               |
Détruit   |             |               |
...       |             |               |
----------|-------------|---------------|

En théorie, le gift G1 pourrait être revendu/recharger (nouvel attribut "rechargeable" dans l'entité gift) au lieu d'être détruit s'il est en bon état (mais cela n'arrivera jamais je pense).

Revendu à qui ? A n’importe quel magasin ? A la centrale ? A un client offline ? A tout le monde ?

Quand je lis : « En théorie, ..., on pourrait... », j’en retire que ça n’est évidemment pas là une règle de gestion, et à votre demande la MOE (Maîtrise d’œuvre) doit se prononcer, à savoir si l’hypothèse devient règle ou pas. Verba volant, Scripta manent comme dit l’autre (Les paroles s’envolent, les écrits restent). Tout ce qui est modélisé doit être la conséquence stricte d’une règle de gestion rédigée en (bon) français, consignée dans le dossier de conception, et qui a dû d’abord faire l’objet d’un coup de tampon de la part de la MOE. Supposons qu’il n’ait jamais été question de la revente de gifts, donc que celle-ci n’ait pas fait l’objet d’une quelconque modélisation de votre part ; quand l’utilisateur se plaindra de l’absence de la fonctionnalité « Revente », la MOE ne pourra que reconnaître que c’est de sa faute (et pas la vôtre !) Elle devra en conséquence vous fournir les ressources pour mettre en œuvre la fonctionnalité, sur la base de l’estimation du chef de projet quant aux coûts et délais. Le MCD (ou le DC) doit au plus tôt être le plus complet et le plus blindé le plus possible, tout en restant ouvert pour l’arrivée de nouvelles fonctionnalités au fil des ans. C’est un peu l’alternative « Monde ouvert » et « Monde clos » (la part de l'imagination vagabonde vs la réalité du dossier de conception bien blindé).

Je pensais que non, car ce sont les consignes officielles, mais j'ai découvert hier que, en insistant, un client pourrait se faire rembourser de l'argent présent sur une gift-card. Je ne vois donc rien, en théorie, qui empêcherait que cette carte retourne dans le circuit (si elle n'est pas abimée bien sûr). Dans la pratique, cela n'arrivera probablement jamais (mais bon, j'aime autant le prévoir)

On est dans la logique que je viens d'évoquer. Si vous deviez prendre en compte le fait qu'une carte puisse être rachetée à un client et remise dans le circuit, cela pourrait compliquer singulièrement les choses, non seulement du côté de la modélisation des données, mais aussi du côté applicatif (à creuser). Il faut commencer par s’assurer que la MOE juge effectivement nécessaire la fonctionnalité « Rachat d’une carte » ; dans ces conditions, elle devra mettre les moyens en face de l’estimation chiffrée (jours/homme) faite par le chef de projet (s’il y en a un...) en association avec vous. Ne prenez pas d’initiative seul, ne soyez pas plus royaliste que le roi, ne dites pas « j'aime autant le prévoir », vous pourriez en subir les conséquences, du genre : « On ne vous a jamais demandé de mettre ça en œuvre », j’ai observé plus d'une fois ce genre de situation.

Un gift vendu en caisse est anonyme en effet.
Je peux juste éventuellement retrouver un propriétaire dans le cas où une carte client (genre de carte de fidélité) a été utilisée dans la transaction et donc se retrouvera sur le ticket dont j'ai les infos dans l'entité où la vente est historisée.

Toujours dans la série « En théorie, ..., on pourrait... », sauf contre-ordre signé par la MOE, on doit partir du principe que du point de vue des règles de gestion, on en reste à ceci :

Un gift vendu en caisse (« online ») est anonyme.

Un gift vendu à un client (« offline ») est lui aussi anonyme.

C’est bien ça ?

Concernant ce que vous appelez période, vous en feriez une entité à part entière ?

Disons qu’une période est un type scalaire, tout comme il existe les types scalaires ENTIER (INTEGER), CARACTÈRE (CHARACTER), ou DATE. Je considère ici qu'une période c’est une date de début et une date de fin, par exemple "[2012_07_14:2012_09_13]", mais ça pourrait être un intervalle plus fin. Comme pour le type ENTIER, il n’y aucune raison a priori d’en faire un type d’entité de plein droit. Ce que j’appelle période est en fait un intervalle particulier (laissez tomber la 6NF, c'est un film interdit aux moins de 18 ans de modélisation ).

La centrale effectuant aussi des ventes (hors caisses et qui font l'objet de commande), je l'ai considérée comme un magasin. Peut-être à tord.

Sémantiquement parlant, c’est un tort (un MCD relève de la modélisation sémantique !) Ça n’est qu’après stabilisation des règles de gestion que l’on peut envisager d’affaiblir la représentation en fusionnant des concepts bien distincts, en croisant les doigts pour que de fâcheux effets secondaires ne viennent pas ébranler l’édifice rendu instable...
Pour ce que j’ai vu jusqu’ici des règles de gestion, je ne vois pas de bonnes raisons de considérer la centrale comme un magasin.

Il vient d'ailleurs encore de me demander si les gifts étaient livrés directement en magasin alors qu'on a encore dit hier en réunion que non... C'est désespérant parfois )

Demandez-lui de rédiger l’ensemble des règles de gestion et de les faire valider par la MOE ! (mais relisez-les d’abord ).

Quitte à m'orienter vers une des deux, autant choisir la bonne

Si vous parlez de l’alternative MCD / DC (diagramme de classes), tous deux permettent de représenter les données de façon satisfaisante. A une époque je validais des paquets de MCD et de DC : les erreurs que je relevais ne faisaient que refléter les mêmes faiblesses imputables aux concepteurs : « Il n’y a pas de mauvais outils, ...»

Si vous parlez de l’alternative Merise / E-R, je dirais que pour discuter avec l’utilisateur, le MCD merisien est préférable (la MOE examine parfois les MCD lors des séances de relecture/validation), même chose quand je punaise le dessin au mur et que les curieux viennent demander des explications ou donner leur avis. Mais, quand j’en ai assez de travestir des ovales en rectangles (problème des associations d’associations), quand j’en ai assez d’être obligé de représenter un type d’entité factice DATE (à cause de certaines associations rendues ternaires du fait de l'intervention de la date), quand je dois produire un MLD SQL (les structures des tables et les contraintes d'intégrité) sans avoir à trop retoucher celui-ci, quand je n’ai plus de temps à perdre et que la sémantique ou l’émotion ne sont plus parties prenantes, je deviens pragmatique et utilise la combinaison E/R+Merise (je reproduis ici une partie de l’image figurant dans votre message #33) :



Je connais pas mal de concepteurs qui procèdent ainsi (ou qui se limitent à la notation E/R).

Je vais essayer de lire la suite de la discussion, mais tous les deux, avec CinePhil vous êtes de véritables mitraillettes, je me demande si j’arriverai un jour à vous rattraper, c’est la poursuite infernale (qui a soufflé : chasse au dahu ?)

__________________
P.-S. Je vois que vous faites mention des et , mais vous n'en faites guère usage. CinePhil et fsmrel s'échineraient-ils donc à n'énoncer que des lieux communs et autres banalités ?

[fsmrel]

En attendant la réponse de Kropernic à mes questions, des bricoles en passant.


Comme un gift peut être utilisé le même jour dans plusieurs magasins, il serait bien qu’on connaisse aussi le moment dans la journée auquel l’utilisation en a été faite.

- un client commande une gift-card pour une valeur de X€
- la centrale attribue la gift-card G à la commande du client et la livre
- ce client utilise la totalité de G et la laisse à la caisse car n'est plus utile pour lui (il pourrait faire le choix de la garder pour la recharger)
- G est renvoyée à la centrale
- un autre client commande une gift-card pour une valeur de Y€
- la centrale attribue G à la commande du client et la livre
- etc.

Dans ce cas, un gift fera l'objet de plusieurs commandes. Faut-il ajouter une contrainte pour préciser que ces commandes doivent être disjointes temporellement ? (sinon c'est qu'il y a eu un couac quelque part)

Oui. Pas de chevauchement de périodes.

Je n'ai par contre toujours pas trouver l'option de génération des tables en fonction des cardinalités

Pouvez-vous préciser votre problème ?

Pourquoi est-ce que j'obtiens deux relations CONCERNER et CONCERNER2 entre les entités-types GIFT et DESTRUCTION ?

C’est pour des raisons de symétrie... Il faut donc supprimer manuellement le lien en trop...

Mais, pour éviter d’avoir à bricoler le MLD à la main, on peut en passer par la mise en œuvre du « rôle dominant » comme je l’ai précisé dans la discussion dont vous faites mention. Si vous restez en Merise pur, comme ce concept n’en fait pas partie, vous pourrez utiliser une astuce de feignant qui en a marre de bricoler les MLD : établir un lien d’héritage entre GIFT et DESTRUCTION (que je verrais bien renommé en GIFT_DETRUIT, et pour cause...)

En tout cas, en Merise comme en E/R, dans la configuration classique, je vous recommande de mettre en oeuvre l’identification relative (cardinalité 1,1 entre Concerner et Destruction à mettre entre parenthèses) :

GIFT-0,1----CONCERNER----(1,1)-DESTRUCTION-1,1----EFFECTUER-0,n-CENTRALE

On reviendra sur les raisons et la sémantique de la chose.

Au niveau du dessin du schéma par contre ça peut être un peu fouilli. Je ne sais pas quelle liberté offre PowerAMC dans le positionnement des liaisons des associations.

PowerAMC permet plein de choses. Le mieux étant de faire des vues sur le MCD global (idem pour le MLD). Regardez à ce propos le message que j’ai envoyé à heretik25 (cherchez-y le mot « tuyau ») et dans lequel je parle du reste de l'identification relative. Ainsi vous pourrez vous concentrer sur un diagramme où vous ferez figurer seulement les types d’entités et associations impliquées par exemple dans les relations entre les gifts, la centrale, les magasins et les clients, sans être encombré par les adresses, les courriels et toutes ces sortes de choses.

[Kropernic]

Bonsoir,

Bonjour

Avant d’en fournir la typologie, quel mot français est proposé pour « gift » ? « cadeau » suffit ?

Oui, cadeau pourrait suffir. C'est juste que nous utilisons tous les jours le terme gift (gift-cheque, gift-card, gift-list(c'est encore autre chose ça mais bon)) et cela me semblait bien pour que tout le monde comprenne de quoi je parle. Nous pouvons utiliser le terme cadeau entre nous si vous voulez

Avant d’envisager des choix techniques de modélisation, il faut stabiliser les règles de gestion, sinon c’est le gadin pratiquement assuré.

J'en ai déjà rédigé une première version. Je vérifie une dernière fois que tout y est et je fais valider par le service concerné.

Quels sont ces certains cas ?

Aucun cas précis. Il suffit que le département marketing décide que pour une certaine action elle crée un gift-card et que cette gift-card ne sera pas rechargeable.

En attendant, ça serait bien de compléter le tableau ci-dessous, permettant de savoir quel statut est applicable (oui/non) à quel type de gift.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
----------|-------------|---------------|
          |  Gift card  |  Gift cheque  |
----------|-------------|---------------|
Utilisé   |     X       |      X        |
Rechargé  |     X       |               |
Volé      |     X       |      X        |
Perdu     |     X       |      X        |
Retrouvé  |     X       |      X        |
Détruit   |             |      X        |
...       |             |               |
----------|-------------|---------------|

J'ai fait la modif dans le tableau.

Revendu à qui ? A n’importe quel magasin ? A la centrale ? A un client offline ? A tout le monde ?

Un gift n'est pas vendu à un magasin. C'est le magasin qui vend le gift à un client. En online si c'est vendu dans un des 15 magasins (donc à la caisse), en offline, si c'est vendu par la centrale.

Quand je lis : « En théorie, ..., on pourrait... », j’en retire que ça n’est évidemment pas là une règle de gestion, et à votre demande la MOE (Maîtrise d’œuvre) doit se prononcer, à savoir si l’hypothèse devient règle ou pas. Verba volant, Scripta manent comme dit l’autre (Les paroles s’envolent, les écrits restent). Tout ce qui est modélisé doit être la conséquence stricte d’une règle de gestion rédigée en (bon) français, consignée dans le dossier de conception, et qui a dû d’abord faire l’objet d’un coup de tampon de la part de la MOE. Supposons qu’il n’ait jamais été question de la revente de gifts, donc que celle-ci n’ait pas fait l’objet d’une quelconque modélisation de votre part ; quand l’utilisateur se plaindra de l’absence de la fonctionnalité « Revente », la MOE ne pourra que reconnaître que c’est de sa faute (et pas la vôtre !) Elle devra en conséquence vous fournir les ressources pour mettre en œuvre la fonctionnalité, sur la base de l’estimation du chef de projet quant aux coûts et délais. Le MCD (ou le DC) doit au plus tôt être le plus complet et le plus blindé le plus possible, tout en restant ouvert pour l’arrivée de nouvelles fonctionnalités au fil des ans. C’est un peu l’alternative « Monde ouvert » et « Monde clos » (la part de l'imagination vagabonde vs la réalité du dossier de conception bien blindé).

Le problème c'est que j'ai l'impression qu'il n'y a pas de MOE bien définie . C'est d'ailleurs le gros bordel pour avoir une information cohérente et définitive sur quelque chose.

On est dans la logique que je viens d'évoquer. Si vous deviez prendre en compte le fait qu'une carte puisse être rachetée à un client et remise dans le circuit, cela pourrait compliquer singulièrement les choses, non seulement du côté de la modélisation des données, mais aussi du côté applicatif (à creuser). Il faut commencer par s’assurer que la MOE juge effectivement nécessaire la fonctionnalité « Rachat d’une carte » ; dans ces conditions, elle devra mettre les moyens en face de l’estimation chiffrée (jours/homme) faite par le chef de projet (s’il y en a un...) en association avec vous. Ne prenez pas d’initiative seul, ne soyez pas plus royaliste que le roi, ne dites pas « j'aime autant le prévoir », vous pourriez en subir les conséquences, du genre : « On ne vous a jamais demandé de mettre ça en œuvre », j’ai observé plus d'une fois ce genre de situation.

Je vais encore insister. J'ai déjà reposé la question ce matin au service qui gère les cartes et pour eux, c'était non. Quand je pose la question à un gars de l'équipe caisse, y a des cas où ça arrive... Bref, comme je disais plus haut, c'est le bordel !

Complément d'info (pcq ça fait 2h que ce message est en édition chez moi^^) : Mon chef vient de me dire ceci :

Actuellement la caisse ne permet pas le remboursement d'une carte mais c'est possible par des moyens détournés. Dans le nouveau système, l'option existe mais on ne souhaite en informer les caissières.

Voilà ce que je viens d'avoir. La possibilité existe donc bel et bien. Le fait de ne pas vouloir en informer les caissières, c'est une presque anecdote je dirais. Je sais bien que ici, tout finit toujours par ce savoir (et pas forcément que ici en fait) et une décision qui a été prise fini souvent par changer également (surtout quand le client entre en ligne de compte).

Toujours dans la série « En théorie, ..., on pourrait... », sauf contre-ordre signé par la MOE, on doit partir du principe que du point de vue des règles de gestion, on en reste à ceci :

Un gift vendu en caisse (« online ») est anonyme.

Un gift vendu à un client (« offline ») est lui aussi anonyme.

C’est bien ça ?

Un gift vendu online est anonyme.
Un gift vendu offline n'est pas anonyme.

Disons qu’une période est un type scalaire, tout comme il existe les types scalaires ENTIER (INTEGER), CARACTÈRE (CHARACTER), ou DATE. Je considère ici qu'une période c’est une date de début et une date de fin, par exemple "[2012_07_14:2012_09_13]", mais ça pourrait être un intervalle plus fin. Comme pour le type ENTIER, il n’y aucune raison a priori d’en faire un type d’entité de plein droit. Ce que j’appelle période est en fait un intervalle particulier (laissez tomber la 6NF, c'est un film interdit aux moins de 18 ans de modélisation ).

Ok tout va bien alors. Quant à la 6NF, le peu que j'en ai lu m'avait déjà donné le sentiment que ce n'était pas de mon âge.

Sémantiquement parlant, c’est un tort (un MCD relève de la modélisation sémantique !) Ça n’est qu’après stabilisation des règles de gestion que l’on peut envisager d’affaiblir la représentation en fusionnant des concepts bien distincts, en croisant les doigts pour que de fâcheux effets secondaires ne viennent pas ébranler l’édifice rendu instable...
Pour ce que j’ai vu jusqu’ici des règles de gestion, je ne vois pas de bonnes raisons de considérer la centrale comme un magasin.

Ce que j'appelle la centrale pour que simplifier le vocabulaire sur le forum est en fait le SSSD (pour Special Sales & Services Departement) que nous considérons comme notre 16e magasin. C'est ce service s'occupe de vendre les gifts (cheque ou carte) aux clients qui passent commandes (chez eux également). C'est toujours ce même service qui s'occupe de commander chez nos fournisseurs de nouveaux gifts. Enfin, pour une partie de ceux-ci. J'ai appris ce matin que pour les gifts-card standards (car il y en a dont l'image change 4 fois par an), c'est géré via un autre circuit. J'ai d'ailleurs grandement modifier/simplifier le mcd à cause de cela car il y a toute une partie de ce que je prenais en considération jusqu'ici qui tombe à l'eau.

Demandez-lui de rédiger l’ensemble des règles de gestion et de les faire valider par la MOE ! (mais relisez-les d’abord ).

Je ne pense pas qu'il sache ce qu'est une règle de gestion d'un point de vue de modélisation conceptuelle.

Si vous parlez de l’alternative MCD / DC (diagramme de classes), tous deux permettent de représenter les données de façon satisfaisante. A une époque je validais des paquets de MCD et de DC : les erreurs que je relevais ne faisaient que refléter les mêmes faiblesses imputables aux concepteurs : « Il n’y a pas de mauvais outils, ...»

Comme souvent...

Si vous parlez de l’alternative Merise / E-R, je dirais que pour discuter avec l’utilisateur, le MCD merisien est préférable (la MOE examine parfois les MCD lors des séances de relecture/validation), même chose quand je punaise le dessin au mur et que les curieux viennent demander des explications ou donner leur avis. Mais, quand j’en ai assez de travestir des ovales en rectangles (problème des associations d’associations), quand j’en ai assez d’être obligé de représenter un type d’entité factice DATE (à cause de certaines associations rendues ternaires du fait de l'intervention de la date), quand je dois produire un MLD SQL (les structures des tables et les contraintes d'intégrité) sans avoir à trop retoucher celui-ci, quand je n’ai plus de temps à perdre et que la sémantique ou l’émotion ne sont plus parties prenantes, je deviens pragmatique et utilise la combinaison E/R+Merise (je reproduis ici une partie de l’image figurant dans votre message #33) :



Je connais pas mal de concepteurs qui procèdent ainsi (ou qui se limitent à la notation E/R).

J'imagine que je ferai mon choix avec l'expérience...

Je vais essayer de lire la suite de la discussion, mais tous les deux, avec CinePhil vous êtes de véritables mitraillettes, je me demande si j’arriverai un jour à vous rattraper, c’est la poursuite infernale (qui a soufflé : chasse au dahu ?)

Faites à votre aise (mais pas trop quand même :p)

P.-S. Je vois que vous faites mention des et , mais vous n'en faites guère usage. CinePhil et fsmrel s'échineraient-ils donc à n'énoncer que des lieux communs et autres banalités ?

Loin de là. Cette signature date d'une époque où je faisais un peu de zèle sur le forum VB.NET et je n'y attache plus guère d'importance. De plus, aussi bien vous que Cinéphil ne dites que des choses fort intéressantes. Du coup, je serais obligé de marqué en vert chacun de vos messages et aucun ne sortirait plus du lot... Mais je peux le faire si cela vous tient à coeur.

[Kropernic]

Comme un gift peut être utilisé le même jour dans plusieurs magasins, il serait bien qu’on connaisse aussi le moment dans la journée auquel l’utilisation en a été faite.

La date se trouve dans l'entité mouvement, c'est prévu .

Pouvez-vous préciser votre problème ?

Il s'agissait du même problème que celui présenter dans la discussion dont j'ai fait mention dans un message précédent (et dont vous redonnez le lien plus bas).

C’est pour des raisons de symétrie... Il faut donc supprimer manuellement le lien en trop...

Je l'avais bien compris mais je n'arrivais pas à savoir lequel était de trop. Par contre, pour ma culture, j'aimerais savoir ce vous entendez exactement par symétrie ici.

Mais, pour éviter d’avoir à bricoler le MLD à la main, on peut en passer par la mise en œuvre du « rôle dominant » comme je l’ai précisé dans la discussion dont vous faites mention. Si vous restez en Merise pur, comme ce concept n’en fait pas partie, vous pourrez utiliser une astuce de feignant qui en a marre de bricoler les MLD : établir un lien d’héritage entre GIFT et DESTRUCTION (que je verrais bien renommé en GIFT_DETRUIT, et pour cause...)

Pouvez-vous développer svp ?

En tout cas, en Merise comme en E/R, dans la configuration classique, je vous recommande de mettre en oeuvre l’identification relative (cardinalité 1,1 entre Concerner et Destruction à mettre entre parenthèses) :

GIFT-0,1----CONCERNER----(1,1)-DESTRUCTION-1,1----EFFECTUER-0,n-CENTRALE

On reviendra sur les raisons et la sémantique de la chose.

C'est ce que j'ai finalement fait. Pareil pour les activations (et les désactivations qui ne figurent pas encore sur les mcd's que j'ai déjà postés), les mouvements financiers, les déclarations et les réceptions. Les envois ne seront plus historier. Fini donc le problème de savoir qui envoi quoi à qui et de savoir d'où vient ce que quelqu'un reçoit.

PowerAMC permet plein de choses. Le mieux étant de faire des vues sur le MCD global (idem pour le MLD). Regardez à ce propos le message que j’ai envoyé à heretik25 (cherchez-y le mot « tuyau ») et dans lequel je parle du reste de l'identification relative. Ainsi vous pourrez vous concentrer sur un diagramme où vous ferez figurer seulement les types d’entités et associations impliquées par exemple dans les relations entre les gifts, la centrale, les magasins et les clients, sans être encombré par les adresses, les courriels et toutes ces sortes de choses.

Je vais aller regarder cela de plus près. Ce doit être fort pratique !

[Kropernic]

Jamais 2 sans 3 comme on dit !
(avis aux modérateurs : désolé pour le triple message mais c'est histoire de bien séparer à qui/quoi je réponds et un nouveau message qui ne répond à aucun autre)

J'ai annoncé différents changements dans mon message précédent. Notamment pour les envois et les réceptions.
A force d'essayer de tirer les vers du nez à tout le monde, j'ai fini par des infos détaillés sur la vie des gifts.

Je vais détailler ci-dessous :

D'abord, les gift-cheques "à valeur fixe". Ils sont commander par la centrale. C'est elle qui décide des numéros de série des chèques. Une fois fabriquer par le fournisseur, il les livre à notre entrepôt et de là, ils sont dispatcher dans les différents magasins (les 15 "vrais" magasins plus la centrale qui est le 16e virtuel) sur base des instructions de la centrale. Une fois en magasin, le chèque est :
- vendu à la caisse (en online donc anonyme) puis utilisé ou non par le client s'il s'agit d'un "vrai" magasin
- vendu hors caisse (en offline donc pas anonyme) puis utilisé ou non par le client
- invendu et est retourné à la centrale pour destruction (à une date limite prévue par la centrale).

Ensuite, les gifts-cheque "à valeur variable". Ce sont en fait des bons d'achats. Ils sont créés par exemple lors du retour d'un article. Plutôt que de rembourser le client en cash, on lui émet un gift-cheque de la valeur de l'article retourné et ce gift est imprimer directement sur le ticket de caisse. Pas de commande au fournisseur et pas de destruction non plus. Juste une création et une utilisation. Ils sont aussi émis lorsqu'un client utilise un gift-cheque "à valeur fixe" pour un montant inférieur à la valeur du chèque. Il lui est alors rendu un chèque "à valeur variable" pour le montant restant.

Maintenant les gift-cards...
Déjà, première différence. Il y a les cartes "prepaid" (à valeur fixe") et les autres (à valeur variable).
Les prepaids sont vendues uniquement à la centrale (en offline donc). Niveau commande, on n'a pas su me répondre car aucune commande de ce type de carte n'a encore été fait... (ils les ont récupérées de je sais pas trop où et en ont encore un gros stock)

Pour les valeurs variables, il y a encore 2 sortes. Les cartes classiques et les saisonnières.
Les classiques sont considérées comme un article ordinaire et sont commandées et distribuées en magasin comme n'importe quel autre article de notre assortiment. Ce n'est donc pas la centrale qui gère cela. Ils sont donc commandés via un autre système et livrés à notre entrepôt (qui devra signaler à la centrale ce qu'il a reçu histoire de pouvoir les créer dans la DB). L'envoi vers les magasins se fait lorsque ceux-ci font une commande de ce type de carte à l'entrepôt via le même autre système. Je ne saurai donc pas ce que l'entrepôt enverra vers les magasins. Par contre, le magasin devra signaler dans l'application ce qu'il a reçu. Une fois en magasin, la carte est vendue à un client et utilisée ou non par ce client.
Finalement, les cartes saisonnières fonctionnent comme les chèques à valeur fixe. Elles sont commandées par la centrale, livrées à l'entrepôt et dispatchées dans les magasins (+centrale) sur base des instructions de la centrale. Une fois en magasin en magasin, elles sont vendues au client jusqu'à épuisement du stock puis utilisées par ce dernier. En cas d'invendus (pcq l'image ne plait pas par exemple), elles sont retournées à la centrale qui les écoule pour les commandes offline.

Voilà, comme ça, tout est à plat !
Et ça m'a permis de ma clarifier les idées par la même occasion.

Du coup, évidemment, je me pose de nouvelles questions du point de vue de la modélisation des gifts.

Jusqu'ici, j'ai une entité gift qui permet de définir deux sous-types que sont les chèques et les cartes. Je me demande si je ne devrais pas créer une entité par type de chèque.
La nomenclature d'un barcode de chèque est la suivante :
TTVVYXXXXXXXC
où :
- TT représente le type du chèque sur 2 digits
- VV représente la valeur du chèque sur 2 digits
- Y représente l'année d'impression du chèque
- XXXXXXX est un numéro de séquence
- C est le check-digit du barcode au format EAN13

Pour un chèque à valeur fixe, aucun souci, ça colle parfaitement. Pour un chèque à valeur variable, VV sera toujours 88 et la caisse devra faire une requête DB (une autre dont j'ignore tout ) pour en connaitre la valeur. Du coup, je me demande s'il ne vaudrait pas mieux faire une entité à part pour ce genre de chèque-là.

Pour les cartes, ça semble aller. J'ai une nomenclature respectée à chaque fois où chaque partie conserve son sens sémantique donc je pense qu'une table devrait suffire en splittant le barcode en autant d'attribut que nécessaire.

Voici donc, en pièce jointe, le mcd auquel je suis arrivé (en mettant mon collègue à contribution). Je n'ai mis que la partie qui concerne la vie d'un gift. La partie client + commande étant au point je pense.

Je viens par contre de remarquer un truc pas cohérent. Je n'ai pas relié destruction avec centrale alors que je le fais pour activation et désactivation. Cela vient probablement du fait que je n'arrive pas à considérer la centrale comme autre chose qu'un magasin (avec éventuellement un statut admin).
Quand je regarde ce schéma, je ne peux m'empêcher d'imaginer les tables de la future DB et leur contenu. Or, pour l'entité centrale, je ne vois vraiment pas ce qu'il y aurait dedans...

Je vais m'arrêter là pour aujourd'hui et laisser les idées se décanter je pense. A force de tout retourner, je finis par devenir brouillon (puis il faut laisser le temps à fsmrel de suivre :p)

[fsmrel]

Bonsoir à nouveau,

quel mot français est proposé pour « gift » ? « cadeau » suffit ?

Oui, cadeau pourrait suffir. C'est juste que nous utilisons tous les jours le terme gift (gift-cheque, gift-card, gift-list(c'est encore autre chose ça mais bon)) et cela me semblait bien pour que tout le monde comprenne de quoi je parle. Nous pouvons utiliser le terme cadeau entre nous si vous voulez

Le terme « gift » me convient suffit puisque c’est celui qui est utilisé dans la chaîne de magasins et que je sais maintenant qu’il est synonyme de « cadeau ».

J'en ai déjà rédigé une première version.

N’hésitez pas à nous soumettre cette version, plus elle sera relue et commentée plus elle se stabilisera (sous réserve que le marketing ne délire pas...)

Un gift-cheque par exemple ne sera jamais rechargeable alors qu'une gift-card le sera toujours sauf dans certains cas.

Quels sont ces certains cas ?

Aucun cas précis. Il suffit que le département marketing décide que pour une certaine action elle crée un gift-card et que cette gift-card ne sera pas rechargeable.

Si je comprends bien, l’attribut CRD_RECHARGEABLE du sous-type CARD du type d’entité GIFT est un booléen servant à entériner la décision du marketing (à l’imagination débridée). C’est bien cela ? Par ailleurs, vous écrivez que c’est seulement pour « une certaine action ». Vous ne conservez pas la trace de la décision du marketing visant la carte en cause ? C’est inutile ? (A préciser dans les règles de gestion).

J'ai fait la modif dans le tableau.

D’accord, merci.

Un gift n'est pas vendu à un magasin. C'est le magasin qui vend le gift à un client. En online si c'est vendu dans un des 15 magasins (donc à la caisse), en offline, si c'est vendu par la centrale.

La fourche m’avait langué , je voulais en fait savoir si le gift G1 — qui a été rapporté dans le magasin M314 par un quidam (cf. message #25) — retrouvait le statut de gift lambda et donc être remis dans le circuit. Si je vous suis, G1 peut effectivement repartir en magasin ou être vendu en offline à un client. Est-ce bien cela ? Merci de préciser la règle de gestion qui figurera dans le dossier de conception.

Le problème c'est que j'ai l'impression qu'il n'y a pas de MOE bien définie . .

Mouais... Si vous êtes en fait en prise directe avec la MOA (Maîtrise d’ouvrage), veillez néanmoins à ce qu’elle tamponne les règles de gestion sur lesquelles vous vous appuyez, en sorte que le jour où l’on vous dira « Dites donc M. Kropernic, ça ne va pas, là, ça n’est pas ce qu’on a demandé », vous puissiez rétorquer, preuves à l’appui : « Mais si ! relisez attentivement, tel jour vous l’avez validé... » (n’oubliez jamais : verba volant, pour ma part, c’est une des premières choses que j’ai apprises en construisant des bases de données...)

Mon chef vient de me dire

Si votre chef peut jouer le rôle de la MOE et communique avec la MOA, à lui de tamponner en 1er lieu et d’aller faire tamponner par la MOA...

Voilà ce que je viens d'avoir. La possibilité existe donc bel et bien.

Puisque le chef va mettre un coup de tampon sur la règle : « une carte peut être rachetée à un client et remise dans le circuit », y-a-plus-qu’à (jusqu'à ce qu’un contre-ordre vienne infirmer la règle, phénomène pas si rare dans les entreprises où l’imagination ne fait pas défaut...)

aussi bien vous que Cinephil ne dites que des choses fort intéressantes. Du coup, je serais obligé de marqué en vert chacun de vos messages et aucun ne sortirait plus du lot...

En fait, si vous ne marquez pas un message, on ne sait pas vraiment si on a dit des choses intéressantes : votre vote permet de s’en assurer et surtout de savoir que vous avez compris ce que l’on dit, car nous pouvons parfois être fumeux et difficiles à suivre... En plus, un vote sert aussi à motiver les autres forumeurs susceptibles de s’intéresser à la discussion. Et puis, être plussé, ça stimule quand même.


Je marque une pause, car ce qui suivra touche à la modélisation : ça risque de faire l’objet de questions, voire de débats et je préfère isoler les points sensibles.

[fsmrel]

Dans ce qui suit, je ne tiens pas compte de votre message d’hier, dans lequel vous évoquez le rôle de l’entrepôt, lequel vient ficher un tantinet la zoubia...

Ce que j'appelle la centrale pour que simplifier le vocabulaire sur le forum est en fait le SSSD (pour Special Sales & Services Departement) que nous considérons comme notre 16e magasin. C'est ce service s'occupe de vendre les gifts (cheque ou carte) aux clients qui passent commandes (chez eux également). C'est toujours ce même service qui s'occupe de commander chez nos fournisseurs de nouveaux gifts. Enfin, pour une partie de ceux-ci. J'ai appris ce matin que pour les gifts-card standards (car il y en a dont l'image change 4 fois par an), c'est géré via un autre circuit.

Jusqu’ici, je pense que du point de vue de la modélisation ou peut continuer à parler de la centrale, sans chercher à creuser outre mesure. Quoi qu’il en soit, pourquoi tenez-vous à considérer celle-ci comme un magasin ? Je suppose qu'elle n'a pas de caisses, qu'elle ne pratique pas l'online. Dans ces conditions que manque-t-il d’essentiel si on part du principe qu’elle est unique et qu’elle ne fait pas l’objet d’aucune ligne dans la table STORE ? Par exemple, vous avez supprimé le lien avec la centrale dans le cas de la destruction d’un gift, donc vous avez senti que ce lien est inessentiel : on sait par définition que si un gift est détruit, alors c’est la centrale qui s’en est chargé. En toute logique, le lien entre les tables STORE et ACTIVATION est a priori inessentiel lui aussi ; même chose pour le lien entre les tables STORE et DESACTIVATION : qui a agi pour activer ou désactiver ? Réponse : la centrale. Bref, je répète, que manque-t-il d’essentiel si on évacue la centrale en tant qu’instance de STORE ?

Vous me répondrez sans doute qu’on ne sait plus gérer les stocks de la centrale. Mais on peut modéliser les choses ainsi :




Qu’en est-il des transferts de gifts entre la centrale et les magasins ? Je dirai pour ma part que la table RECEPTION ne concerne alors que les transferts vers les magasins.

Par exemple, au cours de la période P11, le gift G1 figure dans le stock de la centrale. Au cours de la période suivante P12, G1 figure dans le stock du magasin M1 (en passant, je renommerais volontiers RECEPTION en STORE_STOCK) et au cours de la période P13, G1 réintègre le stock de la centrale. En l'occurrence les modèles ci-dessous suffisent :


MCD



MLD



N.B.

La version que j’utilise de PowerAMC est bien antérieure à la vôtre, donc la notation MLD est déjà relationnele (mickeys <PK>, <AK>, <FK>, ...)

Vous remarquerez que l’attribut StoreCode donne lieu à un identifiant alternatif dans le MCD (clé alternative dans le MLD).

[CinePhil]

Petit complément au dernier MCD de fsmrel : Il faudrait ajouter une contrainte d'exclusion entre les deux association reliant GIFT à CENTRALE_STOCK d'une part et à STORE_STOCK d'autre part.

Moi aussi, cette entité type CENTRALE me gênait parce qu'il n'y a qu'une seule centrale. Et une table de BDD avec une seule ligne, c'est un peu comme un coffre à bijou sans x à bijou !
Comme d'habitude, l'expert y a trouvé une compensation élégante !

@Kropernic, désolé, je n'ai pas pris le temps de regarder en détails ton dernier MCD.

[Kropernic]

Cette histoire de stock me fait voir les choses sous un jour nouveau.

C'est vrai que c'est pas mal clair de cette façon et ça supprime cette table centrale dénué d'intérêt pour la remplacer par quelque chose avec un vrai contenu.

Dans la même logique, j'imagine que rien n'empêche d'ajouter une entité type nommée entrepot_stock qui serait du même acabit que centrale_stock et store_stock avec une contrainte d'exclusion mutuelle entre les trois liaisons qui partent de gift vers les stocks. (au passage, comment vous notez cette contrainte sur un mcd ? comment se concrétise-t-elle en DB ? (un trigger à l'insert qui vérifie qu'on peut mettre le gift dans le stock demandé ?))

Autrement, que pensez-vous de mon commentaire sur le sous-type cheque de gift ? Avec les nouveaux éléments reçus hier, ne vaudrait-il pas mieux créer plusieurs sous-types ?

[CinePhil]

Dans la même logique, j'imagine que rien n'empêche d'ajouter une entité type nommée entrepot_stock qui serait du même acabit que centrale_stock et store_stock avec une contrainte d'exclusion mutuelle entre les trois liaisons qui partent de gift vers les stocks. (au passage, comment vous notez cette contrainte sur un mcd ?

Voir dans cet article.

comment se concrétise-t-elle en DB ? (un trigger à l'insert qui vérifie qu'on peut mettre le gift dans le stock demandé ?))

Généralement, oui.

[Kropernic]

Bon bin il n'est pas possible de représenter des contraintes d'inclusion/d'exclusion dans power amc ^^

[Kropernic]

Voilà donc ce à quoi j'aboutis (cfr. pièce jointe)

Se pose juste encore la question pour les chèques à valeur variable dont la valeur n'est pas reprise dans le barcode (que j'ai décomposé dans l'entité) mais si la nomenclature colle avec la décomposition.

Et je ne suis toujours pas sûr des cardinalités pour l'association COMMANDER qui a lieu entre GIFT_GFT - FOURNISSEUR_FRN - COMMANDE_CMD.

Pour les associations entre 2 entités, j'ai bien compris le "truc" tel que détaillé dans un billet du blog de Cinéphil. Mais pour les associations entre plus que 2 entités, je n'arrive toujours pas à formuler cela d'une manière qui permettrait de déterminer les cardinalités.

Auriez-vous un tuyau à ce sujet ?

Merci d'avance !

[CinePhil]

Pour les associations entre 2 entités, j'ai bien compris le "truc" tel que détaillé dans un billet du blog de Cinéphil. Mais pour les associations entre plus que 2 entités, je n'arrive toujours pas à formuler cela d'une manière qui permettrait de déterminer les cardinalités.

Auriez-vous un tuyau à ce sujet ?

Pour faire vite, une association d'arité supérieure à 2 aura les cardinalités maximales à n, sinon, c'est le signe que ça peut être décomposé en des associations d'arité inférieure.

Et généralement, les cardinalités minimales sont à zéro, même s'il peut parfois y en avoir à 1.

Tu peux donc commencer par mettre du 0,n sur toutes les pattes de l'association puis te poser la question pour chaque entité type y participant : " Combien de fois cette entité type participe t-elle au minimum à l'association ? "

Venons-en à ton doute :

Et je ne suis toujours pas sûr des cardinalités pour l'association COMMANDER qui a lieu entre GIFT_GFT - FOURNISSEUR_FRN - COMMANDE_CMD.

Moi j'ai de gros doutes, a priori et sans avoir relu les messages précédents, qu'un gift puisse être commandé plusieurs fois à un fournisseur !

Je ferais plutôt ce genre de schéma :
Gift -0,n----concerner----1,n- Commande -1,1----passer----0,n- Fournisseur

[Kropernic]

Venons-en à ton doute :

Moi j'ai de gros doutes, a priori et sans avoir relu les messages précédents, qu'un gift puisse être commandé plusieurs fois à un fournisseur !

Je ferais plutôt ce genre de schéma :
Gift -0,n----concerner----1,n- Commande -1,1----passer----0,n- Fournisseur

J'avais également des doutes là-dessus .

Ca finira bien un jour par rentré ! Si vous vous souvenez, j'avais fait la même chose avec les entités adresse, type_adresse et client. Et vous aviez donné le même genre de solution.

A force de taper sur le clou, je vais finir par retenir.

Merci !

P.S. : Entre temps, j'avais trouvé ceci.

[Kropernic]

Encore une question pour fsmrel et sa sulfateuse à NULL ^^

Je me suis rendu compte d'une erreur (en fait 3 mais c'est 3 fois la même) dans mon dernier MCD.

Pour les entités de stock, j'ai mis l'attribut DATE_OUT dans l'identifiant ce qui le rend donc obligatoire. Il est évident que lorsqu'un gift entre en stock, on n'en connait pas encore la date de sortie. Donc il ne peut pas être obligatoire. Et de toute façon, l'id du gift et la date d'entrée suffit à identifier chaque instance de l'entité de manière unique.

Mais du coup, le bonhomme NULL pointe le bout de son nez !
Certes, à terme (lorsque le gift sortira du stock), il n'y aura plus de NULL mais entre l'entrée et la sortie, monsieur NULL prendra le thé avec les gifts.

Comment faire alors ? Suis-je trop maniaque (peut-on autoriser ce NULL-là ?) ?

[CinePhil]

La question à se poser serait peut-être : "La propriété DATE_OUT doit-elle être enregistrée dans la BDD ?"

Si tous les mouvements ou événements survenant sur les gifts sont horodatés, on doit pouvoir à tout moment, par simple requête, savoir si un gift est encore dans le central_stock ou dans un autre stock ou connaître sa date de sortie, si elle existe, de tout stock par lequel il est passé.

Le risque de laisser une telle propriété est la redondance d'information qui entraîne le risque d'incohérence des données.

Sans avoir revu le détail de ton MCD, je dirais a priori que c'est le nid DATE_OUT qui doit passer à la sulfateuse, empêchant ainsi tout NULL de s'y glisser !