Gestion d'articles et de documents

Version imprimable

28/08/2013, 18h34
Spawnrad

Gestion d'articles et de documents

Bonjour, Je débute dans la réalisation d'un MCD, je me suis donc aidé des documentations. J'ai une problématique au niveau du choix à prendre pour concevoir le MCD et j'aimerai vos conseils. Je me suis aidé d'un post de conception par héritage que je pense allait très bien pour mon modèle.

Voici tout d'abord un début des règles du projet :

L'utilisateur sera soit inscrit ou invité.

Les différents types d'utilisateurs inscrit :
- Les membres
- L'admin
- Les rédacteurs

Un document peut être :
-Une image
-Un message
-Un article

L' utilisateur inscrits peut poster un document de type Images ou Message.
L'utilisateur ne peut pas poster d'article.

L'utilisateur inscrits peut aimer/commenter un document.
Un document peut etre aimer/commenter par plusieurs utilisateurs.

L'utilisateur inscrits peut sauvegarder un article.
Un article peut être sauvegardé par plusieurs utilisateurs.

Un rédacteur possède un article.
Un article est associé à un seul rédacteur.

Un rédacteur peut éditer son article.

Un admin peut modérer un document.

Un article est attaché à une seule catégorie.
Une catégorie possède plusieurs sous-catégories.

Problématique :

Je me demande si le mieux n'est pas de séparer l'entité Articles de l'héritage de l'entité documents. L'entité Articles est dans l'héritage de l'entité Documents juste pour les simplifier les actions Aimer/Commenter. Cette séparation rendra peut être le modèle un peut plus complexe ?

Je vous remercie d'avance pour vos réponses.

Voici Le graphique :

http://img14.imageshack.us/img14/4097/r7r6.png
28/08/2013, 21h47
Spawnrad

J'ai effectué quelques modifications :

Ajouts :

- Un utilisateur inscrit peut s'abonner à un autre utilisateur inscrit.
- Un utilisateur inscrit peut envoyer des messages à un autre utilisateur inscrit.
- Un Rédacteurs possède 2 types de fonction ( Expert / Débutant / ou les 2 :calim2: )

Modifications :

- J'ai ajouté l'entité "sauvegarde_article" contenant la liste des articles sauvegardé par un utilisateur ( Un utilisateur inscrits peut sauvegarder un article )

- J'ai enlevé des associations avec l'entité non-invité ( je pense que ce n'est pas nécessaires, est ce que je me trompe? )

Voici le nouveau graphique :

http://img198.imageshack.us/img198/8237/fd5.png
21/09/2013, 15h08
Oppenheimer
Bonjour Spawnrad,

Je vous invite à prendre exemple sur un sujet similaire, qui a été bien défini en titre, quoique mal posé en message (en effet, si une règle d'or y est opposée aux règles imposées, alors la règle d'or comme remède miracle n'existe pas) :
http://www.developpez.net/forums/d79...evoir-bon-mcd/

Je vais - non pas résoudre votre MCD jusqu'au MPD - mais vous répondre de manière générale (en principe, on va du général au particulier).

Citation:

Envoyé par Spawnrad

Un document peut être :
-Une image
-Un message
-Un article

-en ce cas, il faut vous interroger sur: "Qu'est-ce qu'un document ?"
sans exemple, je dirais:
- un auteur,
- un message,
- une date (d'édition),
- un lieu (d'édition).
et là, ça devient très fun, parce que votre document pourrait être:
un contrat (à condition de permettre au moins trois auteurs (deux contractants et un notaire)),
ou un message,
ou un article.

Et si vous incluez un champs [image] à votre document, alors une image se résumera à un document sans message !

En fait, vous avez cerné la pierre d'achoppement dès la pose de votre problème, et pourtant vous l'avez oubliée, puisque vous aviez dit dans un premier temps qu'un document pouvait être un article, et qu'ensuite vous avez séparé l'article dans votre modèle.

Qu'on soit clair: vous voulez bien parler de relations, et non du modèle par héritage (soit: "arbre") en vogues au début des années '80s ?

-Et puis je n'ai pas vu d'entité "Personne" (en général, un document est bien écrit par une personne (au moins)), qui pourrait être quant à elle, tant un individu, qu'une entreprise (soit: une personne morale), puisqu'une entreprise peut très bien éditer, par exemple, un règlement interne !

Enfin, sur la méthode, je sais que je ne vais pas faire plaisir à Fsmrel, mais je ne vois pas de dichotomie entre Normalisation et MERISE (à quoi appartient en principe le MCD).

Donc:
- établir vos tables par objets les plus généraux possible (dans une mesure du bon sens: une table "Matière" pour parler d'un document papier n'aurait aucun sens),
- Normaliser au stade souhaité - en gardant à l'esprit que: Plus c'est normalisé, plus on évite les problèmes d'ingérence par la suite;
- Une fois vos entités d'objets obtenues, vous pouvez vous occuper des liens entre tables (et non entre attributs eux-mêmes) qui sont l'objet du MCD.
- Et si ça peut vous aider pour la suite (comme je vois que vous avez déjà un premier jet de schémas) : pour le MLD il faudra s'arranger de transformer les liens "plusieurs-à-plusieurs" en lien maximum "un-à-plusieurs" par l'insertion d'une table intermédiaire idoine; et
- préciser les attributs liés spécifiquement (jointures).
Voilà, j'espère que cette méthode et son introduction vous aideront.
22/09/2013, 11h54
Oppenheimer

En fait, ce qui m'étonne dans l'histoire, c'est que vous parlez déjà d'héritage, alors que vous titrez votre sujet par "choix de la modélisation".

À savoir qu'un tel choix intervient en principe (par définition) avant tout modèle.
22/09/2013, 22h15
Oppenheimer

Je me permets d'insister sur la notion d'entité généralisées aux diverses définitions du dictionnaire.

Spawnrad,

En fait, le problème dans votre inspiration depuis une méthode "héritée", à mon sens, c'est que vous pouvez sans souci doubler la liste d'exemples de vos documents, qu'elle ne sera jamais exhaustive comme prévention de ce qui peut arriver.

C'est pourquoi je me permets d'insister sur le caractère "généralisé" des entités.

Dans le cas du document, et je ne me moque aucunement: Prenez la définition du dictionnaire... et appliquez là! Sans aucune considération pour des exemples particuliers qui deviendront bientôt insuffisants.

Mais on peut se demander pourquoi "Matière" ne serait pas une entité pertinente pour parler d'un document matériel. Parce que son type de support n'influe nullement sur son message (quoique certains ont une certaine affinité pour le papier... dont moi! Mais en termes d'information formelle, cela n'intervient pas).

Citation:

Envoyé par Oppenheimer

-Et puis je n'ai pas vu d'entité "Personne" (en général, un document est bien écrit par une personne (au moins)), qui pourrait être quant à elle, tant un individu, qu'une entreprise (soit: une personne morale), puisqu'une entreprise peut très bien éditer, par exemple, un règlement interne !

Et j'ai eu pour ma part eu l'occasion de constater qu'en entreprise, ce genre de considération a tendance à être oublié. M'occupant une fois de conception - c'est à dire au stade conceptuel - de base de données, je constatai à regret que mon responsable n'entendit rien.

Ca veut dire que même dans le monde professionnel, on a tendance à se mettre un mur.

Mais c'est important d'avoir des entités larges, très important!

On peut encore être amené à accepter de nouveaux types d'objets, voire à interagir avec de nouvelles bases de données, il faut tout prévoir !

Dans le cas de la personne, je ne vois pour ma part que deux définitions essentielles, l'une ramenant à l'individu, l'autre à une entreprise. Mais peut-être qu'il y en a d'autres, allez savoir.

N.B.:
Ces considérations ont peut-être l'air naïves ou perfectionnistes, mais il s'agit non seulement de la survie de votre projet, mais plus encore de l'évolutivité de votre modèle pour des projets ultérieurs !
23/09/2013, 03h59
fsmrel

Bonsoir,

Spawnrad, il faudrait que vous fassiez figurer les attributs (propriétés au sens merisien) des entités-types de votre MCD. Qui plus est, ces attributs doivent figurer là où ils sont strictement pertinents, c'est-à-dire obligatoires. Par exemple, si l’adresse de courriel ne vaut que pour les seuls utilisateurs inscrits, alors l’attribut AdrCourriel correspondant n’est pas pertinent pour les invités et doit figurer non pas dans l’entité-type UTILISATEUR (parce que les invités en hériteraient à tort), mais dans l’entité-type UTILISATEUR_INSCRIT figurant ci-dessous.

Quels attributs communs d’une part, spécifiques d’autre part caractérisent les utilisateurs inscrits et invités ?

Reprenons votre diagramme en zoomant sur les utilisateurs. Ci-dessous je fais figurer par des points de suspension les attributs manquants (à cette occasion je précise que l’identifiant est artificiel, c'est-à-dire invariant et dépourvu de signification). A vous de remplacer par les attributs pertinents.

http://www.fsmwarden.com/developpez_...ateurs_MCD.png

A noter que dans ce diagramme les pointes de flèches vont du sous-type (par exemple UTILISATEUR_INSCRIT) vers le surtype (UTILISATEUR) : votre MCD est à corriger en ce sens.

Selon ce diagramme, je dirais qu’un rédacteur est à même de rédiger des articles et aucune autre catégorie de personnes n'a le droit de le faire, notamment les administrateurs. Est-ce bien ce que vous voulez ?

Citation:

Envoyé par Spawnrad

Un utilisateur inscrit peut s'abonner à un autre utilisateur inscrit.

Qu’entendez-vous par s’abonner à un autre utilisateur ? abonnement à un article ? un message ? Une discussion ? (sujet non encore évoqué...)

Citation:

Envoyé par Spawnrad

Un utilisateur inscrit peut envoyer des messages à un autre utilisateur inscrit.

Prenez l’habitude d’énoncer les règles de gestion correspondantes. Par exemple, par référence à la messagerie privée de Developpez.com :

R150 - Un utilisateur inscrit peut envoyer plusieurs messages ;
R151 - Un message est émis par au moins un et au plus un utilisateur inscrit ;
R152 - Un message est destiné à au moins et au plus plusieurs utilisateurs inscrits ;
R153 - Un utilisateur inscrit peut être destinataire de (recevoir) plusieurs messages.
http://www.fsmwarden.com/developpez_...agerie_MCD.png

Ce diagramme serait à aménager si par exemple la règle R152 devenait :

R152 - Un message est destiné à au moins et au plus un autre utilisateur inscrit.
Par la suite (pour le moment il n’y a pas le feu), il faudra penser à représenter la contrainte correspondant à la règle de gestion s’il y a lieu (elle ne vaut pas pour Developpez.com) :

R154 - l’émetteur d’un message ne peut pas en être destinataire.

Citation:

Envoyé par Spawnrad

Un Rédacteurs possède 2 types de fonction ( Expert / Débutant / ou les 2).

Sur la base de quels critères ? En relation avec quoi ?

Citation:

Envoyé par Spawnrad

J'ai ajouté l'entité "sauvegarde_article" contenant la liste des articles sauvegardé par un utilisateur (Un utilisateur inscrits peut sauvegarder un article )

Si tout utilisateur inscrit peut sauvegarder un article, au vu de votre diagramme il y a un problème, car on ne sait pas qui a sauvegardé. Voici ce que dit votre représentation à propos des sauvegardes :

Un article peut faire l’objet de plusieurs sauvegardes et une sauvegarde peut concerner plusieurs articles.
Si donc tout utilisateur inscrit peut sauvegarder un article donné, le diagramme correspondant serait plutôt le suivant :

http://www.fsmwarden.com/developpez_...garder_MCD.png

Citation:

Envoyé par Spawnrad

J'ai enlevé des associations avec l'entité non-invité ( je pense que ce n'est pas nécessaires, est ce que je me trompe?

Tout dépend des règles de gestion que vous souhaitez mettre en œuvre. Il est temps que vous les fournissiez de façon exhaustive (à l’image de celles que j’ai fournies ci-dessus : R150, etc.), car votre diagramme actuel risque fort de ne pas leur correspondre (voyez par exemple les sauvegardes d’articles et l’émission des messages).

Citation:

Envoyé par Spawnrad

Un article est attaché à une seule catégorie.
Une catégorie possède plusieurs sous-catégories.

Qu’en est-il des relations entre les articles et les sous-catégories ? L’association « relation_3 » mérite d’être expliquée de façon précise.

Citation:

Envoyé par Spawnrad

L'utilisateur inscrits peut aimer/commenter un document.

Commenter un message, un article, d’accord, mais qu’en est-il si le document est une image ?

Citation:

Envoyé par Spawnrad

Un admin peut modérer un document.

Que cela vaille pour les messages, d’accord, mais qu’en est-il des articles ? des images ?

Conclusion : il faudra que nous disposions de règles complètes et plus précises et que vous répondiez aux questions ci-dessus. A défaut, on ne sait pas si la spécialisation des utilisateurs est acceptable en l’état. En ce qui concerne l’entité-type DOCUMENT, la spécialisation risque d’en prendre un coup (commenter, modérer des images, c'est bizarre...) En revanche, si on arrive à ce qu’un document soit ou bien un article ou bien un message, alors on pourra établir une association entre DOCUMENT et IMAGE. Par exemple, à supposer qu’une image appartienne à un seul document (à vous de préciser la règle) :

http://www.fsmwarden.com/developpez_...uments_MCD.png

N’hésitez pas à utiliser la touche « F4 » pour prendre connaissance des erreurs signalées par l’AGL.

A suivre (surtout pas de panique !)
23/09/2013, 08h46
Oppenheimer

Je ne vois toujours pas pourquoi on distingue un document d'un article.

Bonjour Fsmrel !

J'espère que vous ne m'en avez pas voulu pour mes questions sur la normalisation.

Je ne me serait pas permis de discuter à cette heure, d'implémentation d'un projet, à savoir que je n'ai accompli que relativement peu de bases jusqu'au MPD jusqu'à aujourd'hui.

Puis-je me permettre une question également ? Les symboles arrondis sont bien des "OU", et ceux-ci comportant une crois des "OU exclusifs" à l'instar des circuits logiques ?

Si c'est le cas, alors je n'y suis pas, ou pas encore.

Toutes mes excuses à Spawnrad, j'avais lu comme titre "Problématique: Choix de la modélisation", mais je crois que ça a été correctement renommé par la modération.
------
N.B.:
La distinction entre un document et une "variante de document comme un article" a quoi comme vertu exactement, (je ne vois pas cet aspect dans votre réponse Fsmrel, quoiqu'ayant lu le paragraphe sur le document), c'est d'éviter ce qu'on appelle vulgairement de potentielles "valeurs vides" ?