Discussion :

[Snake7345]

Bonjour a tous,

Alors voilà je me suis lancé dans un petit projet mais vu mon niveau faible d'analyse j'aurais voulu vous soumettre mon MCD pour savoir si il y a possibilité de faire mieux ou pas(car je trouve que la table Users est quand même assez chargé en information) je compte faire mon exercice en PHP et c'est la première que je me lance dans quelque chose de si complexe et complet surtout car j'ai jamais gérer autant d'entités.

Voici moi comment je vois l'exercice :

Ici chaque utilisateurs et clubs de sport on un rôle (soit administrateur, soit club soit encore utilisateurs).Ici j'ai décidé de mettre admin club et utilisateurs ensemble c'est par choix.

Les rôles possèdent des droits (CRUD), par exemple voir une fiche, supprimer une annonce, mettre a jour une annonce ou créer une offre d'emploi.

Les clubs pratiquent un ou des sports et sont les seuls capables de poster une offre d'emploi. (les clubs peuvent voir les fiches des users et selon leurs besoins peuvent effectuer une recherche selon les différents corps de métier et ce sans abonnement)

Les utilisateurs (ici les administrateurs, les joueurs et entraineurs,...) font un ou plusieurs métiers car un joueur peut également être médecin ou encore entraineur.

Les utilisateurs (ici les administrateurs et en outre le webmaster) peut publier des news concernant les mises à jours du site.

Les utilisateurs possèdent chacun un panier dans lequel ils peuvent mettre un ou plusieurs produits (ici les produits sont des abonnements de X mois avec cette abonnement les utilisateurs peuvent avoir accès aux offres d'emplois et aux fiches des clubs).
Les utilisateurs peuvent effectuer des commandes et une commande correspond a un panier.
La commande génère une facture qui est payé par un mode de paiement et correspond à un encaissement à une date bien précise et d'un montant bien précis.

Mes questions sont les suivantes :

Est ce que le MCD est bon ? y-a-t-il moyen de faire mieux si oui comment ?
Et j'ai une grosse hésitation concernant la gestion des roles, des droits et aussi concernant tout ce qui est panier,paiement,facture,mode de paiement et encaissement est-ce bien juste ?

Merci a vous tous

Je vous transmet si joint mon MCD

[Charvalos]

Salut !

Voilà plusieurs points que j'ai remarqué :

• On remarque tout de suite que tu as CountryXXXX et TownXXXX. Dès lors, autant gérer les villes et les pays dans tes entités propres. Dans ton cas, tu n'as aucun contrôle sur ces données. L'utilisateur pourra entrer une ville quelconque voir pourra se tromper sur le nom de sa ville. Et si soudainement, une ville change de nom ou de NPA, je te souhaite bonne chance pour aller trouver et modifier les entrées.
• Je suppose que qu'un User peut être un responsable de club ? Dans ce cas, il te manque une liaison entre User & Club et tu peux virer RespClub et SexeRespClub.
• Toujours dans ton entité User, je pense que tu gères les images et ce LinkImageUser (même chose pour club) contiendra le chemin vers l'image stockée sur le serveur. Là-aussi, on a plutôt tendance à stocker les "images" dans une table propre où tu trouveras comme propriétés son nom, son extension, par exemple.
• À quoi correspond l'entité Job ?
• Je suppose que ton entité Basket correspond au panier d'achat de ton utilisateur. Dans ce cas, tu n'as pas besoin d'avoir une liaison entre Product et Orders car tu pourras de toute façon voir quel produit est dans quel panier qui lui-même est lié à une commande.
• Concernant la méthode de paiement, j'aurais tendance à la relier à l'utilisateur. Là, il ne pourra tout simplement pas gérer ses méthodes de paiement dans son compte.
• Je n'arrive pas bien à comprendre à quoi sert ton entité Cashing ?
• Idem également pour Delivery. À mon avis, elle ne sert pas à grand-chose car finalement, la date de paiement et l'état de la commande, c'est plutôt des propriétés liées à Orders, non ?

Voilà ce que j'ai trouvé, pour le moment.

[Snake7345]

Coucou charvalos et merci d'avoir répondu si rapidement.
Alors oui en effet, selon tes remarques ils y a des choses maintenant qui me sautent aux yeux.

Je vais l'adapter ce soir ou demain matin et ensuite le reposter pour voir encore si j'ai des fautes ou non.

Merci en tout cas charvalos je m'expliquerais sur tout ça pour voir si j'ai bien compris

[Snake7345]

Coucou a tous, coucou Charvalos

Voilà comme promis (avec un peu de retard pour ma part ^^ ) je te présente la version 2 de mon MCD, j'ai realisé les changements que tu m'as dit Charvalos et également j'ai fait quelques entités supplémentaires.

Pour répondre a ta question charvalos : Job correspond au travail de chaque users (ici dans mon cas c'est entraineur, gérant, joueurs,...), car j'aurais voulu faire ceci en mettant l'entité Job :

- Un club peut rechercher en fonction d'un métier ou encore d'un Code postal, un user qui exerce le métier de joueurs ou encore entraineur.

Alors parmi les autres changements :

- Un user peut (comme un club) afficher 0 ou 1 photo sur son profil.
- Un user peut résider à une adresse autre qu'un club (Voilà pourquoi les deux sont reliés).
- Une adresse correspond à une localisation (latitude et longitude).
- Un user choisit son mode de paiement pour la commande.
- (et la dans mon MCD précédent j'ai oublié quelque chose de majeur) : Un produit correspond à 0 ou plusieurs abonnements (car si sa se trouve tous les users choisissent l'abonnement à 6 mois et personne celui à 3 mois) et un abonnement correspond à un et un seul produit. Ici donc j'ai rajouté l'id de l'abonnement ainsi que la date de début et de fin d'abonnement pour activer quand l'user a payer et le désactiver quand l'abonnement est expiré.

[Charvalos]

Re-salut !

Je vais faire comme mon premier post :

• Est-ce qu'un club peut ne pas avoir de personne qui le gère ? C'est en tout cas ce qu'indique ta relation entre Club et Users.
• Je changerais ta table PostalCode. C'est les localités que tu gères et pas les codes postaux non ? Et vas-tu vraiment utiliser la longitude et la latitude ?
• Il y a quelque chose qui me dérange également et cela concerne Abonnement et Product. Si j'ai bien compris, un produit est en réalité un abonnement ? Ou il se pourrait que dans le futur, un club puisse vendre autre chose (maillot, chaussures, etc.) ?
  Déjà, dans ta table Abonnement, de mon point de vue, il manque des choses : un abonnement à sûrement un prix par mois, une description et une durée en + de la date de début et de fin de validité de l'abonnement. Typiquement, la date de fin, tu peux la calculer automatiquement en fonction de sa durée et de la date à laquelle l'abonnement a été activé pour la personne.
  Pour en revenir à la question, dans le cas où Produit = Abonnement, autant supprimer l'entité Produit qui est inutile. Par contre, si tu prévois que les clubs puissent vendre autre chose que des abonnements, alors là, je pense qu'il faudra changer l'entité Produits et y intégrer les propriétés de l'entité Abonnement puis faire une autre entité reliée à Produit que tu pourrais appeler TypeProduct, par exemple.
• Concernant la partie paiement, il y a quelque chose qui cloche. Déjà, je pense que logiquement, il devrait y avoir une relation entre User et Order (0,n - 1,1) : un User commande 0,n Order et un Order est commandé par 1 seul User. Maintenant, est-ce que savoir de quelle manière a été payé l'Order est nécessaire ? Est-ce que l'utilisateur, finalement, a besoin de savoir que sa commande XXXX a été payé par carte de crédit, paypal, autre ? Personnellement, je pense qu'il n'y a pas besoin d'avoir de liaison entre Payment_Mode et Orders. Pour toi, savoir de quelle manière va payer l'utilisateur te sera utile pour ton code pour pouvoir appeler le bon API (celui de Paypal, de la Banque, etc) voir pour pré-sélectionner la méthode de paiement quand l'utilisateur voudra payer.
• Pour en revenir à la table User, il y a peut-être moyen de séparer formation et nationalité dans deux entités séparées mais cela dépend de toi, de comment tu vois la chose.
• Je ne sais pas si tu a prévu de faire l'activation du compte par mail mais si c'est le cas, il te manque un champ dans ton entité User que j'appelle communément HashUser. En fait, lorsque l'utilisateur s'inscrit, il va générer un hash que t'ajouteras ensuite dans l'URL d'activation qui sera dans le mail. Et quand l'utilisateur cliquera sur l'URL de son mail pour activer son compte, tu compareras le hash de l'URL à celui de ta table.
• Est-ce qu'un utilisateur est obligé de communiquer des news ? C'est ce qu'indique ta relation.
• Je terminerais en parlant des droits. Je me pose la question de savoir si c'est vraiment nécessaire de stocker les droits dans la BDD. Je suppose qu'en fonction du rôle de l'utilisateur, tu interdiras l'accès à certaines pages ou certaines fonctions. Et finalement, cela tu le gères dans le code.

Voilà mes nouvelles remarques !

[escartefigue]

Bonjour,

Pour commencer, il manque la quasi-totalité des règles de gestion : chaque "patte" d'une relation est la résultante d'au moins une règle de gestion, par exemple
R001a : un utilisateur possède une et une seule adresse
R001b : pour une adresse il peut y avoir zéro à plusieurs utilisateurs
Ici R001a + R001b permettent de modéliser la relation que vous appelée "réside"
En l'absence de l'une de ces deux règles, rien ne justifie les cardinalités de votre MCD
Si existe des Contraintes d'Intégrité Fonctionnelles (CIF) il faut des règles de gestion supplémentaires (exemple : si seul l'utilisateur qui gère un club peut afficher l'image correspondante, c'est une règle de gestion qui concerne les relations "gère" et "affiche")


Ensuite, pourquoi avoir choisi de nommer les entités-type et les attributs en anglais et les relations en français
Soit votre application est maintenue par du personnel anglophone auquel cas le choix de l'anglais s'impose pour tous les objets, soit c'est une équipe francophone auquel cas le français s'impose.
Si la langue est l'anglais, les règles de gestions seront bien sur rédigées en anglais
De plus, l'usage est de nommer les entités-type au singulier : un type d'entité ou entité-type caractérise les attributs de toutes les occurrences d'entité.


Pour les typologies (type d'image, code sexe, code devise, code pays, code mode de paiement, code job...) il est préférable de créer une entité-type spécifique avec un identifiant, un code, un libellé et éventuellement une date de début et une date de fin de validité, entité-type à mettre en relation avec les entités-type concernées (un peu comme vous l'avez fait pour "job" mais qui est incomplet)
Faute de typologie, vous allez décrire plusieurs fois les mêmes choses avec des noms différents (ex : les pays dans l'entité-type UTILISATEUR)
Dans ce cadre, il faut définir des types de formation et des types d'expérience puis mettre en relation 0,n les utilisateurs avec ces formations et ces expériences : un utilisateur doit pouvoir avoir zéro à plusieurs formations et/ou expériences (si vous aviez rédigé les règles de gestion, vous n'auriez pas commis cette erreur )


Les adresses se codifient selon une norme.
Si l'application est française, référez vous aux normes de la poste c'est à dire 6 x 38 caractères avec un code postal en char(5) pour la France et une ligne de plus pour les adresses étrangères.
Si l'application est spécifique à un autre pays, recherchez la norme applicable dans ce pays.


Une donnée calculée ne doit jamais être stockée, sauf si c'est une valeur à date d'arrêté ou une contrainte réglementaire .
De ce fait, le montant total du panier ne doit pas être stocké mais calculé en faisant la somme des montants de chaque produit le composant.
De plus les montants se stockent dans des colonnes de type décimal.


Pour certaines entités-type, l'utilisation de l'identification relative serait profitable, par exemple le panier pourrait être identifié relativement à l'utilisateur, de même pour la commande.


Pour les rôles et droits/privilèges, il ne faut pas créer autant d'attributs qu'il y a de privilèges, mais répéter la relation autant de fois que nécessaire (une occurrence de relation pour la lecture, une autre pour la suppression...)
Notez que la cardinalité mini de 1 me semble requise, car vous avez oublié le droit en lecture qu'il est la plupart du temps nécessaire de gérer et si un ROLE existe c'est qu'il possède à minima un DROIT (là encore à confirmer en rédigeant les règles de gestion qui vont bien )
La relation pourrait/devrait être porteuse d'attributs date de début et date de fin de droit : les privilèges d'un rôle peuvent éventuellement changer (règles de gestion...)
De plus, vous avez déconnecté les droits des objets auxquels ils se rapportent, est-ce normal ? un utilisateur à -t- il les mêmes droits sur les annonces, les fiches, les offres (devinez quoi ... encore les règles de gestion )


"CASHING" comporte une date de paiement mais n'est en relation avec aucune personne qui effectue ce paiement


Règlementairement, il faut obligatoirement une facture pour justifier un paiement, or vous n'avez modélisé ni la facture, ni les lignes de factures


D'après votre MCD, une commande est livrée en une seule fois, n'y a -t- il jamais des livraisons multiples pour une même commande ? (eh oui, encore ces fichues règles manquantes )


Le nom de la relation "pratique" est inadéquat : un club de "pratique" pas un sport, il le propose. Ce sont les sportifs qui pratiquent un sport


D'après votre MCD, un utilisateur ne peut avoir qu'un seul panier, quelle que soit la date , très peu probable...


D'après votre MCD, un panier correspond à au moins une commande , comment gérez vous les paniers non validés ?

[Snake7345]

Re-salut !

Je vais faire comme mon premier post :

• Est-ce qu'un club peut ne pas avoir de personne qui le gère ? C'est en tout cas ce qu'indique ta relation entre Club et Users.
• Je changerais ta table PostalCode. C'est les localités que tu gères et pas les codes postaux non ? Et vas-tu vraiment utiliser la longitude et la latitude ?
• Il y a quelque chose qui me dérange également et cela concerne Abonnement et Product. Si j'ai bien compris, un produit est en réalité un abonnement ? Ou il se pourrait que dans le futur, un club puisse vendre autre chose (maillot, chaussures, etc.) ?
  Déjà, dans ta table Abonnement, de mon point de vue, il manque des choses : un abonnement à sûrement un prix par mois, une description et une durée en + de la date de début et de fin de validité de l'abonnement. Typiquement, la date de fin, tu peux la calculer automatiquement en fonction de sa durée et de la date à laquelle l'abonnement a été activé pour la personne.
  Pour en revenir à la question, dans le cas où Produit = Abonnement, autant supprimer l'entité Produit qui est inutile. Par contre, si tu prévois que les clubs puissent vendre autre chose que des abonnements, alors là, je pense qu'il faudra changer l'entité Produits et y intégrer les propriétés de l'entité Abonnement puis faire une autre entité reliée à Produit que tu pourrais appeler TypeProduct, par exemple.
• Concernant la partie paiement, il y a quelque chose qui cloche. Déjà, je pense que logiquement, il devrait y avoir une relation entre User et Order (0,n - 1,1) : un User commande 0,n Order et un Order est commandé par 1 seul User. Maintenant, est-ce que savoir de quelle manière a été payé l'Order est nécessaire ? Est-ce que l'utilisateur, finalement, a besoin de savoir que sa commande XXXX a été payé par carte de crédit, paypal, autre ? Personnellement, je pense qu'il n'y a pas besoin d'avoir de liaison entre Payment_Mode et Orders. Pour toi, savoir de quelle manière va payer l'utilisateur te sera utile pour ton code pour pouvoir appeler le bon API (celui de Paypal, de la Banque, etc) voir pour pré-sélectionner la méthode de paiement quand l'utilisateur voudra payer.
• Pour en revenir à la table User, il y a peut-être moyen de séparer formation et nationalité dans deux entités séparées mais cela dépend de toi, de comment tu vois la chose.
• Je ne sais pas si tu a prévu de faire l'activation du compte par mail mais si c'est le cas, il te manque un champ dans ton entité User que j'appelle communément HashUser. En fait, lorsque l'utilisateur s'inscrit, il va générer un hash que t'ajouteras ensuite dans l'URL d'activation qui sera dans le mail. Et quand l'utilisateur cliquera sur l'URL de son mail pour activer son compte, tu compareras le hash de l'URL à celui de ta table.
• Est-ce qu'un utilisateur est obligé de communiquer des news ? C'est ce qu'indique ta relation.
• Je terminerais en parlant des droits. Je me pose la question de savoir si c'est vraiment nécessaire de stocker les droits dans la BDD. Je suppose qu'en fonction du rôle de l'utilisateur, tu interdiras l'accès à certaines pages ou certaines fonctions. Et finalement, cela tu le gères dans le code.

Voilà mes nouvelles remarques !

Coucou a tous,

Alors merci tout d'abord pour vos remarques escartefigue et Charvalos je vais répondre dans l'ordre :
Charvalos :

• Il est vrai ici qu'il y a une grosse erreur car chaque club à au moins un user qui le gère mais un user n'est pas forcément dirigeant de club donc j'ai modifié
• Et bien écoute je gère les localités et les codes postaux car j'aurai besoin de ces données pour si un club veut effectuer une recherche sur un endroit pour savoir combien de users se trouve dans les environs imaginons à 40km à la ronde du code postal 15700 et savoir combien de users sont dans la zone. Je suis obligé de les gérer du coup.
• Ici un abonnement est un produit et sera le seul produit qu'on vendra. Les clubs ne vendront rien sur le site. Le club a l'inscription sa sera gratuit, tandis que les autres users devront payer un abonnement pour être visible sur le site.
  Donc ici du coup je vais supprimer l'entité produits et donc mettre tout dans l'entité Abonnements
  Ici donc du coup ben oui j'ai besoin de latitude et longitude pour avoir les users à la ronde lors d'une recherche.
• Alors par contre pour ici j'aurais besoin de plus d'explication pour l'API car ici j'ai quand même relié users et mode de paiement dans mon nouveau schéma que je vais présenter ici (plus en dessous) car l'user doit quand même sélectionner son moyen de paiement non ? et moi j'ai besoin de le savoir pourr le rediriger vers le site correspondant non?
• Alors pour nationalité tu as raison mais personnellement je vois formation dans l'entité User donc j'aurai tendance a laisser comme ça.
• Ha non c'est vrai que j'y ait pas penser et bien je vais ajouter un hash dans l'entité User et ici l'activationUser ca me permet de voir si le gars a un abonnement et donc d'activer son compte pendant la durée de l'abonnement.
• Problème corrigé aussi effectivement, j'ai tout ce qu'il faut avec rôle et également avec user.

Alors je réponds dans les heures qui suivent concernant escartefigue car là je vais allez en cours voici mon schéma à ce stade (avant d'avoir lu le post de escartefigue) :