Discussion :

[CinePhil]

Seulement avec ce mcd, quand je regarde le mld généré, je retrouve l'identifiant de commande dans gift. Alors qu'un gift peut ne pas avoir fait l'objet d'une commande.

Décidément, je n'aime pas la représentation Entity/Relationship !

Normalement, en MCD merisien classique, tu devrais avoir ceci :
commande -1,n----concerner----0,1- gift

Et comme je l'explique dans mon blog, une telle association engendre une table associative. Il ne doit donc pas y avoir de clé étrangère référençant la commande dans gift.

Je crois que je vais rester avec la généralisation et ajouter un attribut store dans l'entité action qui, dans certains cas sera null, dans d'autres indiquera l'origine et dans les cas restants la destination.

Aïe ! fsmrel va sortir sa sulfateuse anti NULL !

Déjà que mon collègue me fait presque une scène parce que je refuse de lui ajouter un attribut status dans l'entité gift

S'il est pertinent qu'un gift passe par différents états, il semble normal que l'entité type gift soit associée à une entité type référençant ces différents états.

Maintenant, si l'état d'un gift peut être trouvé à tout moment par requête sans avoir besoin de l'enregistrer, c'est effectivement de la redondance qu'il vaut mieux éviter.

Déjà que mon collègue me fait presque une scène parce que je refuse de lui ajouter un attribut status dans l'entité gift car cela ajoute de la redondance alors si je lui file un schéma avec toutes ces relations, je vous raconte pas le bordel .

Il ne faut pas transiger avec la qualité des données. Surtout qu'il s'agit ici, si j'ai bien compris, du coeur du business : chaque gift enregistré a une certaine valeur pour l'entreprise et il semble que vous souhaitiez avoir une bonne traçabilité de la vie de chaque gift, que ce soit pour des statistiques ou peut-être pour justificatifs comptables ou fiscaux.

À vous de voir quelle importance vous attachez à vos données mais il vaut mieux prendre le temps de bien faire maintenant plutôt que de se rendre compte qu'il y a des données incohérentes et inexploitables, engendrant des résultats faux une fois tout cela mis en production.

Bon courage !

[Kropernic]

Décidément, je n'aime pas la représentation Entity/Relationship !

Normalement, en MCD merisien classique, tu devrais avoir ceci :
commande -1,n----concerner----0,1- gift

Et comme je l'explique dans mon blog, une telle association engendre une table associative. Il ne doit donc pas y avoir de clé étrangère référençant la commande dans gift.

Ah bin voilà !!! Il me manque une entité/association ! Je ne sais pas pourquoi elle a disparue. Elle se trouve bien dans le premier schéma que j'ai posté néanmoins.
Ca doit être ça que quelque chose me chiffonnait.

Cependant, j'y ai réfléchis depuis et je me dis que l'id de la commande dans la table gift n'est pas si gênant que ça. S'il y a une valeur, le gift a fait l'objet d'une commande. Si c'est NULL, le gift n'a pas fait l'objet d'une commande (et il faut aller voir dans action pour connaitre son statut)
Mais cela fait une valeur null de plus et je ne voudrais pas me mettre fsmrel à dos .

Aïe ! fsmrel va sortir sa sulfateuse anti NULL !

Qu'il n'hésite pas ! Un point de vue tiers provoquera p-e un déclic.

S'il est pertinent qu'un gift passe par différents états, il semble normal que l'entité type gift soit associée à une entité type référençant ces différents états.

Maintenant, si l'état d'un gift peut être trouvé à tout moment par requête sans avoir besoin de l'enregistrer, c'est effectivement de la redondance qu'il vaut mieux éviter.

C'est effectivement le cas. Il est parfaitement possible de retrouver le status d'un gift via une requête sur l'entité action.

Il ne faut pas transiger avec la qualité des données. Surtout qu'il s'agit ici, si j'ai bien compris, du coeur du business : chaque gift enregistré a une certaine valeur pour l'entreprise et il semble que vous souhaitiez avoir une bonne traçabilité de la vie de chaque gift, que ce soit pour des statistiques ou peut-être pour justificatifs comptables ou fiscaux.

À vous de voir quelle importance vous attachez à vos données mais il vaut mieux prendre le temps de bien faire maintenant plutôt que de se rendre compte qu'il y a des données incohérentes et inexploitables, engendrant des résultats faux une fois tout cela mis en production.

C'est bien pour cela que passe mon temps ici avec vous depuis hier

Bon courage !

Merci

[Kropernic]

fsmrel va être content.

J'ai une nouvelle info à placer et du coup, la généralisation devient de plus en plus bancale.

Je modélise et reviens vers vous si vous voulez toujours bien

[Kropernic]

Me voilà de retour.

Je pense avoir clarifier le MCD (même si c'est un peu le foutoir au niveau de power amc) mais j'ai encore des problèmes pour arriver à déterminer les cardinalités des associations entre plus que 2 entités.

Voilà à quoi je suis arrivé (cfr. pièce jointe "mcd.png").

Je pense avoir des soucis au niveau des cardinalités pour mon association DETRUIRE_DET, quand il génère le MLD (cfr. pièce jointe "mld.png"), il ajoute mon attribut DET_DATE dans la table GIFT_GFT au lieu de générer une table association.

Autre question, est-ce "normal" (dans le sens, est-ce que cela peut arriver) d'avoir une double relation entre DEPLACER_DEP et STORE_STR ?
En tout cas, cela résoud mon problème de destination/origine puisque j'ai deux colonnes pointant vers ma table store dans mon MLD.

[petit HS]
En tout cas, la modélisation est un domaine passionnant. J'ai démarré programmeur et je suis devenu DBA par la force des choses car il n'y en a pas où je bosse (enfin je suis encore apprenti on va dire ^^) et ce que je fais maintenant avec vous est ma première vraie modélisation "dans les règles de l'art". Ca me donne vraiment envie de ne plus faire que ça (ou presque). Si vous deviez conseiller un bouquin pour quelqu'un comme moi qui s'intéresse à cela mais qui débute, lequel serait-ce ?
(Je sais qu'il existe des "ouvrages de référence" écrit par des sommités comme C. Date mais de ce que j'en ai entendu/lu comme avis, ils sont assez formels et il faut parfois s'accrocher.)
[/petit HS]

[fsmrel]

Bonsoir,


J’ai regardé d’un peu plus près, le sujet traité est intéressant.


Ce que j’écris ici ne concerne pas votre message #24, que j’ai découvert après avoir rédigé ce qui suit.


Je vais essayer de suivre un peu quelques uns des événements qui marquent la vie de cette chose mystérieuse que vous appelez GIFT.

Le gift G1 a fait partie du stock de la centrale pendant la période P11. Pendant la période P12, il a fait partie du stock du magasin M1. Considéré comme en excédent, G1 a été renvoyé à la centrale et a fait à nouveau partie du stock de celle-ci pendant la période P13. Quand M1 a commandé de nouveaux gifts à la centrale, elle a récupéré G1 (mais ça n’est qu’un effet du hasard). G1 a fait à nouveau partie du stock de M1 pendant la période P14. G1 a fait l’objet d’une vente en caisse à la date D15 (qui fait que la période P14 se termine la veille de D15). G1 a été utilisé dans 3 magasins différents le même jour (D16). A la date D17, G1 a été rapporté par un quidam au magasin M314, vraisemblablement perdu par son propriétaire (ou volé). Ne sachant que faire de G1, à la date D18 le magasin M314 l’a renvoyé à la centrale, laquelle ne connaissant pas (?) l’identité de son propriétaire l’a détruit (G1 ne pouvant pas réintégrer le stock).

Suis-je dans les clous ?


Autres questions :

Un gift vendu en caisse (ou activé) est-il anonyme ? Autrement dit, en cas de perte (ou de rechargement par exemple), sait-on qui en est le propriétaire ?

Dans votre 1er message, vous avez écrit :

« Un store peut envoyer des gifts vers d'autres magasins »

Mais par la suite, il semble que les seuls transferts possibles sont entre la centrale et les magasins, jamais directement entre magasins (message #6). Qu’en est-il ?

Je suppose qu’une fois vendu, un gift ne peut pas être racheté par la chaîne de magasins ou revenir dans le circuit (dans le stock de la centrale ou celui d’un magasin) d’une façon quelconque. Qu’en est-il ?

Un gift peut être utilisé, rechargé, signalé volé, perdu, retrouvé. Suivez-vous ces événements seulement pour les gifts vendus par les magasins ou aussi pour les gifts vendus directement à des clients ?


Observations

Vos associations T_ENVOYER_ENV et T_RECEVOIR_REC sont porteuses d’une propriété STR_ID permettant de retrouver un magasin : comme au niveau MLD il faudra ajouter une clé étrangère, cela revient à dire qu’au niveau conceptuel (rétro-conception oblige...) il faut remplacer cette propriété par une patte vers T_STORE_STR.

Pour le moment, je ne suis pas partisan de la prise en compte de la centrale en tant que magasin, car cela alourdit et complique pas mal les choses.


En attendant vos réponses, je repars explorer votre MCD, histoire de préparer un autre lot de questions et observations.

[fsmrel]

Si vous deviez conseiller un bouquin pour quelqu'un comme moi qui s'intéresse à cela mais qui débute, lequel serait-ce ?

Chronologiquement parlant, pour modéliser les données, il faut commencer par le commencement : diagramme de classes UML ou MCD Merise. Puisque vous êtes parti sur un MCD, le bel ouvrage de Dominique Nanci et Bernard Espinasse : Ingénierie des systèmes d’information Merise, deuxième génération doit figurer sur votre table de chevet.

Il y a aussi l’excellent ouvrage de Michel Diviné Parlez-vous Merise ? (gratuit, Merci Michel !), qui est du niveau de la 1re génération de Merise, et ne traite donc pas de l’héritage et toutes ces sortes de choses, mais qui est très clair (laissez toutefois tomber la partie MLD/MPD qui est bonne pour le pilon).

Pour suivre la chronologie, donc passer au niveau logique et plus précisément relationnel il faut s’embarquer dans l’ouvrage de référence de C.J. Date : An Introduction to Database Systems, Eighth edition, c’est un incontournable quand on veut vraiment maîtriser le sujet : sans un minimum de théorie, la pratique seule ça n’est pas terrible, pour jouer du Mozart il faut d’abord en passer par les gammes, tout le monde n’est pas Richter...

L'ouvrage de Date est tout à fait lisible, celui-ci a toujours cherché à rester clair. Si vous voulez un peu plus hermétique, fouillez chez Carlo Zaniolo, par exemple On the Design of Relational Database Schemata...

[Kropernic]

Bonsoir,
[...]
Je vais essayer de suivre un peu quelques uns des événements qui marquent la vie de cette chose mystérieuse que vous appelez GIFT.

Un gift est en fait un gift-cheque ou une gift-card. J'ai généralisé en une entité gift + typegift histoire de me prémunir de toutes nouvelles inventions du département marketing. 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. Un gift-cheque par exemple ne sera jamais rechargeable alors qu'une gift-card le sera toujours sauf dans certains cas. Du coup, comme les gift-cheques n'ont pas besoin de cet attribut, un héritage ne conviendrait-il pas mieux ?

Le gift G1 a fait partie du stock de la centrale pendant la période P11. Pendant la période P12, il a fait partie du stock du magasin M1. Considéré comme en excédent, G1 a été renvoyé à la centrale et a fait à nouveau partie du stock de celle-ci pendant la période P13. Quand M1 a commandé de nouveaux gifts à la centrale, elle a récupéré G1 (mais ça n’est qu’un effet du hasard). G1 a fait à nouveau partie du stock de M1 pendant la période P14. G1 a fait l’objet d’une vente en caisse à la date D15 (qui fait que la période P14 se termine la veille de D15). G1 a été utilisé dans 3 magasins différents le même jour (D16). A la date D17, G1 a été rapporté par un quidam au magasin M314, vraisemblablement perdu par son propriétaire (ou volé). Ne sachant que faire de G1, à la date D18 le magasin M314 l’a renvoyé à la centrale, laquelle ne connaissant pas (?) l’identité de son propriétaire l’a détruit (G1 ne pouvant pas réintégrer le stock).

Suis-je dans les clous ?

C'est tout à fait ça. Du moins dans la pratique. 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).
Il manque juste la partie où la centrale commande les gifts chez le fournisseur (fabriquant) mais j'en ai été informé que hier donc c'est normal.
Sinon concernant ce que vous appelez période, vous en feriez une entité à part entière ?

Autres questions :

Un gift vendu en caisse (ou activé) est-il anonyme ? Autrement dit, en cas de perte (ou de rechargement par exemple), sait-on qui en est le propriétaire ?

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é dans la transaction et donc se retrouvera sur le ticket dont j'ai les infos dans l'entité où la vente est historisée.

Dans votre 1er message, vous avez écrit :

« Un store peut envoyer des gifts vers d'autres magasins »

Mais par la suite, il semble que les seuls transferts possibles sont entre la centrale et les magasins, jamais directement entre magasins (message #6). Qu’en est-il ?

Les transferts de gifts ne sont effectivement qu'entre la centrale et les magasins. Mais 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.

Je suppose qu’une fois vendu, un gift ne peut pas être racheté par la chaîne de magasins ou revenir dans le circuit (dans le stock de la centrale ou celui d’un magasin) d’une façon quelconque. Qu’en est-il ?

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)

Un gift peut être utilisé, rechargé, signalé volé, perdu, retrouvé. Suivez-vous ces événements seulement pour les gifts vendus par les magasins ou aussi pour les gifts vendus directement à des clients ?

Nous suivons ces évènements pour tous les gifts. Juste une précision sur les 2 modes de ventes des gifts histoire d'être certain d'être sur la même longueur d'onde.
1 : la centrale reçoit une commande d'un client et puise dans son stock pour y répondre. Nous parlons ici d'une vente "offline".
2 : un client se présente à la caisse d'un magasin et signale qu'il voudrait une gift-card (par exemple) de 50€. Nous parlons ici d'une vente "online".

Dans le premier cas, la db devra en être informée via une action de l'utilisateur dans l'application.
Dans le second cas, la db en sera informée automatiquement via job qui prendra les infos dans la db des transactions caisses.

Observations

Vos associations T_ENVOYER_ENV et T_RECEVOIR_REC sont porteuses d’une propriété STR_ID permettant de retrouver un magasin : comme au niveau MLD il faudra ajouter une clé étrangère, cela revient à dire qu’au niveau conceptuel (rétro-conception oblige...) il faut remplacer cette propriété par une patte vers T_STORE_STR.

C'est ce que j'ai fait dans mon dernier MCD ou j'ai une double relation entre l'entité/association DEPLACEMENT et l'entité STORE.

Pour le moment, je ne suis pas partisan de la prise en compte de la centrale en tant que magasin, car cela alourdit et complique pas mal les choses.

Je m'en rends compte également au fur et à mesure que la conception se précise et de nouvelles infos viennent s'ajouter à l'ensemble.

En attendant vos réponses, je repars explorer votre MCD, histoire de préparer un autre lot de questions et observations.

Déjà un grand merci pour le temps consacrer. C'est en tout cas impressionnant de voir à quelle point vous cernez vite les choses. Je crois que même mon collègue qui travaille ici depuis plus de 20 ans ne cerne pas aussi bien ce "système" que vous. (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)


J'ai hâte de lire vos prochaines remarques !

[Kropernic]

Chronologiquement parlant, pour modéliser les données, il faut commencer par le commencement : diagramme de classes UML ou MCD Merise. Puisque vous êtes parti sur un MCD, le bel ouvrage de Dominique Nanci et Bernard Espinasse : Ingénierie des systèmes d’information Merise, deuxième génération doit figurer sur votre table de chevet.

Il y a aussi l’excellent ouvrage de Michel Diviné Parlez-vous Merise ? (gratuit, Merci Michel !), qui est du niveau de la 1re génération de Merise, et ne traite donc pas de l’héritage et toutes ces sortes de choses, mais qui est très clair (laissez toutefois tomber la partie MLD/MPD qui est bonne pour le pilon).

Pour suivre la chronologie, donc passer au niveau logique et plus précisément relationnel il faut s’embarquer dans l’ouvrage de référence de C.J. Date : An Introduction to Database Systems, Eighth edition, c’est un incontournable quand on veut vraiment maîtriser le sujet : sans un minimum de théorie, la pratique seule ça n’est pas terrible, pour jouer du Mozart il faut d’abord en passer par les gammes, tout le monde n’est pas Richter...

L'ouvrage de Date est tout à fait lisible, celui-ci a toujours cherché à rester clair. Si vous voulez un peu plus hermétique, fouillez chez Carlo Zaniolo, par exemple On the Design of Relational Database Schemata...

Merci bien. Pour ces liens. J'ai dors et déjà télécharger le livre de Michel Diviné que j'attaquerai ce soir dans le train (2h de trajet par jour, ça permet d'en lire des choses ^^)

Question à part : En ce qui vous concerne (et cela vaut aussi pour Cinéphil ^^), quelle méthode préférez-vous et pourquoi ? Quitte à m'orienter vers une des deux, autant choisir la bonne et je pense pouvoir faire confiance en vos décennies d'expérience

[CinePhil]

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. Un gift-cheque par exemple ne sera jamais rechargeable alors qu'une gift-card le sera toujours sauf dans certains cas. Du coup, comme les gift-cheques n'ont pas besoin de cet attribut, un héritage ne conviendrait-il pas mieux ?

Si c'est le seul attribut qui diffère, ce n'est pas utile car le type de gift suffit à savoir s'il est rechargeable ou non. En fait, dans ce cas, l'attribut lui même est inutile car redondant avec le type de gift.

Si par contre il y a des gift-cards rechargeables et d'autres non, l'attribut supplémentaire est utile et l'héritage peut être pertinent, surtout si le département marketing annonce déjà d'autres idées à implémenter dans le futur (des coupons numérisés dans un smartphone par exemple, c'est la grosse actualité du jour chez la pomme).

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

Je ne pense pas non. Une période n'est qu'un laps de temps entre deux instants horodatés. Si tous les événements relatifs à un gift sont enregistrés de manière horodatée, on peut retrouver chaque période de son cycle de vie.

Les transferts de gifts ne sont effectivement qu'entre la centrale et les magasins. Mais 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.

Ce qui revient je pense à l'idée que j'avais suggérée de faire un héritage de store vers centrale, cette dernière entité type ayant des associations spécifiques mais pas forcément d'attributs spécifiques par rapport à un store.

Question à part : En ce qui vous concerne (et cela vaut aussi pour Cinéphil ^^), quelle méthode préférez-vous et pourquoi ? Quitte à m'orienter vers une des deux, autant choisir la bonne et je pense pouvoir faire confiance en vos décennies d'expérience

Je crois l'avoir déjà dit dans cette discussion ; pour modéliser une base de données, je préfère largement le MCD de la méthode Merise. Un bon MCD se lit comme un livre où chaque association est une phrase (un peu plus compliquée pour les associations d'arité supérieure à 2 mais c'est une image).

En plus, en se fixant quelques règles, on évite des erreurs. Par exemple, je m'interdis de faire pointer une association sur une association. Si je suis confronté à cela, c'est qu'il faut que je transforme l'association en ce que j'appelle une "entité type associative".

Bref, le MCD est à mes yeux l'outil le plus rigoureux pour bien modéliser une BDD.

[Kropernic]

Me revoilà.

J'ai apporté quelques modifications :

- Notion d'héritage pour préciser les différents types de gifts plutôt qu'une généralisation ;
- Création d'une entité centrale héritant de store ;
- Ajout d'une association "activer" entre les entités gift et centrale (je l'avais oubliée celle-là. C'est ce qui sert pour les ventes offline histoire qu'on sache quelle valeur se trouve sur le gift)

Du coup, on voit bien que les déplacements se font entre la centrale et les magasins.

Par contre, j'ai encore du mal avec les cardinalités. Je pense que j'ai du me tromper car quand je passe du MCD au MLD, la table gift se retrouve affublé d'une série de colonne qui, selon moi, devraient se trouver dans leurs associations respectives.

Je dois encore ajouter la partie où le fournisseur entre en action mais je préfère d'abord clarifier ce qui nous occupe pour le moment (cette partie ne me semble pas la plus délicate à concevoir).

Qu'en pensez-vous ?

Vous trouvez les schémas en question en pièce jointe.

EDIT
@Cinéphil : Serait-il possible de changer le titre de la discussion car celle-ci n'a finalement plus rien à voir (il n'y a en fait que le premier message qu porte sur les relations réflexives...)

[CinePhil]

Je ne comprends toujours pas pourquoi il y a un mélange de Entity/relationship Diagram et de MCD merisien et c'est assez perturbant !

C'est quoi le tag <M> figurant à droite des propriétés dans chaque entité type ?

1) Les adresses des clients
ADDRESS_ADR -0,n----ADDRESS_CLIENT_ADC----1,n- CLIENT_CLI

Ceci veut dire qu'une adresse peut être celle de plusieurs client. Normal ?

ADDRESS_ADR -0,n----ADDRESS_CLIENT_ADC----1,n- CLIENT_CLI
TYPEADDRESS_TAD -0,n-----------|

Ceci veut dire qu'une adresse d'un client peut être de plusieurs types. Normal ?

J'externaliserait ADR_CITY dans une entité type CITY_CTY pour éviter d'avoir plusieurs orthographes pour la même ville.

2) La commande
COMMANDE_COM -1,n----COMMANDEDETAIL_CDT----0,n- GIFT_GFT

Ceci veut dire qu'un gift peut faire partie de plusieurs détails de commandes. Normal ?

3) Les mouvements
GIFT_GFT -0,n----MOUVEMENT_MVT----0,n- TYPEMOUVEMENT_TMV
STORE_STR -0,n----------------|

Ici, je pense que MOUVEMENT_MVT devrait être une entité type et non pas une association.
GIFT_GFT -0,n----concerner----1,1- MOUVEMENT_MVT -1,1----typer----0,n- TYPEMOUVEMENT_TMV
STORE_STR -0,n----effectuer----1,1--------|

=> Bonne habitude à prendre : nommer les associations avec un verbe à l'infinitif.
Par exemple, pour la précédente association, j'écrirais plutôt ceci, selon mon standard de nommage :
COMMANDE_COM -1,n----CDE_CONCERNER_GFT_CCG----0,n- GIFT_GFT

4) Les actions sur les gifts

Je pense que j'ai du me tromper car quand je passe du MCD au MLD, la table gift se retrouve affublé d'une série de colonne qui, selon moi, devraient se trouver dans leurs associations respectives.

Je ne pense pas que tu te sois trompé dans les cardinalités mais il doit y avoir une option dans PowerAMC pour l'obliger à créer une table associative lorsqu'il y a le couple de cardinalités {0,1 - 0,n}.

Par contre, il y a un léger problème il me semble au niveau de l'association DEPLACER_DEP. La patte vers CENTRALE_CEN me semble superflue. Si un store est habilité à déplacer un gift, la centrale, en tant que store particulier peut le faire aussi. Pas besoin d'ajouter la patte vers centrale.
Là aussi, je pense qu'une entité type DEPLACEMENT_DEP serait plus appropriée.

Idem pour DECLARER que je verrais bien en DECLARATION.

=============

C'est tout pour le moment comme disait l'autre !

[Kropernic]

Je ne comprends toujours pas pourquoi il y a un mélange de Entity/relationship Diagram et de MCD merisien et c'est assez perturbant !

C'est quoi le tag <M> figurant à droite des propriétés dans chaque entité type ?

N'ayant jamais pratiquer ni l'un ni l'autre, je ne vois pas où se trouve le mélange :-/. J'ai pourtant bien demandé à créer un "Conceptual Data Model" et les outils à ma disposition pour ajouter des composants graphiques étant limités, je suppose qu'ils sont réservés à ce genre de schémas. P-e power amc présente-t-il les choses différemment de la manière dont vous êtes coutumier ?

Pour le tag <M>, cela indique si l'attribut est obligatoire ou non (M pour mandatory). Donc vu qu'il faut bannir le bonhomme null (©fsmrel^^), tous les attributs devraient être obligatoire et on pourrait se passer du tag pour alléger le schéma mais c'est en fait utile lorsque power amc génère en toute fin, le script de création de la DB.

1) Les adresses des clients
ADDRESS_ADR -0,n----ADDRESS_CLIENT_ADC----1,n- CLIENT_CLI

Ceci veut dire qu'une adresse peut être celle de plusieurs client. Normal ?

Euh non. Mais j'ai toujours du mal pour arriver à déterminer les cardinalités des relations faisant intervenir plus de 2 entités. C'est pourtant très clair lorsque vous l'énnoncer... Je vais tenter de revoir ces relations en prenant les entités par couple.

ADDRESS_ADR -0,n----ADDRESS_CLIENT_ADC----1,n- CLIENT_CLI
TYPEADDRESS_TAD -0,n-----------|

Ceci veut dire qu'une adresse d'un client peut être de plusieurs types. Normal ?

Cela est juste . Il est tout à fait concevable que l'adresse de livraison soit la même que l'adresse de facturation par exemple.

J'externaliserait ADR_CITY dans une entité type CITY_CTY pour éviter d'avoir plusieurs orthographes pour la même ville.

C'est noté !

2) La commande
COMMANDE_COM -1,n----COMMANDEDETAIL_CDT----0,n- GIFT_GFT

Ceci veut dire qu'un gift peut faire partie de plusieurs détails de commandes. Normal ?

A première vue ça parrait bizarre mais prenons le cas suivant :
- 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)

3) Les mouvements
GIFT_GFT -0,n----MOUVEMENT_MVT----0,n- TYPEMOUVEMENT_TMV
STORE_STR -0,n----------------|

Ici, je pense que MOUVEMENT_MVT devrait être une entité type et non pas une association.
GIFT_GFT -0,n----concerner----1,1- MOUVEMENT_MVT -1,1----typer----0,n- TYPEMOUVEMENT_TMV
STORE_STR -0,n----effectuer----1,1--------|

=> Bonne habitude à prendre : nommer les associations avec un verbe à l'infinitif.
Par exemple, pour la précédente association, j'écrirais plutôt ceci, selon mon standard de nommage :
COMMANDE_COM -1,n----CDE_CONCERNER_GFT_CCG----0,n- GIFT_GFT

Je vais regarder cela. Pour la bonne habitude, je vais tâcher de m'y tenir.

4) Les actions sur les gifts

Je ne pense pas que tu te sois trompé dans les cardinalités mais il doit y avoir une option dans PowerAMC pour l'obliger à créer une table associative lorsqu'il y a le couple de cardinalités {0,1 - 0,n}.

Par contre, il y a un léger problème il me semble au niveau de l'association DEPLACER_DEP. La patte vers CENTRALE_CEN me semble superflue. Si un store est habilité à déplacer un gift, la centrale, en tant que store particulier peut le faire aussi. Pas besoin d'ajouter la patte vers centrale.
Là aussi, je pense qu'une entité type DEPLACEMENT_DEP serait plus appropriée.

Idem pour DECLARER que je verrais bien en DECLARATION.

Je m'en vais donc à la chasse à l'option .
Concernant la patte de l'association DEPLACER_DEP vers CENTRALE_CEN, c'est pour signaler qu'un bon est déplacer d'un store vers la centrale et de la centrale vers un store. Toujours ce problème de destination/origine pour lequel j'ai créé cette discussion en premier lieu...

C'est tout pour le moment comme disait l'autre !

Encore merci !

[Kropernic]

Je cherchais l'option en rapport avec les cardinalités et je tombe sur ceci (cfr. pièce jointe)

Voilà pourquoi vous êtes perturber par mon schéma ^^!

Je vais bien sûr modifier cela en Merise uniquement. On devrait y voir plus clair

EDIT : De fait, le tools que j'utilisais pour les relations n'est plus disponible. Les relations ont été converties en associations et je n'ai plus que ce tool pour mettre en "relation" deux entités.

[CinePhil]

1) Les adresses des clients
ADDRESS_ADR -0,n----ADDRESS_CLIENT_ADC----1,n- CLIENT_CLI

Ceci veut dire qu'une adresse peut être celle de plusieurs client. Normal ?

Euh non. Mais j'ai toujours du mal pour arriver à déterminer les cardinalités des relations faisant intervenir plus de 2 entités. C'est pourtant très clair lorsque vous l'énnoncer... Je vais tenter de revoir ces relations en prenant les entités par couple.

ADDRESS_ADR -0,n----ADDRESS_CLIENT_ADC----1,n- CLIENT_CLI
TYPEADDRESS_TAD -0,n-----------|

Ceci veut dire qu'une adresse d'un client peut être de plusieurs types. Normal ?

Cela est juste . Il est tout à fait concevable que l'adresse de livraison soit la même que l'adresse de facturation par exemple.

Donc le bon schéma serait plutôt celui-ci (en français simple pour clarifier) :
client -1,n----posséder----1,1- adresse -1,n----typer----0,n- type_adresse

A première vue ça parrait bizarre mais prenons le cas suivant :
- 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)

Il faudra effectivement une contrainte fonctionnelle pour ça. Et il vaudra mieux gérer cela par trigger ou procédure stockée en BDD pour garantir la cohérence des données.

Concernant la patte de l'association DEPLACER_DEP vers CENTRALE_CEN, c'est pour signaler qu'un bon est déplacer d'un store vers la centrale et de la centrale vers un store. Toujours ce problème de destination/origine pour lequel j'ai créé cette discussion en premier lieu...

OK. Il serait utile alors de le préciser quelque part.

Je cherchais l'option en rapport avec les cardinalités et je tombe sur ceci (cfr. pièce jointe)

Et bien voilà la raison du métissage !
Bizarre cette option !

[Kropernic]

Donc le bon schéma serait plutôt celui-ci (en français simple pour clarifier) :
client -1,n----posséder----1,1- adresse -1,n----typer----0,n- type_adresse

De fait, j'ai encore été mettre une entité/association alors qu'une association simple aurait suffit. J'ai l'art de compliquer les choses

Il faudra effectivement une contrainte fonctionnelle pour ça. Et il vaudra mieux gérer cela par trigger ou procédure stockée en BDD pour garantir la cohérence des données.

Je n'ai pas encore réfléchi d'un point de vue DB mais créer un trigger devrait être dans mes cordes (heureusement^^).

OK. Il serait utile alors de le préciser quelque part.

Ouais... Faudrait que je fasse un document où je reprends toutes les règles de gestion. Ce sera au moins utile pour mon collègue ^^.

Et bien voilà la raison du métissage !
Bizarre cette option !

Je n'ai par contre toujours pas trouver l'option de génération des tables en fonction des cardinalités... Je vais aller demander à mon ami google!

[CinePhil]

Il faudra que je me décide à installer PowerAMC un de ces 4 !
On l'a depuis plus d'un an quand même !

[Kropernic]

Et moi qui pleure depuis plus d'un an pour qu'on se procure des outils performants...

C'est d'ailleurs pour cela que je vous ennuie autant avec ce MCD car je n'ai qu'une période d'essai de 15 jours avec power amc (je l'ai installé dimanche).

Vous devriez avoir honte

[CinePhil]

Si tu es coincé par la suite, tu peux essayer Open Modelsphere qui est gratuit mais il ne permet sans doute pas autant de choses que PowerAMC qui est la Rolls en la matière.

[Kropernic]

Je l'avais déjà essayé j'avais laissé tombé.
Quel logiciel utilises-tu pour faire tes diagrammes ?

[CinePhil]

Ben Open Modelsphere mais ça fait un bail que je n'ai pas eu à en faire.

Il a l'avantage de fonctionner sous Linux, vu que je suis allergique à Winbug !