Discussion :

[heize568]

Bonjour à tous, Je suis actuellement en train de concevoir la base de données pour un projet de site web/blog, et j'aimerais avoir vos avis sur mon Modèle Conceptuel de Données (MCD)

[escartefigue]

Bonjour et bienvenue dans le forum modélisation

Le MCD est une présentation schématique de règles de gestion selon un formalisme particulier.
Or vous n'avez formulé aucune des règles de gestion.

Voir dans ce fil de discussion, réponse n°8, comment formaliser les règles de gestion.

De plus, le formalisme de votre schéma est inhabituel, quel est votre outil de modélisation ?

Si vous n'avez pas de logiciel adapté, je vous recommande l'excellent Looping que vous pouvez télécharger gratuitement ICI.

Avec un logiciel tel que Looping, vous n'auriez pas commis l'erreur de positionner des clefs étrangères dans les types d'entité. En effet, au stade conceptuel, la notion de clef n'existe pas encore, donc évidement pas de clefs étrangères à ce stade.
C'est dans le modèle tabulaire (MLD et MPD) que les identifiants deviennent clefs et éventuellement clefs étrangères.

[heize568]

J'ai utilisé un outil en ligne pour l'UML https://lucid.app. En classe, nous l'écrivons sur papier, donc merci pour la recommandation. J'essaierai d'utiliser looping et merci d'avoir signalé l'erreur de clé étrangère. Je vais corriger le diagramme et le republier en utilisant un logiciel propre. Mais pensez-vous que c'est logique jusqu'à présent ? C'est la première fois que je crée une base de données à partir de zéro.

[fsmrel]

Bonjour,

Comme dit escartefigue, on ne peut que douter de la pertinence de votre diagramme, lequel n’est manifestement pas un MCD.

Dans un MCD, un carré symbolise un type d’entité et non pas plusieurs, d’où la nécessité d’utiliser des noms au singulier : COMMENTAIRE est un nom pertinent, COMMENTS ne l’est pas (et tant qu’à faire évitez le sabir résultant du mélange du français et de l’anglais).

Avez-vous compris la signification des cardinalités ? Par exemple, il apparaît que le même commentaire peut avoir été effectué par plusieurs utilisateurs et qu’un commentaire peut exister sans que personne ne soit concerné (cardinalité minimale 0).

Etc.

N.B. Looping permet aussi de faire des diagrammes UML.

[escartefigue]

Avez-vous compris la signification des cardinalités ? Par exemple, il apparaît que le même commentaire peut avoir été effectué par plusieurs utilisateurs et qu’un commentaire peut exister sans que personne ne soit concerné (cardinalité minimale 0).

À ce propos il faut noter que selon la symbolique UML, les cardinalités sont inversées par rapport à celles en usage sous Merise.
Attention à bien appliquer les cardinalités Merisiennes, par exemple, avec le modèle E/A suivant :

[ENTITE1] 0,n --- (asso 1) --- 1,1 [ENTITE 2]

Une occurrence d'Entité1 peut avoir zéro à plusieurs associations (asso 1) avec des occurrences d'Entité2, alors que chaque occurrence d'Entité2 a obligatoirement une association asso 1) avec une seule occurrence d'Entité1

[heize568]

est-ce mieux ?
j'ai utilisé l'anglais car ma base de données sera en anglais éventuellement

[escartefigue]

Bonjour,

Grâce à Looping, le formalisme est beaucoup mieux

Autres points concernant la forme :

• l'utilisation de l'anglais est judicieuse dans un contexte international, mais en ce cas, il faut aller jusqu'au bout de la démarche ;
  Par exemple, les verbes des associations doivent aussi être en anglais, ainsi que certains attributs tels que "libellé" (wording en anglais)
• les types d'entités se nomment au singulier : "role" (sans accent en anglais) plutôt que "rôles", "comment" plutôt que "comments" ;
• préfixer les noms des attributs par le nom du type d'entité est judicieux, ça garantit l'unicité et évite de percuter avec des noms réservés SQL lors de la dérivation du MCD (si toutefois on conserve les noms logiques comme noms physiques).
  Mais il est préférable de le faire pour tous les attributs. Par exemple first_name et last_name ne sont pas préfixés.
  Pour ma part, j'associe un préfixe court (de deux ou trois caractères) à chaque type d'entité et chaque association (par exemple USRpour l'entité-type USER) et j'utilise ce préfixe pour nommer les entités, les associations et leurs attributs
  Exemple USR_USER(USR_ident, USR_first_name, USR_last_name....)
  Cette méthode garantit l'unicité, évite la percussion avec des mots réservés SQL, mais aussi, elle facilite les études d'impact ;
• certaines associations ont un verbe à l'infinitif pour nom, d'autres un verbe conjugué (publie) ou un substantif (poste). L'usage est le verbe à l'infinitif, comme vous optez pour l'anglais, harmonisez donc toutes les assos pour utiliser un infinitif en anglais (avec préfixe si vous utilisez ma méthode de nommage).

Sur le fond, il manque toujours les règles de gestion, je vous ai fourni un lien vers un fil de discussion pour vous guider sur la façon de les formuler.

[heize568]

J'ai apporté les modifications ultérieures au diagramme.
J'ai consulté la discussion que vous avez mentionnée précédemment et je n'ai pas pu identifier ce qui ne va pas avec le diagramme.
Par exemple, 1-1 utilisateur publie 0-n articles,
0-n utilisateurs commentent 0-n commentaires
Peux-tu expliquer davantage ce que tu considères comme incorrect concernant les règles de gestion ?

[al1_24]

Peux-tu expliquer davantage ce que tu considères comme incorrect concernant les règles de gestion ?

Pour le moment on ne peut pas dire qu'elles sont incorrectes ; elles brillent par leur absence.

[escartefigue]

Comme déjà expliqué, il faut, dans l'ordre :

1 - rédiger les règles de gestion. Inspirez-vous du fil de discussion déjà communiqué pour voir quel formalisme utiliser
2 - établir le Modèle Conceptuel des Données (MCD) en utilisant un logiciel Adhoc tel que Looping
3 - quand le MCD est validé, choisir le SGBD et générer le script de création des objets bases de données

Vous publiez votre MCD (étape 2), alors que vous ne publiez pas vos règles de gestion (étape 1), on ne peut donc rien valider...

[heize568]

Est-ce cela que vous entendez par règles de gestion ?
Règles de gestion pour un site de blog

**1. ** Identificateurs

Tous les identifiants (utilisateurs, articles, commentaires, etc.) doivent être uniques.
Les identifiants doivent être alphanumériques, avec une longueur 10 (caractères).
**2. ** Mots de passe

Les mots de passe doivent comporter au moins 8 caractères, dont au moins une lettre majuscule, une lettre minuscule, un chiffre et un caractère spécial.
**3. ** Utilisateurs

Tout utilisateur doit avoir un nom, un prénom, une adresse électronique et un mot de passe.
Un utilisateur peut être un auteur, un éditeur ou un simple lecteur.
**4. ** Articles

Un article doit avoir un titre, une date de publication et une catégorie.

**5. ** Commentaires

Un commentaire doit avoir un auteur, une date de publication exacte.

**6. ** Permissions

Les auteurs peuvent créer, modifier et supprimer leurs propres articles.
Les éditeurs peuvent créer, modifier et supprimer tous les articles, y compris ceux des autres auteurs.
Les lecteurs peuvent uniquement lire les articles et commenter.

**7. ** tags

Un article peut avoir un maximum de 30 tags.
Un tag peut être utilisé pour plusieurs articles.
avec une longueur min 2, max de 10 (caractères)
Un auteur peut utiliser des tags pour classer ses articles par sujet. Par exemple, un auteur qui écrit des articles sur la programmation Python pourrait utiliser les tags suivants : python, apprendre-le-python, développement-web, etc.
Un lecteur peut utiliser des tags pour trouver des articles sur un sujet qui l'intéresse. Par exemple, un lecteur qui s'intéresse à la programmation Python pourrait rechercher les tags python ou apprendre-le-python.
tag invalide: #python (le tag commence par un hashtag)

[escartefigue]

Bonjour,

Les règles de gestion sont les règles métier qui permettent d'expliquer les interactions entre les objets de gestion, pour rappel, il est recommandé de donner un identifiant à chaque règle, c'est bien plus pratique pour la validation et le suivi :

Par exemple :
Clients et commandes
R001A : un client est une personne qui a passé au moins une commande
R001B : une commande est passée par un et un seul client
Commandes et lignes de commande
R002A : une commande contient au moins une ligne de commande
R002B : une ligne de commande est contenue dans une et une seule commande
Lignes de commande et articles
R003A : une ligne de commande concerne un et un seul article
etc.
Ce sont les règles de gestion qui justifient les cardinalités du MCD et aussi certaines contraintes.

**1. ** Identificateurs
Tous les identifiants (utilisateurs, articles, commentaires, etc.) doivent être uniques.
Les identifiants doivent être alphanumériques, avec une longueur 10 (caractères).

L'unicité d'un identifiant n'a pas besoin d'être rappelée dans les règles de gestion, car c'est implicite :
Tout identifiant est par définition unique, non "nullable" et irréductible.
De plus, il est très fortement recommandé qu'il soit concis et stable. À ce titre, le choix d'un type caractère est peu judicieux car rarement stable, peu concis et sensible à la collation.
On recommande le plus souvent d'utiliser un type integer pour tous les identifiants, c'est ce qu'il y a de plus concis et c'est asémantique, donc stable. Les types integer attribués par le SGBD sont judicieux : l'unicité est garantie par le SGBD sans avoir besoin de s'en préoccuper. Selon le choix du SGBD, on parlera d'IDENTITY (SQL server, DB2), d'AUTO_INCREMENT (MySQL, MariaDB), de SERIAL (Postgre), etc.

**2. ** Mots de passe
Les mots de passe doivent comporter au moins 8 caractères, dont au moins une lettre majuscule, une lettre minuscule, un chiffre et un caractère spécial.

Cette règle doit être mentionnée dans le dictionnaire de données, mais n'est pas requise pour établir le MCD (à part la longueur qui est requise).

**3. ** Utilisateurs
Tout utilisateur doit avoir un nom, un prénom, une adresse électronique et un mot de passe.
Un utilisateur peut être un auteur, un éditeur ou un simple lecteur.

Le fait qu'il existe plusieurs types d'utilisateurs est important si certains types possèdent des attributs spécifiques ou que certains types participent spécifiquement à certaines associations.
Ce que confirme votre point n°6 sur les permissions et que je reprends ci-dessous en ajoutant des identifiants de règles comme suggéré à plusieurs reprises :

**6. ** Permissions
R010 : les auteurs peuvent créer, modifier et supprimer leurs propres articles.
R011 : les éditeurs peuvent créer, modifier et supprimer tous les articles, y compris ceux des autres auteurs.
R012 : les lecteurs peuvent uniquement lire les articles et commenter.

Ces règles que j'ai numérotées R010 à R012 devront être matérialisées dans le MCD sous forme de contraintes

[heize568]

Thanks for the so-called recommendation. My computer got infected, and most of my work got wiped out. Are you here just to scam people into downloading infected files?

[Paprick]

Looping est exécuté plus de 2000 fois par jour (plus de 50 000 fois par mois) par de multiples utilisateurs... aucun virus n'a jamais été signalé...

[escartefigue]

J'utilise régulièrement Looping depuis ses premières versions, à la fois à titre privé et professionnel, et je confirme n'avoir jamais eu le moindre problème d'infection virale, quelle que soit la version utilisée.

[chrtophe]

ça doit être un faux positif. Le logiciel provient de l'université de Toulouse, connue également pour gérer une blacklist utilisée avec Squid