Discussion :

[escartefigue]

d'accord du coup les joueurs sont aussi dans la table Personne !

Oui

effectivement selon mon cahiers des charges un dirigeant peu avoir plusieurs postes ( roles )

Dans ce cas pas d'impact MPD

cependant ce changement va impacter grandement ma conception de base de donnée car j'avais une entité club ( id , nom , adresse , ... , equipe_id ) et j'avais une entité dirigeant ( id , nom , prenom , club_id ) , je compter rajouter licence_id pour pas mon compliquer dans dirigeant mais apriori ce n'est pas la bonne solution .

Ce n'est pas la bonne solution et ca ne va pas du tout : la présence de l'identifiant équipe dans la table club, signifie qu'un club ne peut avoir qu'une seule équipe
De même, mais la c'est sans doute moins grave, un dirigeant ne peut être que dans un seul club, n'y a -t- il pas des cas, sans doutes rares, dans lesquels une même personne peut exercer un rôle dans plusieurs clubs ?

EDIT : en observant le MCD que vous venez de communiquer, je me rend compte qu'il y a des choses qui ne correspondent pas à nos échanges
Par exemple, vous avez modélisé TYPE 1,1 --- donner_lieu --- 1,1 SOUS_TYPE
Or vous aviez mentionné que la licence dépend de la catégorie d'age, du type, et du sous type, ce n'est pas ce que représente ce modèle. Dans ce modèle, la licence ne dépend que de la catégorie et du type

Avant même de commencer le MCD, il faut rédiger et faire valider les règles de gestion, car là ce n'est vraiment pas clair

[mourareaupro]

Effectivement je m'était trompé, j'avais corrigé le tir lors de ma modélisation pour une base de donnée pour LARAVEL



effectivement un dirigeant peut exercer dans plusieurs clubs même si c'est très rare , je dois donc faire une table pivot c'est bien ca ? pour dire que club a plusieurs dirigeants ( personnes ) et que les dirigeants ( personnes ) sont rattachés à 1 ou plusieurs clubs ?

EDIT : effectivement c'est un premier MCD avant même que je me mette d'accord avec eux sur les règles de gestions spécifiques , depuis le mcd a changé cependant j'ai effectué les modifications sur la base de données directement

[escartefigue]

Aïe, il ne faut pas modifier la base de données sans retoucher le MCD, car du coup il y a risque de regression lors d'une prochaine maintenance et la documentation n'est plus à jour

Autres remarques

• n'utilisez jamais de nom réservés comme nom de table ou d'attribut, ca ça complexifie inutilement les requêtes et n'apporte rien.
  Donc TIMESTAMP, WHERE, SELECT, NULL, DISTINCT, UPDATE etc... ne doivent pas être utilisés
• le type et la longueur des attributs sont des choses importantes. Définir un nom sur du CHAR(255) a des conséquences sur l'espace disque et l'encombrement réseau, pour une justification plus qu'hasardeuse. Si en moyenne, vos adhérents de club ont des noms de 20 caractères, vous allez stocker autant de fois 235 caractères blanc que vous avez de licenciés !

En fait ce sujet devrait être déplacé dans le forum modélisation

[mourareaupro]

C'est noté !

j'ai effectué un rapide MCD pour modéliser ce dont nous avons parlé par rapport à la licence et aux personnes qui correspondent à soit un joueur , dirigeant , officiels ect ..

cela vous semple correct ? merci encore

je pense que je me suis trompé pour la clef étrangère personne_id dans club c'est plutôt club_id dans personne pareil pour compétition c'est la personne qui hérite de compétition

[escartefigue]

En fait, au niveau conceptuel, les clef étrangères ne doivent jamais apparaitre.
Elles sont générées automatiquement lorsque vous dérivez le modèle logique ou le modèle physique à partir du MCD
Pour cela, il faut utiliser un logiciel de modélisation. Il en existe des gratuits que vous pouvez télécharger.

Difficile de dire si votre modèle est correct sans avoir les règles de gestion
Exemple : vous modélisez une relation entre personne et compétition d'une part mais aussi entre équipe et compétition d'autre part, c'est peut être juste, mais sous réserve qu'il existe des compétitions individuelles et d'autres par équipe, Est-ce le cas ?
autre chose, il n'y a aucune relation entre personne et équipe. Est-ce normal ? on pourrait imaginer une relation à date par exemple
Il manque probablement des entités-type et des relations, par exemple, une compétition s'inscrit dans le cadre d'un championnat ou d'une coupe, voire éventuellement plusieurs, or vous n'avez rien modélisé en ce sens

Bref beaucoup d'inconnues liées à l'absence de RG sans lesquelles vous ne pouvez valider le modèle conceptuel

Or si le modèle conceptuel est faux, vos tables seront inadaptées.

[StringBuilder]

[mode cheveux sur la soupe]
Bonjour,

J'ai pas trouvé dans la discussion d'explications entre "type licence" et "sous type licence". Pas plus qu'une potentielle relation entre les tranches d'âge et les types / sous-types de licence.

En effet, d'un sport à l'autre (type licence) les catégories peuvent éventuellement varier (pro / amateur, mais pourquoi pas autre-chose) et je me demande si d'un sport à l'autre, et entre pro et amateur, les tranches d'âges seront toujours les mêmes...

Dans certains sports, on est senior à 25 ans, dans d'autres, on reste "junior" jusqu'à 35... donc je me pose la question... idem, entre un sportif professionnel et 25 ans (vieillard qui tiens plus debout sur un podium) et un sportif amateur de 25 ans (force de l'âge au top de sa forme) je me demande si c'est bien les mêmes tranches...
[/mode cheveux sur la soupe]

A mon avis, sous-type est une entité fille de type, et âge pourrait bien être fille de l'une ou de l'autre.

[mourareaupro]

L'application que je dois réaliser ne comporte que le rugby du coup les tranches d'ages , type , sous type ne changent pas ! pour revenir à ton observation concernant les compétitions effectivement dans le rugby il existe des championnats et des coupes . du coup une compétition peut être rattachée à un championnat ou une coupe je pense . es tu d'accord ?

je dispose de ce référentiel pour l'application : https://www.sendspace.com/file/bpn3ex

ainsi que de ces règles de gestion que j'ai établies avec la fédération : https://www.sendspace.com/file/use6qi

[escartefigue]

Bonjour,

Je ne peux pas accéder aux liens que vous avez communiqué, probablement à cause d'un filtrage sur le site où je suis

Je reviens au MCD que vous avez communiqué dans votre réponse n°24
la relation entre PERSONNE, CLUB et FONCTION doit être une relation ternaire, elle doit être à date, et il faut prévoir qu'une personne puisse exercer plusieurs fonctions, ce qui donne :

PERSONNE 0,n --- Exercer (date debut, date fin) --- 0,n FONCTION
.............................│
CLUB 0,n ------------┘

[mourareaupro]

mince , c'est dommage ...

d'accord ce qui nous donnerait :

Personne(id , nom)
exercer(personne_id , club_id , function_id , date_deb , date_fin)
club(id , nom)

?

[escartefigue]

C'est bien ça

Note : vous n'êtes pas obligés de citer chaque intervention des autres contributeurs, une citation n'est utile que si elle concerne une réponse qui ne précède pas immédiatement la votre, ou que vous souhaitez scinder la réponse d'un contributeur en différents sous ensembles, de façon à pouvoir y répondre point par point

Autrement dit, cliquez le plus souvent sur "répondre à la discussion" en bas à gauche, plutôt que "répondre avec citation" en bas à droite

Vous pouvez également voter en cliquant sur le pouce vert pour les réponses qui vous ont été utiles
... ou voter contre les réponses qui vous auraient semblé erronées, mais en ce cas merci d'en expliquer les raisons