Discussion :

[tiger33]

Bonjour,

Le contexte : 1 site d'échange de mangas animés "non-licenciés" par voie numérique et/ou postale accompagnés de news sur le monde de la japanimation.

2 sortes d'users(concernant les échanges) :

1. Les traders (ceux qui échangent par la poste booléen trader=1)
2. Les autres

Pour les traders un système de Liste Blanche=bon trader et liste noire =mauvais trader sera mis en place.

edit : j'ai supprimer le début de mcd en PDF et mwb (Mysql Workbench) zippé (voir MCD + complet à la fin du topic)

Les question :

1. Y'a-t-il des énormités sur l'ensemble du schéma
2. une catégorie de news n'est modérée actuellement que par un modérateur puis-je faire un truc du style "set d'idUtilsateurs" ? (en changeant la cardinalite de la relation bien-sûr)
3. Comment faire et alimenter les deux liste de traders (les deux booléens actuels ne me vont pas bien)

merci beaucoup

[JPhi33]

Bonjour tiger33,

2 sortes d'users(concernant les échanges) :

1. Les traders (ceux qui échangent par la poste booléen trader=1)
2. Les autres

Pour les traders un système de Liste Blanche=bon trader et liste noire =mauvais trader sera mis en place.

D'une manière générale, avant de modéliser directement des tables, je te conseille de passer par une étape de modélisation conceptuelle (modèle relationnel ou modèle Entité-Association Merise, par exemple) ce qui te permettra d'éviter bien des pièges, retours arrières ou incohérences de ta base de données (tutoriels disponibles sur ce site).

Pour distinguer les traders des autres utilisateurs je te conseille de recourir au concept de généralisation / spécialisation que j'ai déjà exposé sur ce forum ici entre autres.
Tu seras amené à distinguer, parmi la population des utilisateurs, le sous-ensemble des traders pour lequel seulement les notions de liste blanche et liste noire existent. Ceci te permettra de mettre au rancart le booléen Trader.

Y'a-t-il des énormités sur l'ensemble du schéma

J'ai un doute sur la relation Utilisteurs -- Catégorie : 1 Utilisateur est lié à une seule Catégorie et 1 Catégorie est liée à un seul Utilisateur.

puis-je faire un truc du style "set d'idUtilsateurs" ? (en changeant la cardinalite de la relation bien-sûr)

Qu'est-ce qu'un "set d'idUtilsateurs" ?

Comment faire et alimenter les deux liste de traders (les deux booléens actuels ne me vont pas bien)

Un trader est soit en liste blanche soit en liste noire. Un seul booléen suffit, par exemple "liste_trader". S'il est à "Oui", le trader est en liste blanche ; s'il est à "Non", le trader est en liste noire. A moins qu'un trader puisse n'être dans aucune liste...


JPhi33

[tiger33]

JPhi33,

merci ta réponse claire, maintenant c'est clair qu'il me faut un héritage entre utilisateur et trader. avant de mettre résolu, connais-tu un win-design-like gratuit qui puisse générer du mysql automatiquement ? (je ne peux pas physiquement me servir d'une feuille et d'un crayon)

"set d'idUtilisateur", çà n'est pas très clair ok alors j'explique

mon champs modérateur dans la table catégorie peut-il être de type set et au lieu d'avoir set('toto',tata','tutu') puis-je avoir set(utilisateur.idutilisateur.value)ou un truc du genre ?

merci

[JPhi33]

Bonjour tiger33,

connais-tu un win-design-like gratuit qui puisse générer du mysql automatiquement ?

Non, mais tu peux regarder dans le sous-forum Outils du forum Conception.

"set d'idUtilisateur", çà n'est pas très clair ok alors j'explique

mon champs modérateur dans la table catégorie peut-il être de type set et au lieu d'avoir set('toto',tata','tutu') puis-je avoir set(utilisateur.idutilisateur.value)ou un truc du genre ?

Tu devrais poser cette question dans le forum MySQL (ici, c'est un forum plutôt orienté modélisation conceptuelle)

[tiger33]

ok voila le mcd refait, sous forme jpg, désolé pour la taille.

une seule question : mcd valide ou erroné ? (c'est un peu vague je sais,mais je ne vois rien de particulier sur quoi m'attardé.) En gros, Le MCD vous semble-t-il :

• Respecter Merise ?
• Répondre aux besoins exprimé plus haut (il me semble, mais j'ai la tête dans le guidon)
• ëtre exempt de choses qu'on pourrait simplifier

(çà fait trois questions)
j'ai rajouté la listeEchangeable "composée" d'itemEchangeable.
J'ai égalment Ajouté deux entiers pour compté le nombre de transactions et les"bonnes" (le booléen listeNoire passera à true si bonneTransact<=NombreTransact/2)

EDIT : Il semble que j'aie des problèmes "d'index inclusion" au moment du passage au Mpd. cela concerne les association "modérePar" et la composition "contient". Je ne sais pas si c'est une erreur conceptuelle ou d'utilisation de PowerDesigner 12.5
merci

[JPhi33]

tiger33,

moderePar

Les utilisateurs qui modèrent des catégories ont une particularité qui est (justement) d'être modérateur. En conséquence, l'association moderePar ne s'applique qu'aux utilisateurs qui ont cette fonction (ça me semble être "Modo").

Tu pourrais spécialiser Utilisateurs en Modérateurs. "moderePar" serait alors une association entre Modérateurs et Catégorie ayant une cardinalité 1,n côté Modérateurs. En contrepartie, il y a une entité supplémentaire à gérer : insertion dans Modérateur quand un Utilisateur le devient, suppression quand il arrête sa fonction de modérateur.

Malgré cette contrepartie tu y gagnes car tu évites les risques d'incohérences : Utilisateur de fonction "Modo" sans Catégorie ou Utilisateur non "Modo" lié à des Catégories.


fonction

Une question de candide : un Modo peut-il être aussi Uploader ? Autrement dit, parmi les fonctions que tu as définies, se peut-il qu'un Utilisateur en exerce plusieurs à la fois (ce qui poserait évidemment quelques problèmes).


Pour le reste, ça me sembre correct. Evite quand même les pattes d'associations qui se croisent et les association qui chevauchent des pattes ("rattacheA").


JPhi33

[tiger33]

Jphi33,

c'est vrai pour modo, je vais faire la spé.
l'utilisateur peux exercer plus d'une fonction, effectivement. mais il y aurait une hierachie des fonction (ce qui, si je voulais le traduire donnerais des spécialisations progressive -- modo est un uploader particulier admin un modo modo particulier et root un admin particulier--)

Sais-tu pourquoi j'ai ces message "d'index inclusion" lors du passage mpd ? (avec powerDesigner)
de plus il ne veut pas que idItem ne soit auto incrémenté, il me semble pourtant que dans la composition l'élément qui compose a sa propre clé.
Je sais qu'on sort du domaine conceptuel mai je ne vais pas réexpliquer tout dans le forum outils (d'autant plus que c'est peut-être lié au conceptuel)
regarde la capture d'écran
merci encore.

[JPhi33]

Bonjour,

Sais-tu pourquoi j'ai ces message "d'index inclusion" lors du passage mpd ? (avec powerDesigner)

Désolé, je ne connais pas powerDesigner.

de plus il ne veut pas que idItem ne soit auto incrémenté, il me semble pourtant que dans la composition l'élément qui compose a sa propre clé.

Ca me semble logique.

itemEchangeable est identifiée selon le principe d'identification relative. C'est-à-dire que son identifiant propre, idItem, ne suffit pas à distinguer de manière unique chacune de ses occurrences. Pour y parvenir, elle doit s'appuyer sur une autre entité identifiée de manière absolue : ListeEchangeable. L'identifiant unique de itemEchangeable est donc composé :
- de l'identifiant absolu idListe
- de lidentifiant relatif idItem

itemEchangeable est qualifiée d'entité faible ; ListeEchangeable est une entité forte.


Exemple

Code :

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

1
2
3
4
5
6
7
8
9
ListeEch.   itemEch.

idListe     idItem
-------     ------
   1          1
   1          2
   2          1
   2          2

Le véritable identifiant de itemEchangeable est donc {idListe, idItem}. Or voici ce qui se passe si tu utilises une donnée de type auto-incrémenté pour idItem :

Code :

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

1
2
3
4
5
6
7
8
9
ListeEch.   itemEch.

idListe     idItem
-------     ------
   1          1
   1          2
   2          3
   2          4

Dans ce cas, itemEchangeable n'est plus identifiée par rapport à ListeEchangeable mais elle dispose d'un identifiant absolu.


Le type auto-incrémenté est incompatible avec le concept d'identifiation relative pour l'identification d'une entité faible.


JPhi33