Modèle de données

Bonjour tout le monde,


je ne sais pas si je me trouve sur le bon forum (merci d'avance pour votre indulgence) :-)))

Actuellement sur le développement d'une appli de gestion d'un club sportif, en Symfony2/Doctrine2, pourriez-vous me donner votre avis sur cette ébauche de modèle de données ?


Merci d'avance pour votre aide très précieuse :-)


Un Utilisateur (FosUserBundle) peut être Président ou Joueur et avoir des infos complémentaires
Dans le cas d'un Président, il peut être président d'un Club et ce Club peut avoir x équipes
Dans le cas d'un Joueur, il peut être inscrit dans un Club

Pièce jointe 195102

Il existe un forum spécialement dédié à la modélisation (http://www.developpez.net/forums/f94.../modelisation/)
Sinon, je ne sais pas trop que dire sur le modèle dans la mesure où je ne vois pas très bien ce qui se cache derrière les "lienUser", "lienClub" et autres...
Sont-ce des champs ? A mon avis, ces simili champs ne devraient pas apparaître du tout sur le schéma car ils brouillent l'information et n'auront aucune existence concrète une fois la base générée. Les relations suffisent.
Je te conseillerais de passer par un outil dédié à la modélisation. L'idéal pour apprendre étant de bien faire un "modèle conceptuel" avant de passer "modèle physique" (avec des clés). Je ne connais pas trop les logiciels de modélisation conceptuels libres mais dans un cas comme ça (qui reste relativement simple), tu peux peut-être te contenter de passer directement à l'étape modèle physique avec un outil du genre MySQL Workbench si ta base est sous MySQL.
Les avantages sont que les notations habituelles de ce genre de schémas seront respectées et que tu pourras générer directement la base de données à partir de Workbench.

L'autre petite remarque est que je ne vois pas tellement d'intérêt à séparer l'User de UserInfo. En dehors de gagner quelques pouillèmes de place lorsque le User n'a pas de nom ou de prénom...
Sinon, à part ça, ça semble bien.
Les entités me semblent correctes et les relations également.
Attention toutefois aux 0 qui n'apparaissent pas dans les cardinalités précisées (one to one : un user peut-il ne pas être président ? Un président peut-il ne pas être user ? Je me doute des réponses mais cela n'apparaît pas dans la notation "one to one")

Merci beaucoup fatbob pour ta réponse très claire et tes conseils précieux !!!


Effectivement la table UserInfo n'a pas lieu d'être :-) je peux la fusionner avec la table User !!!

Pour les cardinalités ... il me semble que cette notion n'est pas présente dans Doctrine ... est-ce que je me trompe ?

Et pour les liens, je les ai mis puisque dans Doctrine, on doit les faire apparaitre pour le mappage (mappedBy et inversedBy).

La notion est présente mais pas apparente.

Une cardinalité 0..n va donner lieu à un champ non obligatoire alors que 1..n va donner un champ obligatoire.
Si tu travailles avec symfony, toutes ces questions sont quasi-transparentes. Le processus de création d'une base et de son intégration dans symfony devrait être :
- modélisation conceptuelle (on ne s'occupe que des concepts, de leurs caractéristiques et des relations entre les concepts). En particulier, on ne se pose pas de question sur les clés primaires et étrangères et toutes ces choses qui n'existent que pour des raisons techniques (dans le monde réel, une personne a bien un nom et un prénom mais pas d'id - du moins pas encore -)
- modélisation physique (on ajoute les notions de clés). Ce modèle peut souvent être généré à partir du précédent dès lors qu'on a les outils adéquats. On peut éventuellement apporter quelques modifications pour améliorer certains aspects (performances par exemple). On parle souvent de dénormalisation, étant sous-entedu que le modèle physique généré à partir du modèle conceptuel devrait normalement être normal (pour plus d'info : google modèle normal)
- génération de la base à partir du modèle physique. Il est utile de laisser l'outil s'occuper de la base sans intervenir manuellement. Ceci permet de garantir que le schéma sera toujours l'image de la base.
- génération des entités doctrine et des objets à partir de la base. Symfony propose les générateurs qui vont bien et du coup, c'est transparent.

A mon avis, il vaut mieux respecter les conventions et représentations des modèles classiques. Ce sera plus facile pour communiquer. De plus, il est préférable de faire son schéma sans contrainte liée à l'implémentation (d'où la présence de l'étape de modélisation conceptuelle). Cela permet de savoir ce que l'on veut.

Ensuite, petit à petit on intègre des considérations liées à notre environnement de développement ou aux performances. Cela peut nous amener à faire évoluer le modèle mais ces modifications doivent être sérieusement pesées. Si le modèle conceptuel est bon, toute modification au niveau physique ne peut que faire baisser sa robustesse à l'évolution et sa lisibilité. Dans un cas comme le tien aucune modification n'est acceptable (je le précise juste pour insister sur le fait que la modification au niveau physique, en dehors de l'ajout des champs des clés, est une option à n'utiliser que lorsqu'on sait ce qu'on fait).

Je t'invite quand même à aller faire un tour sur le forum modélisation. Il y a là des personnes bien plus au point que moi sur le sujet.

Merci beaucoup fatbob pour ton aide !!!

je vais suivre tes conseils :-)

Coucou tout le monde :-)


j'ai revu/simplifié le modèle !!!

est ce que vous pourriez m'aider sur l'intégration en doctrine ? je galère sur la mise en place des relations...


Merci d'avance pour votre aide :-)


Pièce jointe 203442