Discussion :

[Kropernic]

Bonjour à tous,

Après les gifts qui m'(nous) ont occupé il y a quelques mois, voici un nouveau projet nommé "Anti Mali".

Je n'ai pas encore de MCD à faire valider (à vrai dire j'en suis encore à établir les règles de gestion) mais j'ai déjà une question alors j'ouvre cette discussion histoire de centraliser les choses.

Mais avant tout, histoire qu'on parle bien de la même chose, voici le contexte dans lequel s'intègre ce projet.

Il s'agit de répertorier à quel endroit (zone) du magasin des étiquettes ou antivols sont retrouvés pour pouvoir définir les endroits qui nécessitent qu'on y renforce la surveillance afin de limiter le risque de vols.
Il s'agit de répertorier également les articles qui sont restitués lorsqu'un voleur se fait attraper par un garde à une sortie du magasin.

Voilà pour le gros du fonctionnel. Reste encore la notion de code démo (démo pour démonstration) à définir ainsi que celle de segment.

Code démo:
Nos magasins utilisent le système de "shops in the shop". C'est-à-dire que nous louons des espaces à des fournisseurs et ils y vendent leurs articles sur lesquels nous prenons une marge. Nous appelons ces articles des "articles démo". Démo pour démonstration. Chaque article (sans tenir compte des différences de taille ou de couleur) est identifié par un code démo. Et bien sûr, comme dans tous magasins, ces articles appartiennent à un rayon (homme, femme, enfant, lingerie, etc.).
Segment:
Un segment est en fait une partie de rayon. Par exemple, le rayon femme comprend les segments chemise, jupe, pantalon, etc.

J'ai donc les règles de gestion suivantes :
1°Un magasin possède au moins un étage et un étage est possédé par un magasin
2°Un étage possède au moins une zone et une zone est possédée par un étage
3°Une marque est associée à au moins un rayon et un rayon est associé à au moins une marque.
4°Un rayon peut être composé de plusieurs segments et un segment compose un rayon.
5°Un code démo détermine une marque + un rayon et une marque + un rayon peut déterminer plusieurs code démo.

La question :
La règle 5 comme telle, si j'ai bien intégré ce que j'ai appris au fil de mes lectures du forum, donnerait une association ternaire.
N'y a-t-il pas moyen de décomposé cette dernière en deux association binaire ?

J'apporterai bientôt un premier MCD histoire d'y voir plus clair.

EDIT : Correction de la règle 3°

[Kropernic]

Comme promis, voici un premier MCD de ce que j'ai présenté dans mon premier message.

Deux règles de gestion viennent déjà s'ajouter. La liste complète est donc :
1°Un magasin possède au moins un étage et un étage est possédé par un magasin
2°Un étage possède au moins une zone et une zone est possédée par un étage
3°Une marque est associée à au moins un rayon et un rayon est associé à au moins une marque.
4°Un rayon peut être composé de plusieurs segments et un segment compose un rayon.
5°Un code démo détermine une marque + un rayon et une marque + un rayon peut déterminer plusieurs code démo.
6°Un fournisseur fournit une ou plusieurs marques et une marque est fournie par un ou plusieurs fournisseurs.
7°Un fournisseur peut approvisionner (fournir étant déjà pris comme nom d'association...) plusieurs codes démo et un code démo est approvisionné par un fournisseur.

Vont encore venir s'ajouter les entités-types nécessaires (et les règles de gestions qui vont avec) pour la gestion des vols, restitution, sortie.

En attendant, je cherche donc à "simplifier" l'association ternaire DETERMINER.

[fsmrel]

Bonsoir Kropernic,


Je constate que vous ne restez pas inactif !

Je cherche donc à "simplifier" l'association ternaire DETERMINER.

L’association ternaire DETERMINER (RM dans le MCD ci-dessous) revient en fait à deux binaires, CM et CR :



Dans les deux cas, un code démo peut déterminer un rayon qui n’est pas associé à la marque du code démo, et bien sûr, vous vous demandez comment faire pour éviter cela.

On peut mettre en œuvre une contrainte d’inclusion (le graphisme ci-dessous est sans garantie, il s’agit surtout d’un mickey pour attirer l’attention) synthétisant la contrainte :

(CK1) Le code démo C ne peut figurer dans le rayon R que si la marque M déterminée par C figure elle aussi dans R.

Représentation graphique :




Plutôt que galérer avec les contraintes d’inclusion, on peut préférer transformer l’association RM en entité-type identifiée relativement à RAYON et MARQUE, et y connecter CODE_DEMO, tout en débranchant MARQUE et CODE_DEMO :




Je rappelle que, dans le cas de PowerAMC que j’utilise ici, l’identification relative fait l’objet de la mise entre parenthèses des cardinalités 1,1.


Le MLD produit par l’AGL est le suivant :



La contrainte (CK1) est bien respectée.

[Kropernic]

Bonsoir Kropernic,


Je constate que vous ne restez pas inactif !

Héhé, bien sûr que non ! Et j'espérais bien attirer votre attention

L’association ternaire DETERMINER (RM dans le MCD ci-dessous) revient en fait à deux binaires, CM et CR :



Dans les deux cas, un code démo peut déterminer un rayon qui n’est pas associé à la marque du code démo, et bien sûr, vous vous demandez comment faire pour éviter cela.

C'est exactement cela. En MLD (ou MPD ?) je vois plus ou moins comment procéder. En partant du MCD que j'ai posté, l'association entre rayon et marque donnera un table intermédiaire dont la clef primaire sera composée des clefs primaires des tables rayon et marque qui servira de clef étrangère pour la table code démo. Par contre, je galère vraiment à représenter cela au mcd. Et j'imagine que le fait que je n'arrive pas à conceptualiser cela convenablement révèle soit un manque de maitrise du concept, soit un manque de maitrise de la théorie relationnelle. Bref, j'ai encore du boulot

On peut mettre en œuvre une contrainte d’inclusion (le graphisme ci-dessous est sans garantie, il s’agit surtout d’un mickey pour attirer l’attention) synthétisant la contrainte :

(CK1) Le code démo C ne peut figurer dans le rayon R que si la marque M déterminée par C figure elle aussi dans R.

Représentation graphique :




Plutôt que galérer avec les contraintes d’inclusion, on peut préférer transformer l’association RM en entité-type identifiée relativement à RAYON et MARQUE, et y connecter CODE_DEMO, tout en débranchant MARQUE et CODE_DEMO :




Je rappelle que, dans le cas de PowerAMC que j’utilise ici, l’identification relative fait l’objet de la mise entre parenthèses des cardinalités 1,1.

Ce qui revient exactement à la solution que j'ai expliquée dans mon commentaire précédent . A défaut de PowerAMC (car pas encore de licence définitive et que ma licence d'essai à depuis longtemps expirée ), je teste donc JMerise. Qui jusqu'ici semble pas trop mal foutu et qui permet les liens relatifs. J'appliquerai donc la solution que vous proposez.

Le MLD produit par l’AGL est le suivant :



La contrainte (CK1) est bien respectée.

Et on arrive bien à un modèle logique tel que celui que j'ai décrit plus haut. J'ai donc encore du boulot mais c'est sur la bonne voie .

Merci pour votre intervention .

N.B. : Les deux jours qui viennent, je serai "malheureusement" (la formation est une bonne chose mais le projet va stagner pendant ce temps) en formation pour un nouvel outil permettant de générer des rapports nécessaires au magasin à partir des données de ventes. Je ne pourrai donc probablement plus donner de nouvelles de l'avancement avant vendredi.

[fsmrel]

Voici quelques éléments de réflexion pour meubler les moments de pause à l’occasion de votre formation...

En MLD (ou MPD ?) je vois plus ou moins comment procéder. En partant du MCD que j'ai posté, l'association entre rayon et marque donnera un table intermédiaire dont la clef primaire sera composée des clefs primaires des tables rayon et marque qui servira de clef étrangère pour la table code démo.
[...]
Ce qui revient exactement à la solution que j'ai expliquée dans mon commentaire précédent .

Hum... Utilisons par exemple PowerAMC (Why not? ). Pour reprendre votre MCD :




Voici le MLD produit par PowerAMC :



Pour PowerAMC, la clé de la table DETERMINER est le triplet {CodeDemoId, RayonId, MarqueId}, ce qui prouve en passant que le géniteur de l’AGL a oublié que la cardinalité maximale portée par la patte connectant l’entité-type CODE_DEMO et l’association DETERMINER n’est pas N mais 1. Il aurait dû prendre en compte les dépendances fonctionnelles qui sont les conséquences logiques de cette cardinalité maximale 1 :

{CodeDemoId} -> {RayonId},
{CodeDemoId} -> {MarqueId}.

D’où le MLD corrigé manuellement :




Mais de toute façon, ce MLD n’est pas satisfaisant, une fois ! En effet la paire {RayonId, MarqueId} de la table DETERMINER doit faire référence à la paire {RayonId, MarqueId} de la table ETRE_ASSOCIE, sinon la contrainte CK1 dont j’ai fait mention dans mon message précédent n’est pas garantie. Je rappelle que pour que la contrainte soit respectée, le MLD doit être le suivant (où RM est synonyme de ETRE_ASSOCIE) :




Je ne sais pas ce que JMerise vous produira comme MLD, mais de toute façon, la présence simultanée des deux tables DETERMINER et ETRE_ASSOCIE sans que la 1re fasse référence à la 2e fera que la contrainte CK1 ne pourra pas être garantie, même si, comme vous le conjecturez, la clé primaire de la table DETERMINER était la paire {RayonId, MarqueId}.


Pour le fun

La solution que je propose n’est pas forcément optimale même si elle garantit la contrainte CK1. En effet, conformément à votre MCD, j’ai bien respecté la cardinalité minimale 1 qui est portée par la patte connectant l’entité-type CODE_DEMO et l’association DETERMINER, mais quid si cette cardinalité minimale est 0 ? Pas de panique : la solution n’est pas bien compliquée, vous l’avez déjà mise en œuvre par le passé. Par exemple, on utilise la spécialisation (pour éviter une intervention manuelle dans le MLD, du moins avec PowerAMC) :



MLD :



Au stade SQL, il faudra quand même prévoir une assertion (un trigger à défaut) pour garantir la contrainte d’exclusion : un code démo ne peut pas être à la fois en rayon et pas en rayon...

Bon stage et à bientôt

[Kropernic]

Allez hop, un petit message en attendant mon taxi (je fais du co-voiturage avec mon chef jusqu'à Cologne^^)

Je ne comprends pas la signification de vos entités CODE_DEMO_EN_RAYON et CODE_DEMO_PAS_EN_RAYON.

Un code démo est en fait un code attribué pour identifier un type de marchandise d'un fournisseur dans une marque.

Si par exemple un fournisseur fourni des pantalons dans deux marques M1 et M2 différentes, il aura alors un code démo pour chacune, respectivement C1 et C2. Si à coté de ça, il fournit aussi des chaussettes de la marque M1, il aura alors un code démo C3. Le rayon ici est déterminé par le type de marchandise. Il est évident que les pantalons n'ont pas la même rayon que les chaussettes.
N.B. : Il est à noté que rayon est à prendre au sens informatif (logique) et non pas dans le sens rayon concret sur la surface de vente. A priori, rien n'empêcherait (même si ce n'est pas le cas), que des chaussettes soient vendu à côté de pantalons sur le même rayon physique. (Tiens, on retrouve la séparation entre le logique et le physique, c'est amusant)

Du coup, un code démo déterminera TOUJOURS un rayon et une marque. D'où mon incompréhension.