Discussion :

[fsmrel]

Bonsoir,

Merci de prendre de votre temps pour m'aider.

Je peux prendre un peu de temps, car vous n'êtes pas tout seul à être concerné par ce qui suit, à savoir retoucher un MLD produit par Power AMC et dont on n'est pas entièrement satisfait¹.

Le problème avec le MLD que vous a fourni Power AMC (et que vous ne m’avez pas transmis, hum...) est qu’il génère des cycles du fait des cardinalités 0,1 / 1,1 utilisées pour les associations-types EST_UN et Commentant. Pour arranger ça, soit on supprime le cycle manuellement dans le MLD, soit au niveau MCD on utilise l’héritage, soit encore (toujours au niveau MCD) on panache la notation Merise et la notation entité-association (alias entité-relation).


Héritage en fonction du type de commentaire : commentaire sur article vs commentaire sur commentaire

Sémantiquement parlant, on peut considérer qu’il y a des commentaires qui portent sur des articles et des commentaires qui portent sur des commentaires : on peut ainsi spécialiser les commentaires en fonction de ce sur quoi ils portent. On peut encore considérer que seuls ici les commentaires qui portent sur des articles méritent d’être mis en évidence dans le cadre de la spécialisation et on le fait de la façon suivante (utilisation du lien d’héritage, symbolisé avec Power AMC par une demi-lune) :

A noter qu’il faut demander à Power AMC qu’au niveau du MLD, il ne recopie pas dans la table COM_ART l’ensemble des colonnes de la table COMMENTAIRE, mais seulement la colonne CommentId, on retient donc l’option « N’hériter que les attributs primaires » (fenêtre "Propriétés de l'héritage") :




Dans ces conditions, la table COM_ART générée sera conforme à ce qu’on attend :



Héritage en fonction du type de commentaire : commentaire commentant vs commentaire commenté

Concernant les commentaires sur commentaires : A nouveau au plan sémantique, on peut considérer qu’un commentaire est soit « commentant » soit « commenté » et le MCD peut être ainsi transformé :

Comme dans le cas des propriétés de l’héritage EST_UN, on retient l’option « N’hériter que des attributs primaires ».

Au niveau du MLD, comme la table COMM_COMM doit faire directement référence à la table COMMENTAIRE, au niveau MCD on décoche l’option « Générer » pour l’entité-type COMMENTE_PAR :


Et lors du passage du MCD au MLD, Power AMC produit quelque chose comme ceci :

Même si ça n’est pas indispensable, il est préférable de renommer les colonnes Colonne_2 et CommentId de la table COMM_COMM, car leurs noms sont trompeurs :


Panachage des notations Merise et E-R

Au niveau MCD, pour panacher, sélectionner :

Outils > Options du modèle > paramètres du modèle

Notation : E/R + Merise

Prenons le cas de la relation EST_UN (il s’agit d’une association-type, mais on va utiliser le vocabulaire de Power AMC).

Actions :

Supprimer la relation EST_UN existante.

Cliquer sur l’icône Relation :



Tirer un lien de COMMENTAIRE vers COM_ART :


Nommer la relation en EST_UN :




Cliquer sur l’onglet « Détails » (j’utilise Power AMC V11, mais avec la V15, l’onglet s’appelle « Cardinalités ») :




Cartouche COMMENTAIRE vers COM_ART : remplacer la cardinalité 0,n par 0,1.

Cartouche COM_ART vers COMMENTAIRE : cocher la case « Dépendant » : ceci revient à dire qu’on utilise l’identification relative (symbolisée ici par un triangle côté COM_ART).

Rôle dominant : Sélectionner « COMMENTAIRE -> COM_ART » : ceci a pour conséquence qu’il n’y aura pas de génération de cycle lors de la production du MLD.




En conséquence, on obtient ceci :

La notation est rigolote, mais en termes de cardinalités elle est équivalente à la notation Merise :

Une occurrence de COM_ART fait référence à exactement une occurrence de COMMENTAIRE, tandis qu’une occurrence de COMMENTAIRE est associée de façon facultative a au plus une occurrence de COM_ART (au sens fonctionnel, on a une injection).

En tout cas, Power AMC génère ce que l'on attend au niveau MLD :




Vous pourriez aussi tirer profit de la lecture des discussions suivantes :

http://www.developpez.net/forums/d84...s/#post4835570

http://www.developpez.net/forums/d89...able-jointure/

http://www.developpez.net/forums/d10...e/#post5662260

http://www.developpez.net/forums/d10...sociation-1-n/

__________________
¹ Notez bien qu’un MLD (modèle logique de données), ou plus prosaïquement diagramme logique, est du niveau logique et qu’il ne faut pas le confondre avec le MPD (modèle physique de données) où l’on prend en compte la tuyauterie propre au SGBD (index, allocation en espace sur les disques, etc.)

[heretik25]

Bonjour fsmrel,

Merci, je regarde ça attentivement.

[heretik25]

Bonsoir,

Un grand merci pour cette explication qui ma permit de comprendre les bases du phénomène d'héritage.

Pouvez-vous regarder si le fichier ci-joint correspond bien ?

Aussi, j'aimerais poursuivre avec vous la finalisation de mon MCD car j'aimerais arrêter de cauchemarder dessus .

Ainsi, comme vous le constaterez sur le MCD, mes articles peuvent être de différents types, ils peuvent aussi être rattachés à une catégorie, elle même rattachée à des sous catégories et avoir des mots clés.

Il y a aussi le fait qu'un article peut posséder un fichier GPS (une balade à pied par exemple). Il y a aussi le cas particulier des périples qui sont des articles mais très longs. Ainsi, je pensait stocker le contenu de ces périples dans une table à part "contenu_periple" qui contiendrait les pages découpées avec la référence à l'article. A noter qu'un périple peut aussi être attaché à un fichier GPS.

L'article "entretien" est aussi inféodé à une durée et à une difficulté.

Pour gérer toutes ces particularités, on m'a proposé de créer une table "article_extra" contenant l'ensemble de ces particularités. Cela me paraît un peu étrange... Comment géreriez vous le cas qui est, s'il en est, un peu complexe ?

Encore merci.

[fsmrel]

Bonjour,

L'article "entretien" est aussi inféodé à une durée et à une difficulté.

Quelque part, l’article ENTRETIEN est une spécialisation de l’article. On peut y aller d’un petit héritage :

mes articles peuvent être de différents types

« Peuvent être » est synonyme de « facultatifs », mais puisqu’il y a une cardinalité 1,1, il faut écrire : « un article est exactement d’un type » (ou encore, « un article est au moins et au plus d’un type »).
Attention au nom de l’association-type « Être » entre ARTICLE et TYPE_ARTICLE : on doit l’interpréter comme « un article est un type d’article » alors qu’un article est d’un type d’article, nuance... Le nom de l’association-type est à revoir.

ils peuvent aussi être rattachés à une catégorie

Cette fois-ci, l’expression « peuvent être » est en accord avec la cardinalité 0,1, même s’il est préférable d’écrire : « un article peut être rattaché à une catégorie ». Pour éviter les cycles générés par Power AMC lors de la dérivation du MCD en MLD, on peut pousser le bouchon, user du subterfuge de la spécialisation et considérer qu’il y a des « articles à catégorie » et des « articles hors catégorie » :

une catégorie, elle même rattachée à des sous catégories

A priori, une sous-catégorie est associée à une catégorie par une relation de composition, une catégorie est composée de sous-catégories : le nom de l’association-type ne devrait pas être « peut être associé à » mais « Composer » et SOUS_CATEGORIE est à identifier relativement à CATEGORIE (Fenêtre « Propriétés du lien d’association », cocher la case « Identifiant »).

un article peut posséder un fichier GPS

Allons-y à nouveau d’un détournement d’héritage...

je pensais stocker le contenu de ces périples dans une table à part "contenu_periple" qui contiendrait les pages découpées avec la référence à l'article

De même qu’une facture est composée de lignes de facture, un article peut être composé de pages (noter l’identification relative) :

A noter qu'un périple peut aussi être attaché à un fichier GPS.

Dans la mesure où un article comporte au plus un fichier GPS, a priori le périple, l’ensemble des pages correspondantes (ART_PAGE) qui lui est associé l’est via ARTICLE. Dans ce cas-là, le périple attaché à un fichier GPS est celui qui est attaché à l’article, à moins qu’un article ait un périple distinct de celui du fichier GPS attaché à l’article....

on m'a proposé de créer une table "article_extra" contenant l'ensemble de ces particularités

Ça n’est pas à recommander, car on replie le modèle, on en affaiblit la sémantique en cachant l’information, le typage des données devient inexistant (on le fournit en partie indirectement par un type système basique du genre VARCHAR, mais si par exemple on utilise une seule entité-type pour les utilisateurs et les articles, comment distinguer le type id_user du type id_article ? Cela revient à mélanger, comparer des choux et des carottes), on complexifie la manipulation, l’intégrité des données en prend un coup : l’approche "article_extra" est à utiliser à dose homéopathique, quand on est pressé par le temps ou à court de budgets et qu’on maîtrise bien le sujet de la métamodélisation. Voir l’article (à mon avis un peu trop louangeur) présentant ce thème.

N.B.

• Les propriétés de vos entités-types sont toutes optionnelles : aucune ne doit l’être (sinon le bonhomme NULL se manifestera au niveau tabulaire).
  
• Entité-type USER : changer le nom, car "USER" est un mot réservé en SQL (au moins dans la norme).

[heretik25]

Bonsoir,

Encore une fois, merci pour votre aide précieuse. J'ai appliqué vos remarques au MCD.

Outre vos modifications, j'ai ajouté deux tables:


La première : "secteur_periple" qui permettra de savoir si le périple à eu lieu en France, en europe, en asie...

La seconde : "departement_balade" permettra d'attacher une balade à un département. Si une balade traverse plusieurs départements, ce n'est plus une balade mais un périple. Si elle est limitrophe, l'utilisateur choisira un des deux départements.

Concernant votre remarque sur les entités qui sont optionnelles, je n'ai pas très bien saisi et n'ait pas trouvé l'option. Pouvez-vous détailler ?

En générant le MPD, je remarque une étrangeté pour les entités "fichier_gps", "departement_balade" et "secteur_periple" qui héritent, me semble t-il d'informations inutiles.

Merci de m'éclairer !



Ci-joint, le mcd modifié, qui commence à prendre forme.

[fsmrel]

Bonsoir,

Concernant votre remarque sur les entités qui sont optionnelles

Je n’ai pas parlé d'un (pour le moins hypothétique !) caractère optionnel des entités-types (entités chez Power AMC), mais de celui de leurs propriétés (attributs chez Power AMC). Ainsi, si vous cliquez sur l’entité-type ARTICLE, il y a ouverture de la fenêtre « Propriétés de l’entité ARTICLE », vous cliquez alors sur l’onglet « Attributs » et pour chaque attribut, vous cochez la case « O » (« O » comme « Obligatoire »).

Outre vos modifications, j'ai ajouté deux tables

Vous n’avez pas ajouté deux tables, mais deux entités -types car vous êtes au stade du MCD.

En générant le MPD, je remarque une étrangeté pour les entités "fichier_gps", "departement_balade" et "secteur_periple" qui héritent, me semble t-il d'informations inutiles.

Avez-vous tenu compte de ce que j’ai précisé dans un message précédent ? (On n'hérite que des attributs « primaires » (sic !)) :




Concernant l’entité-type DEPARTEMENT_BALADE, l’attribut Dept_balade_nom représente-t-il un nom de balade ou un nom de département ?

J’ai d’autres remarques à faire, mais je suis obligé d’en rester là pour le moment, à plus tard donc.

[heretik25]

Bonjour,

1) J'ai passé les attributs en obligatoire en ajoutant "O" à ceux-ci.

2) Effectivement, on parle bien d'entité, excusez moi pour cet abus de langage.

3) Quinze coups de fouet ce soir pour avoir oublié le passage sur l'héritage uniquement des attributs primaires

4) Concernant l'entité-type DEPARTEMENT_BALADE et son attribut "dept_balade_nom", il s'agit bien du nom du département.

5) J'attends vos nouvelles remarques avec impatience


En pièce jointe le MCD avec les corrections apportées.

[fsmrel]

Bonsoir,


Avant tout, mettons-nous d’accord sur le principe de la généralisation/spécialisation. Considérez par exemple le cas d’une SSII ayant des clients et des salariés. Le cœur du modèle concerne essentiellement ces deux types de personnes. Si l’on entame la modélisation, on aura peut-être une ébauche de diagramme du genre :

Diagramme dans lequel l’attribut (propriété au sens Merise) ClientId est artificiel, par opposition aux attributs (propriétés) naturels ClientSiret (numéro Siret du client) et ClientRaisonSociale (raison sociale du client). L’attribut ClientId n’est là que pour servir d’identifiant au sens Merise du terme. Ceci vaut pour l’attribut SalarieId, mutatis mutandis.
En passant, je rappelle s’il en est besoin ce qu’a écrit l’un des plus grands de la modélisation, Yves Tabourier (De l’autre côté de MERISE page 81), et ça c’est une règle d’or, qui a plus de vingt ans :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques... »

A noter que deux entreprises ne pouvant pas avoir le même Siret, l’attribut ClientSiret fait donc l’objet d’un identifiant dit alternatif, signalé par le mickey <ai> dans le diagramme (voir ici ou là, c’est du Power AMC V11, mais avec la V15 ça ne doit pas être très différent). Même principe concernant le matricule des salariés et leur numéro de sécurité sociale (NIR).


Ensuite, on va dire que les clients et les salariés ont un téléphone :



Ou bien, s’ils peuvent avoir plusieurs téléphones :


A toutes fins utiles, je rappelle que le fait de placer les cardinalités 1,1 entre parenthèses (convention Power AMC) entraîne que l’identifiant de l’entité-type CLIENT_TELEPHONE est relatif à celui de CLIENT, c'est-à-dire qu’implicitement l’identifiant de CLIENT_TELEPHONE n’est pas ClientTelephoneId mais le couple {ClientId, ClientTelephoneId} (qui composera donc la clé primaire de la table CLIENT_TELEPHONE au niveau logique). Disons qu’entre CLIENT et CLIENT_TELEPHONE on a une relation de composition, ou encore que CLIENT_TELEPHONE est une propriété multivaluée de CLIENT.


A la longue, on se convainc qu’il serait intéressant de factoriser les attributs et les relations qui caractérisent aussi bien les clients que les salariés. On utilise alors le procédé de la généralisation, en considérant que les entités-types CLIENT et SALARIE sont des cas particuliers, des sous-types d’une entité-type plus générale (surtype), appelons-la PERSONNE :


CLIENT et SALARIE sont des sous-types de PERSONNE, des entités-types spécialisées. CLIENT hérite de l’identifiant {PersonneId} de PERSONNE, donc l’attribut artificiel ClientId n’a plus d’emploi et au nom du rasoir d’Ockham, il doit disparaître, même chose concernant l’attribut SalarieId.

Si l’on se place au niveau SQL, les entités-types PERSONNE et CLIENT donneront lieu aux tables PERSONNE et CLIENT, etc. :



Revenons à votre modélisation. Vu l’utilisation de l’héritage, on considère que l’entité-type FICHIER_GPS est un sous-type de l’entité-type ARTICLE :


Comme je l’ai écrit précédemment, il y a détournement d’héritage, mais c’est pour la bonne cause et l’on dira que sémantiquement parlant, le couple {ARTICLE, FICHIER_GPS} représente le cas de l’article à fichier GPS et dont la réunion des attributs est la suivante :

{id_article, article_titre, article_description, article_timestamp, validation_article, article_url_photo, id_fichier_gps, fichier_gps_lat, fichier_gps_lon, fichier_gps_altitude, fichier_gps_url_image, fichier_gps_date}.

Well, mais il y a quand même une anomalie : De même que l’entité-type CLIENT hérite de l’identifiant {PersonneId} de PERSONNE — en vertu de quoi l’attribut artificiel ClientId n’a plus d’emploi et disparaît au nom du rasoir d’Ockham — de même l’entité-type FICHIER_GPS hérite de l'identifiant {id_article} et doit donc être débarrassée de l’attribut id_fichier_gps (à défaut on pourrait dire qu’on est en présence d’une entité-type hybride, à la fois sous-type et propriété multivaluée, ce qui est un non-sens) :



Concernant les balades.

Là aussi, l'attribut id_dept_balade doit disparaître au nom du rasoir d’Ockham. En plus, le numéro et le nom du département ne sont pas des propriétés de DEPARTEMENT_BALADE et doivent être celles d’une entité-type DEPARTEMENT :

(A titre de curiosité, à quoi correspondent dept_balade_prefixe et dept_balade_geom ?)


Entité-type SECTEUR_PERIPLE : Là encore, l'attribut id_secteur_periple doit disparaître.


Cas du livre d’or : selon votre diagramme, un utilisateur peut être en relation avec plusieurs livres d’or, tandis qu’un livre d’or n’est en relation qu’avec un seul utilisateur. Qu’en est-il exactement ?

Cas des mots-clés : un article peut ne pas comporter de mots-clés, tandis qu’un mot-clé fait référence à au moins un article : j’aurais pour ma part tendance à permuter les cardinalités...

[heretik25]

Bonjour et merci encore pour ce magnifique tutoriel que vous appliquez à mon cas.


J'ai enlevé les identifiants comme vous me l'avez conseillé aux entités, balade_departement, secteur_periple et fichier GPS mais cela cause des soucis majeurs dans la génération du MPD. Cause de l'erreur : "Vérifier l'existence d'attribut d'entité". J'ai aussi des avertissement sur d'autres entités.

1) Concernant votre question sur l'entité "departement_balade", l'attribut dept_balade_prefixe correspond au préfixe d'un département comme "les" pour Vosges et dept_balade_geom contient la géométrie du département. Par géométrie, j'entends la géométrie pour la balise MAP HTML.

Ensuite, l'utilisateur peut se rendre sur les balades en passant par une carte : http://partir-en-vtt.com/php/balades...?type_balade=1

Je me demande donc s'il y a besoin d'ajouter l'entité "département" ?


2) Pour le livre d'or, c'est le fait qu'un utilisateur puisse commenter 0 ou plusieurs fois celui-ci. La cardinalité 1,1 devrait passer en 0,n. Un utilisateur peut commenter 0 ou n fois le livre d'or et le livre d'or peut être commenté 0 ou n fois par un utilisateur.

3) Pour les mots clés, au départ dans ce que je pensais faire c'est d'alimenter la balise META keyword, mais aussi et surtout créer un nuage de tag pouvant faire rediriger le lecteur sur un article contenant le mot clé. La grosseur du mot clé dans le nuage de tag sera proportionnel à la fréquence du mot clé.

Comment verriez vous la chose ?

En pièce jointe, le MCD V2.3.

Merci !

[fsmrel]

Bonsoir,


Je vous ai complètement oublié !

Avant de voir votre MCD de plus près, je pare au plus pressé...

J’ai demandé à Power AMC V11 de vérifier votre MCD. Il y a effectivement 3 erreurs, mais c’est la faute à l’outil qui oublie que les identifiants des sous-types DEPARTEMENT_BALADE, SECTEUR_PERIPLE et FICHIER_GPS sont hérités de celui du surtype ARTICLE...



Pour rattraper les étourderies de l’outil, il suffit de lui demander de ne pas effectuer la vérification.

Vous faites Outils > Vérifier le modèle (ou vous utilisez directement la touche F4) et vous décochez la case qui va bien :




Je reviens dès que possible.

[heretik25]

Bonsoir,

Ce n'est pas grave, j'imagine que vous avez fort à faire !

Je sais être patient lorsque cela en vaut la peine et, ici, en l’occurrence, ça en vaut vraiment la peine.

Merci pour l'astuce concernant le souci rencontré sur les identifiants.

[fsmrel]

Bonjour,

J'ai aussi des avertissements sur d'autres entités.

Concernant l’avertissement « Identifiant primaire redéfini », il faut supprimer l’attribut id_entretien de l’entité-type ENTRETIEN puisque celle-ci hérite de l’identifiant d’ARTICLE.

Concernant l’avertissement « Information non utilisée », vous pouvez vivre avec, mais vous pouvez aussi faire le ménage.


Concernant l’avertissement « Information non utilisée », vous ouvrez le dossier « Informations » :

Et vous supprimez les attributs non utilisés (Attribut_8, Attribut_19, etc.)

Concernant l’avertissement « Type de données non défini », il ne réapparaîtra pas dans la mesure où vous aurez supprimé les attributs concernés lors de l’étape précédente.

« Existence d’un lien de relation ou d’association » : Power AMC suggère que l’on a peut-être oublié de définir un 2e sous-type. Comme nous sommes conscients de ce que nous faisons, inutile qu'il continue de nous avertir :


« Parent de plusieurs héritages » : rien que de très normal que l’on définisse « plusieurs héritages », là encore vous pouvez décocher la case correspondante dans la fenêtre « Paramètres de vérification de modèle ».

Je reviens vers vous dès que je peux...

[fsmrel]

Concernant votre question sur l'entité "departement_balade", l'attribut dept_balade_prefixe correspond au préfixe d'un département comme "les" pour Vosges et dept_balade_geom contient la géométrie du département.

Autrement dit, ces données ne dépendent pas de l’article, mais seulement du département, auquel cas les attributs dept_balade_prefixe et dept_balade_geom doivent migrer vers l’entité-type DEPARTEMENT. Il va être temps que vous vous initiiez aux dépendances fonctionnelles, à la forme normale de Boyce-Codd et au théorème de Heath... (Dans votre cas, il y a déjà viol de la 2e forme normale).

Modéliser sans connaître les bases de la théorie de la normalisation c’est pratiquer le trapèze volant sans filet...

Je me demande donc s'il y a besoin d'ajouter l'entité "département" ?

Du point de vue de la modélisation et de la normalisation, la réponse est affirmative, car DEPARTEMENT est une conséquence de l’application du théorème de Heath.

Pour le livre d'or, c'est le fait qu'un utilisateur puisse commenter 0 ou plusieurs fois celui-ci.

Vous écrivez : « Le livre d’or », ce qui laisse supposer qu’il n’y en a qu’un, alors que selon votre modèle il peut y en avoir plusieurs. Qu’en est-il ?

Pour les mots clés, au départ dans ce que je pensais faire c'est d'alimenter la balise META keyword, mais aussi et surtout créer un nuage de tag pouvant faire rediriger le lecteur sur un article contenant le mot clé. La grosseur du mot clé dans le nuage de tag sera proportionnel à la fréquence du mot clé.

Comment verriez-vous la chose ?

Je ne connais pas HTML, donc je passe...

[heretik25]

Bonsoir,

J'aime sans doute apprendre en pratiquant avec un exemple concret, qui me motive. Je vais aller donc lire les articles que vous me recommandez.

Concernant les modifications pour enlever les messages d'avertissement, c'est ok.

Pour le livre d'or, il y a effectivement qu'un seul livre d'or. Ce que je voulais modéliser c'est le fait qu'un utilisateur puisse commenter 0 ou n fois le livre d'or et que le livre d'or puisse être commenté par 0 ou n utilisateurs.

Pour les mots clés, je pense que ça ira comme ça.

Encore une question, comment verriez vous la possibilité de créer un sondage sur un article ?

Encore merci !

Ci-joint le MCD 2.4 (on avance quasiment aussi vite que firefox en versionning )

[fsmrel]

Bonjour,


J’observe que vous avez oublié de supprimer l’attribut id_entretien (entité-type ENTRETIEN). Vous me copierez cent fois « Je suis un étourdi... »

Pour le livre d'or, il y a effectivement qu'un seul livre d'or. Ce que je voulais modéliser c'est le fait qu'un utilisateur puisse commenter 0 ou n fois le livre d'or et que le livre d'or puisse être commenté par 0 ou n utilisateurs.

Le livre d’or ne donne donc pas lieu à la mise en œuvre d’une entité-type, mais les commentaires sur le livre d’or, oui. Comme vous l’écrivez, un utilisateur peut commenter 0 ou n fois le livre d'or, et je rajoute seulement qu'un commentaire est fait par un et un seul utilisateur :


Mais on se rend compte désormais que les entités-types COMMENTAIRE et COMMENTAIRE_LIVRE_OR ont les mêmes propriétés (titre, contenu, etc.) et l’on peut donc procéder à une généralisation :

Je vous laisse méditer sur cette représentation, que vous êtes libre de mettre en oeuvre ou pas...

Encore une question, comment verriez vous la possibilité de créer un sondage sur un article ?

Je n’ai pas trop le temps de réfléchir à ça, mais proposez les règles de gestion qui vous viennent en tête.


J'attends votre MCD v2.5...

[heretik25]

Bonsoir,

Vous me copierez cent fois « Je suis un étourdi... »

Ok !

Code :

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

1
2
3
4
5
6
7
8
9
<?php 
$punition = 1;

While($punition <= 100)
{
echo 'Je suis un étourdi... ';
$punition++;
}
?>

Blague à part, voici le MCD V2.5.

Pour les sondages, voilà comment je verrai les choses :

Un sondage peut être ajouté à un ou n article
Un article peut avoir un et un seul sondage

L'utilisateur peut voter une et une seule fois par sondage
Un sondage peut avoir un ou n vote de un ou n utilisateurs

Encore merci pour votre aide

[fsmrel]

Bonsoir,


Ça commence à prendre une bonne tournure...

Un sondage peut être ajouté à un ou n article

Un sondage n'est-il pas propre à un article ? Qu'est-ce qui justifierait qu'il soit partagé par plusieurs articles ?

[heretik25]

Si ça commence à prendre une bonne tournure, c'est grâce à vous !

Un sondage n'est-il pas propre à un article ? Qu'est-ce qui justifierait qu'il soit partagé par plusieurs articles ?

Effectivement un sondage est propre à un article et un article possède 0 ou 1 sondage.
L'utilisateur peut voter une et une seule fois par sondage

[fsmrel]

Bonjour,


Sondons... Vous pourriez vous orienter vers quelque chose qui ressemble à ceci :

MCD



MLD


Moralité : n’oubliez pas de voter !

[heretik25]

Merci

Avec cette modélisation, l'utilisateur peut mettre une note à un article. Ceci répond en partie à ma question (voir totalement). Cependant pour compliquer un peu et pour comprendre comment vous le géreriez, serait-il possible de proposer plusieurs possibilité de réponse à la place de donner une note ?

Ex : Est-ce que vous aimez l'article ?

Possibilités :

• Oui
• Moyennement
• Pas du tout
• Ne se prononce pas

On pourrait imaginer qu'il y ait des possibilités de bases dès le départ mais que le créateur du sondage puisse ajouter/supprimer/modifier les possibilités.


La solution hybride qui serait au top serait d'être capable de créer soit un sondage "note" ou un sondage "avancé" à base de possibilités.


-------------------------------

J'en profite également pour relancer une question sur l'entité "secteur_periple" qui doit être pour moi modéliser tout comme les départements des balades. En effet pour faire simple le secteur d'un périple peut être considéré comme le département d'une balade.

Du coup, je pensais appliquer la même méthode que pour les départements (capture en PJ).


@bientôt pour de nouvelles aventures