Discussion :

[clarence]

Bonjour,

Pouvez-vous me guider sur la relation n-aires suivantes :
J'ai 5 tables qui sont liés hiérachiquement : la 1ère englobe la seconde...

- Sections
- Catégorie
- Sous-catégories-Articles
- Articles liés

merci pour vos réponses.

[BizuR]

Bonjour,

Pouvez-vous me guider sur la relation n-aires suivantes :
J'ai 5 tables qui sont liés hiérachiquement : la 1ère englobe la seconde...

- Sections
- Catégorie
- Sous-catégories-Articles
- Articles liés

merci pour vos réponses.

Et on est sensé faire quoi avec ca ? Une relation n-aires, c'est une relation n-aires, je vois pas vers où nous devons te guider ... en outre, euh, on ne connait même pas le contexte dans lequel évoluent tes entités ... (ou associations d'ailleurs),

Pourrais-tu nous fournir un semblant d'explications supplémentaires?

[clarence]

Bonjour,

Vous trouverez ci-joint une début de MCD. Mais je ne parviens pas à un faire un lien logique entre les entités "utilisateurs" du site qui peuvent être de 3 types : administrateurs du site, client (ayant déjà fait la demande d'un devis), visiteur.
Ensuite, comment considérer les "contacts" ceux qui remplissent un formulaire.
Enfin, comment considérer ceux qui s'abonne à une newsletter.

Merci pour vos éclairages.

[BizuR]

Hum, je n'ai malheureusement pas de logiciel adequate pour lire ton fichier ... tu crois que tu pourrais nous laisser une screenshot ou mieux, une image enregistrée via ton logiciel s'il te plait ?

Merci, je veux bien te donner un coup de main dans la foulée si je peux

[clarence]

Oui, je travaille sous PowerAMC.
Je vous en fait un fichier doc.
Merci.

[Médiat]

1. Je ne comprends pas l'entité TypeUtilisateur avec 3 id.
2. Je trouve bizarre que les clients ne soient pas des utilisateurs.
3. Il me semble que la hiérarchie Article, Section, Catégorie, Sous-Catégorie devrait être Article, Sous-Catégorie, Catégorie, Section.
4. Les articles et les articles liés semblent être de nature bien semblable, est-ce qu'il faut comprendre "lié" comme une nature de l'article, ou bien est-ce qu'un article lié n'est pas un article qui se trouve être lié à un autre (une hiérarchie réflexive), en particulier, dans ton MCD, le fabricant d'un article est forcément le fabricant de tous les articles liés à cet article. Berf cette notion d'article lié, telle qu'elle est modélisée me paraît très étrange...

[BizuR]

Bon d'apres ce premier schema ... je trouve tout d'abord dommage de créer deux entités distinctes pour articles et articles_liés. Ca veut donc dire qu'un article ne sera JAMAIS un article lié ou bien risques-tu d'avoir un doublon dans les deux tables ?!?

Il est alors possible de n'avoir qu'une seule entité articles reliée à elle même avec une association (et dans ce cas, une simplé clé étrangère sur la table éviterai de créer une seconde table voire des doublons...

Sinon, pour ton problème principal, tu ne modélises pas vraiment la partie site ici même mais plutot la zone de commande. Il peut arriver que certaines tables n'aient aucun lien logique... ici, le seul lien que je vois serait un heritage entre client et utilisateurs (si j'ai bien compris)... il faudrait alors également modéliser les autres utilisateurs, c'est-à-dire les admin et les abonnés...

Pour ce qui est des visiteurs, si ils sont anonymes, dois-tu réellement les rendre persistants ? Idem pour les contacts remplissant un formulaire de je ne sais quoi .... si ce formulaire sert à l'abonnement ou l'inscription, ils deviendront irrémédiablement utilisateurs (abonnés ou clients).

Est ce que cela répond à ta question ? C'est peut etre pas forcément clair, mais n'hésite pas à le dire, pour que je m'explique mieux si besoin est

EDIT: Ah oui, tiens j'avais pas vu ce groupe_utilisateurs, si tu veux les distinguer, je pense qu'une entité type_utilisateurs avec un id et un libelle sera amplement suffisant ... si ils ont plusieurs roles (comme je pense le comprendre), alors dans ce cas, c'est à toi de créer une association avec l'id spécifique en attribut d'association dans ce style :

Code :

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

1
2
3
utilisateur -- 1,3 -------- A POUR ROLE ---------- 0,n -- type_utilisateur
                              id_role

avec id_role = id qu'il possède selon son type d'utilisateurs...

Maintenant, je ne sais pas si cela te servirai... autant conserver l'id_utilisateur pour tout plutot que d'en creer un spécifique à chaque role que jouera un utilisateur.

[clarence]

Ma réponse :

1- Distinction Articles et Articles liés : les articles liés sont vus comme des accessoires et il y a une indépendance "logique" entre ces 2 tables.

2- La modélisation : mon objectif est de traduire le chaîne de demande d'un devis. En fait la modélisation d'une séquence d'achat (avec gestion d'un caddy) mais qui excluerait le paiement. En lieu et place, l'envoi par mail de l'état récapitulatif de la sélection.

3- La prise en compte des utilisateurs : peux-tu me traduire en Merise l'héritage entre client et utilisateurs et la prise en compte des admins et abonnés ?

4- Considération des "visiteurs" : je ne les prends pas en compte finalement. Je les considère comme "transparent".

5- La décomposition Section / Catégorie / Sous-Catégorie / Articles s'inspire de celle adoptée par les CMS (Joomla!...)

Merci pour vos interventions.

[BizuR]

3- La prise en compte des utilisateurs : peux-tu me traduire en Merise l'héritage entre client et utilisateurs et la prise en compte des admins et abonnés ?

4- Considération des "visiteurs" : je ne les prends pas en compte finalement. Je les considère comme "transparent".

ok pour les visiteurs, j'en pense tout autant.

POur les utilisateurs, tu dois etre confrontée à une décision qui est la suivante : L'utilisateur n'a til qu'un seul et unique role ? ou bien peut il avoir les trois ?

Selon la réponse, tu pourras adopter un modélisation adéquate reposant sur l'héritage et les contraintes sur le modèle

[clarence]

On peut distinguer finalement 3 utilisateurs :

- Un utilisateur qui a le rôle d'administrer le site
- Un (des) utilisateur(s) qui peuvent faire une demande de devis
- Un (des) utilisateurs(s) qui peuvent s'abonner à une newsletter

NB : en y réfléchissant un peu je n'ai en fait pas de client (si je considère le client comme celui ayant transformer sa demande de devis en achat)

A partir de là peux-tu corriger et compléter mon MCD ?

Merci.

[BizuR]

Et bien, ca reste simple, si aucun ne peut empieter sur l'autre, un heritage avec deux contraintes de totalite et partition semble s'imposer

Ca donne cela :



En résumé (oui, le schema est moche mais bon, c'est du paint vite fait), tu as ta classe "utilisateur" qui se transforme en 3 sous classes qui sont "Admin" OU "Client" OU "Abonnés" (ce sont des OU EXCLUSIF)
La contrainte T implique la totalité et donc le fait que tous les utilisateurs enregistré font partie d'une ou plusieurs de ces trois familles
La contrainte P implique la partition qui signifie que tout utilisateur ne fait partie que d'une des trois familles...

En écrivant cela, il faut vérifiere mais je me demande si Partition n'inclus pas Totalité ... en gros, soit tu remplace P par X (X = exclusivité, donc aucun ne fait partie de plusieurs, il ne font partie que d'une seule sous classe) ... soit tu enlève T ... si c'est pas clair, jpeux te refaire un dessin

J'espere que cette réponse te satisfera

[Médiat]

5- La décomposition Section / Catégorie / Sous-Catégorie / Articles s'inspire de celle adoptée par les CMS (Joomla!...)

Dommage, parce que ce n'est pas ce que tu as fait !

[clarence]

Bonjour,

Si je suis dans l'erreur, je me permets de vous communiquer l'état actuel du MCD. Etant débutant dans l'analyse, je fais appel à votre aide pour corriger les erreurs sur le document ci-joint et compte tenu des observations précédentes.

Merci pour votre intervention.

[clarence]

Pièce jointe.

[BizuR]

Alors, que l'on se mette bien d'accord :
Tel que tu représente ton modèle de l'utilisateur, je l'interprete comme suit :
- Un utilisateur peut avoir plusieurs roles
- A chaque role, je lui associe un ID propre (attribut de ton association)

Le seul problème de cette modélisation, c'est que l'utilisateur peut avoir plusieurs fois le même role ... ce qui n'ira pas pour t'arranger (désolé, j'ai peut etre fait le schema un poil vite hier mais c'etait ma première idée).

Je pense vraiment que tu peux reprendre le tit dessin que je t'ai fait hier, il exprimera surement mieux l'idée d'organisation des utilisateurs de ton site (et permettra accessoirement de regrouper client a utilisateur par la même occasion).

Sinon tu n'as pas corrigé la remarque (juste d'ailleurs) de Mediat concernant Articles >> Sections >> Categorie >> Sous Categorie de ton modèle... Pour être en accord avec ce que tu disais, il faut relier :

Sous catégorie à Article
Catégorie à Sous catégorie et
Section à Catégorie

... ce qui n'est pas ton cas comme tu peux le voir ... Articlen n'est pas relié a la bonne entité

Voila tout pour le moment en ce qui me concerne

[clarence]

Ci-joint la nouvelle représentation.

Est-ce que cela convient ?

Merci.

[BizuR]

On y arrive

Il ne manque plus qu'a :
- Virer la relation Sections/Articles, qui n'as plus lieu d'être
- Virer l'entité typeUtilisateur et l'association qui va avec puisque l'héritage va maintenant te permettre d'identifier qui fait quoi.
- Poser une contrainte de Partition (ou bien Totalité + eXclusion) entre les trois entités filles pour bien montrer que l'utilisateur ne peut être qu'un des trois (enfin si c'est bien comme cela qu'il faut le voir)

Sinon, pour ma part, je dirai que ca semble correct. Tu dois modéliser encore autre chose (newsletter par exemple pour la relier avec l'abonné) ou non ?

[newmind]

Désolé g pas tout lu mais il me semble que la solution est plus simple.

En fait un client est un utilisateur qui a passé une commande. donc si tu parse tes commandes tu retrouve l'id de tes utilisateurs CLIENT.
De meme un abonné est un utilisateur avec un booleen (abonné oui-non)
Et un administrateur n'est pas un utilisateur.

DONC 3 tables UTILISATEUR(avec booleen aboné ou pas),ADMINISTRATEUR,COMMANDE,...

Et voila.