Discussion :

[sg.jiri]

Bonjour,

Je suis un développeur junior et je souhaiterais connaître votre avis sur la base de données que je viens de créer. Dans le cadre de ce projet, je voudrais simuler un site de petites annonces. La base de données que j'ai élaborée comprend une partie principale contenant la table des utilisateurs et la table des annonces, avec les différentes catégories d'annonces.

Par la suite, je prévois de développer deux modules optionnels : une messagerie et un système d'alertes, où les utilisateurs peuvent être prévenus dès qu'une annonce correspondant à leurs critères préalablement définis est publiée.

En réfléchissant sur ma base de données, je me suis rendu compte que pour réaliser un site semblable à Leboncoin, il est complexe d'avoir une seule table pour les produits, car les critères varient selon le type de produit. Par exemple, un véhicule n'aura pas les mêmes spécifications qu'un bien immobilier. J'ai donc décidé de créer une table dédiée aux véhicules et une autre pour les biens immobiliers. Est-ce une bonne méthode selon vous ?

Une autre question concerne les alertes qu'un utilisateur peut créer. Pour chaque alerte, j'envisage de créer une table à part, par exemple une alerte pour la catégorie des véhicules, car les critères pour cette catégorie diffèrent de ceux pour les biens immobiliers. Est-ce que cette approche vous semble correcte ?

Merci pour vos retours et conseils.

[fsmrel]

Bonsoir,

Avant de parler de tables, commencez par fournir les règles de gestion décrivant votre sujet.
Ceci fait, proposez le MCD impliquant ces règles (voyez l’exemple proposé par escartefigue). A cet effet, utilisez l’excellent outil de modélisation Looping car les diagrammes que vous proposez sont plutôt illisibles.

[escartefigue]

Bonjour,

En effet l'image noire sur fond noir n'est pas lisible

Vous pouvez télécharger l'excellent Looping ICI, il est gratuit, son ergonomie est parfaite et ses fonctionnalités très riches
Avec Looping, passer du modèle conceptuel au modèle tabulaire se fait en un seul clic, y a plus qu'à

[fsmrel]

Bonjour,

sg.iri, comparez le 1er MCD proposé par Worldask (ici) et son dernier MCD (avec Looping), il a suivi nos conseils, y a pas photo ! ça lui a valu les félicitations du jury…

Courage ! Fortuna juvat audaces !

[sg.jiri]

Merci pour toutes vos réponses malgré les erreurs de mon premier message sur ce forum. Je pense que la lisibilité s'est grandement améliorée maintenant. Cette description des tables et des relations m'a vraiment aidé et je me suis même rendu compte de quelques erreurs. C'est entièrement de ma faute, je serai moins paresseux la prochaine fois que je poserai une question.

Dans le cadre de ce projet, je souhaite simuler un site de petites annonces. La base de données que j'ai élaborée comprend une partie principale contenant la table des utilisateurs et la table des annonces, avec les différentes catégories d'annonces.

En réfléchissant à ma base de données, j'ai réalisé qu'il était complexe d'avoir une seule table pour les produits afin de réaliser un site similaire à Leboncoin, car les critères varient en fonction du type de produit. Par exemple, un véhicule n'aura pas les mêmes spécifications qu'un bien immobilier. J'ai donc décidé de créer une table dédiée aux véhicules et une autre pour les biens immobiliers. Est-ce une bonne méthode selon vous ?

Une autre question concerne les alertes qu'un utilisateur peut créer. Pour chaque alerte, j'envisage de créer une table distincte, par exemple une table d'alertes pour la catégorie des véhicules, car les critères diffèrent de ceux pour les biens immobiliers. Est-ce que cette approche vous semble correcte ?

R001 Utilisateur : un utilisateur est une personne qui a créé un compte sur le site ou qui est l'administrateur du site en fonction de son rôle. Il peut publier de 0 à l'infini d'annonces. Un utilisateur peut ajouter entre 0 et l'infini d'annonces à ses favoris.

R002 Ad : une annonce est créée par un seul utilisateur. Elle appartient obligatoirement à une catégorie. Une annonce peut être ajoutée à la liste des favoris de 0 à l'infini d'utilisateurs.

R003 Electronics : Electronics est une table qui contient les informations spécifiques à la catégorie "Électronique". L'objectif est de permettre la mise en place de filtres de recherche. La table Electronics peut être liée à 0 à l'infini d'annonces.

R004, R005 : Le même fonctionnement s'applique pour les catégories "Vehicle" et "Property" comme pour R003.

R005 Property : possibilité de choisir entre les options de vente ou de location d'un bien dans le champ "sale_or_rent".

R006 Message : un message peut être envoyé par un utilisateur. Il appartient à une conversation.

R007 Conversation : une conversation est une suite de messages échangés entre deux utilisateurs. Elle contient au minimum un message et est menée entre deux utilisateurs.

R007 Alerts_Electronics : table dédiée aux alertes créées par un utilisateur pour être prévenu dès qu'une annonce correspondant à ses critères apparaît. Une alerte est créée par un utilisateur à chaque fois. Une alerte peut signaler entre 0 et l'infini d'annonces dans la catégorie "Electronics".

R008 Alerts_Vehicle, R009 Alerts_Property : le même fonctionnement s'applique pour les alertes "Vehicle" et "Property" comme pour R007.

Une question concerne la relation qui lie une annonce à une alerte. J'ai établi cette relation entre R007 et R003 où se trouvent les spécifications d'une annonce. Je me demande si c'est un bon choix ou si je devrais plutôt établir la relation entre R007 et R002.

La deuxième question concerne la propriété id_category dans chaque table des catégories. Je me disais que pour les requêtes, cela pourrait être pratique si j'attribuais par exemple id_category 1 à toutes les annonces dans la catégorie véhicule. Je pense que cela pourrait faciliter les requêtes, mais je me pose la question si c'est une bonne pratique de créer un ID en dur de cette façon.

[sg.jiri]

Voici MLD

[Paprick]

Bonsoir,

Je suis un peu perturbé par votre MCD et le MLD qui va avec...
En effet, vous faites apparaître les clés étrangères dans le MCD (par exemple : "conversation_id" dans la classe d'entités "Message").
Vos associations n-aires "alert" et "catagory" posent aussi questions...

Par ailleurs, je ne comprends donc pas comment votre MLD est généré... Quel logiciel utilisez-vous ?

[fsmrel]

Bonjour,

Votre modèle n’a plus cette allure sépulcrale propre à faire fuir, mais il est largement à revoir.

Tout d’abord, il faut produire un MCD et donc utiliser le vocabulaire ad-hoc : à ce niveau on ne parle pas de tables mais de classes d’entités (ou types d’entités ou entités-types). Je vous renvoie au chapitre 7 de l’ouvrage de référence Ingénierie des systèmes d'information - Merise deuxième génération de D. Nanci (RIP).

Je vous engage à examiner la figure 7.56 qui traduit graphiquement la spécialisation des entités-types.

Par exemple, dans votre cas :

 
Je n’ai évidemment fait figurer que quelques propriétés (attributs) des entités-types (tout ça dans le respect de la langue française qui m’est plus familière).

[fsmrel]

A propos du rôle de l’utilisateur :

Pour des raisons de cohérence, d’homogénéité, il est nettement préférable de mettre en oeuvre une entité-type Rôle, et d’établir une association entre cette entité-type et l’entité-type Utilisateur. Au stade SQL les requêtes ne s’en porteront que mieux.
 
 

La deuxième question concerne la propriété id_category dans chaque table des catégories. Je me disais que pour les requêtes, cela pourrait être pratique si j'attribuais par exemple id_category 1 à toutes les annonces dans la catégorie véhicule. Je pense que cela pourrait faciliter les requêtes, mais je me pose la question si c'est une bonne pratique de créer un ID en dur de cette façon.

Dans le cas de la spécialisation des entités-types, la propriété id_category n’a aucune utilité et doit disparaître. Par contre, quand pour une base de données existante on souhaite procéder à la généralisation d’entités-types existantes, alors on conserve les identifiants existants pour ne pas mettre à mal les requêtes SQL en production.
 
Si votre base de données était déjà en production, le MCD deviendrait :
 

 
Je vous recommande une fois de plus d’utiliser Looping.

[sg.jiri]

Bonjour,

Par ailleurs, je ne comprends donc pas comment votre MLD est généré... Quel logiciel utilisez-vous ?

Merci pour le retour. J'utilise https://app.diagrams.net/ . Pendant ma formation, nous avons tous utilisé cet outil. J'applique la même méthode de conception pour les MCD et MLD que j'ai utilisée tout au long de l'année, y compris lors de ma soutenance. J'avoue être un peu perturbé d'entendre que mes conceptions ne correspondent pas aux règles de conception. Mais visiblement, vous n'êtes pas le seul à me faire cette remarque.

[fsmrel]

Bonjour,


sg.iri, j’ai jeté un coup d’oeil à draw.io. en fait, comme son nom l’indique, c’est un outil, un "couteau suisse", qui permet de représenter des diagrammes, mais ignore tout de ce qu’est un MCD, ça n’est pas un AGL. S’il savait de quoi il s’agit, alors il devrait être capable de générer automatiquement un MLD à partir du MCD, ainsi que le code SQL.

Je réitère, exercez-vous à reprendre votre projet avec Looping, tout en lisant les bons auteurs (Nanci, Bergougnoux, Tabourier, ...)








.

[sg.jiri]

Bonjour,

Votre modèle n’a plus cette allure sépulcrale propre à faire fuir, mais il est largement à revoir.

Merci pour toutes les suggestions. J'ai apporté plusieurs changements par rapport au MCD précédent.

Pour représenter la spécification des entités-types, j'ai intégré la contrainte de totalité. Ainsi, une alerte peut être soit un bien immobilier, soit une voiture, soit un appareil électronique. Si j'ai bien compris, il n'est pas nécessaire de marquer les cardinalités entre l'entité surtype et les entités sous-type. J'ai représenté la spécification entre R002 Ad et R003 Electronics, R004 Vehicle, R005 Property de la même manière.

J'ai enlevé les clés étrangères de mon MCD.

J'ai renommé toutes les relations. C'est plus pratique si les relations sont nommées par les initiales des entités-types qu'elles relient.

Toujour pas le looping, je le sais. J'ai juste apporté des modifications à l'ancien MCD, ce qui m'évite de le refaire complètement. De plus, une fois que je me serai familiarisé avec https://app.diagrams.net, cela pourrait être pratique pour représenter les MCD et MLD. C'est juste que pour mon premier poste, je ne savais pas bien l'utiliser. Je vient de me rendre copmte que je puex meme rendre le diagrame acesible en ligne: https://app.diagrams.net/#G1_hyycgB0...FZUtBfXX%22%7D

[Paprick]

Bonjour,

J'ai enlevé les clés étrangères de mon MCD.

Visiblement, pas toutes...
Tant que vous vous obstinerez à utiliser un outil de dessin au lieu d'un AGL (Looping ou autre), vous n'arriverez pas à gérer correcte la cohérence de votre système d'information.
Le MLD est-il généré automatiquement à partir du MCD avec draw.io ? Vu ce que vous nous avez transmis, je ne crois pas...
Le DDL permettant de créer le schéma relationnel pourra-t-il légalement être généré ? Je ne crois pas non plus...
Vous rentabiliserez très vite l'apprentissage d'un vrai AGL en bénéficiant de ces générations automatiques ! Avec un bon AGL, lorsque le MCD est finalisé, la base de données est prête à être mise en œuvre.
J'ignore pourquoi cet outil draw.io était utilisé pour votre formation, mais ce n'est pas très judicieux, surtout compte-tenu de l'existence de vrais logiciels (gratuit pour certains) spécialisés pour ce type de modélisation.
Bonne continuation !

[sg.jiri]

Bonjour,

Tant que vous vous obstinerez à utiliser un outil de dessin au lieu d'un AGL (Looping ou autre), vous n'arriverez pas à gérer correcte la cohérence de votre système d'information.
[/COLOR]

Merci pour votre retour. J'ignorais que draw.io était si mal perçu dans la communauté. Je prévoyais de commencer à utiliser Looping dans mon prochain projet et de terminer le projet actuel avec draw.io, mais je réalise maintenant que cela pourrait vraiment être avantageux pour moi de m'y mettre dès maintenant.

[al1_24]

J'ignorais que draw.io était si mal perçu dans la communauté.

Ce n'est pas qu'il est mal perçu, c'est qu'il est inadapté.
Tu peux planter un clou en tapant dessus avec le manche d'un tournevis, ça n'en fera jamais un marteau.

[sg.jiri]

Voici mon MCD réalisé en boucle. Je lirai avec plaisir vos commentaires.

[fsmrel]

Bonjour sg.jiri,

Bel effort, on y voit un peu plus clair !

Concernant les alertes : l’entité-type Alert a donc pour sous-types Alert_Electronic, Alert_Vehicle, Alert_Property :

Une alerte électronique est donc une alerte, une alerte véhicule et une alerte property sont ainsi elles aussi des alertes. Par définition, elles héritent de l’identifiant de l’entité-type Alert, les identifiants tels que id_alert_electronic, etc. sont une surcharge inutile et doivent disparaître.

Même chose concernant l’entité-type Ad (qui mériterait un nom plus parlant, pourquoi pas Annonce ?) et, pour éviter toute ambiguïté, les sous-types Electronic, Vehicle, Property devraient être renommés en Annonce_Electronic, etc.

Incidemment, dans le modèle Entité-Association, les noms des entités-types sont à mettre au singulier.

Encore bon courage et à bientôt.

[escartefigue]

Bonjour,

Bel effort en effet, c'est beaucoup plus lisible

Le plus souvent, on ne peut pas voter pour son propre message ou sa propre annonce, ce faisant, il faut mettre en oeuvre une contrainte d'exclusion entre les associations pour contrôler cette règle.
C'est ce que j'ai mis dans l'exemple de MCD ci-dessous, dans lequel j'ai réagencé les objets pour éviter les croisements de liens.



Il est recommandé d'externaliser les villes et les codes postaux des adresses, en effet, plusieurs adresses partagent la même ville et les codes postaux doivent être contrôlés pour qu'ils correspondent à la bonne ville. Vous trouverez ICI dans la réponse n°4 un exemple de modélisation des CP et villes

[sg.jiri]

Bonjour,

Merci pour toutes les réponses. J'ai réalisé un nouveau MCD en tenant compte de toutes les recommandations faites par fsmrel, à l'exception du renommage de l'entité-type "Ad". Cela me pose une question : j'ai conçu tout mon MCD en anglais, et je voulais être cohérent avec cette approche. C'est pourquoi j'ai choisi le nom "AD". La raison derrière ce choix est que, dans ma formation, on nous a toujours dit qu'il est préférable de favoriser l'utilisation de l'anglais en informatique. Quel est votre avis sur ce sujet ? Si j'utilise le nom "annonce" pour cette table, j'abandonne la logique de conception en anglais.

Merci également à escartefigue pour son commentaire. J'ai bien compris pourquoi il faut mettre en œuvre une contrainte d'exclusion pour empêcher un utilisateur de liker ses propres annonces. Je peux facilement réaliser cette contrainte en PHP, donc il n'y a pas de souci de ce côté-là.

J'ai quelques questions concernant la réalisation des entités-types "city" et "postal_code", ainsi que la mise en place des contraintes d'inclusion. J'imagine que cela implique l'utilisation d'une API pour vérifier si le code postal correspond bien à la ville. Cela risque d'être un peu compliqué pour moi à mon niveau de développement. De plus, je ne comprends pas très bien la relation entre les deux associations "C_P" et "P_A" réalisées par une flèche. Je me suis inspiré du lien que vous m'avez envoyé, mais je ne saisis pas clairement cette liaison. Peut-être dans un premier temps il est préférable de garder la ville et son code postal en intérieur de l'entité type AD.

Merci d'avance pour votre aide.

[fsmrel]

Bonsoir sg.jiri,

dans ma formation, on nous a toujours dit qu'il est préférable de favoriser l'utilisation de l'anglais en informatique.

 
C’est un parti pris stupide. Ça fait soixante ans que je pratique l’informatique à haute dose et j’ai toujours utilisé la langue française, car plus précise (tous les diplomates vous le diront). Je n’utilise la langue anglaise que lorsque, par exemple, je cite un auteur rédigeant en anglais ou quand certains termes sont consacrés (par exemple, à propos de la forme normale de Boyce-Codd, j’écris BCNF et non pas FNBC, au lieu de « variable relationnelle », j’utilise le terme « relvar », etc.).

Cela dit, que ma position ne vous empêche surtout pas d’écrire AD plutôt que Annonce...
 
 

Je peux facilement réaliser cette contrainte en PHP, donc il n'y a pas de souci de ce côté-là.

Heu... cette contrainte doit être plutôt programmée dans le langage de description et de manipulation des tables décrites par le MPD, c’est-à-dire en SQL (fonction, trigger).

Par ailleurs, telle que vous l’avez modélisée, votre contrainte d’exclusion dit qu’une annonce ne peut pas être un utilisateur. L’exclusion implique en fait les associations U_A et Likes (revoyez la modélisation proposée par escartefigue).
Pour vous guider, il existe fondamentalement l’ouvrage incontournable de D. Nanci et B. Espinasse Ingénierie des systèmes d'information - Merise deuxième génération,
c’est l’ouvrage de référence. Le chapitre décrivant les contraintes est le chapitre 13 (« Modélisation logique des données »). Voyez par exemple la figure 13.37.
 
 

Cela risque d'être un peu compliqué pour moi à mon niveau de développement. De plus, je ne comprends pas très bien la relation entre les deux associations "C_P" et "P_A" réalisées par une flèche.

Voyez la figure 13.39 de l’ouvrage que je viens de mentionner. Quoiqu’il en soit, escartefigue se fera certainement un plaisir de vous expliquer plus avant la contrainte.

Une fois de plus, cette contrainte doit être plutôt programmée dans le langage de description et de manipulation des tables décrites par le MPD, c’est-à-dire en SQL (fonction, trigger).

Encore bon courage !