Discussion :

[mourareaupro]

Bonjour à tous ,

Je suis actuellement entrain de développer une base de donnée pour la gestion licences sportives , j'ai besoin de votre avis concernant l'obtention du prix d'une licence .

Une licence possède un type de licence et un sous type et une catégorie d'age , le prix sera en fonction de ses trois facteurs .

Par exemple pour une licence de type compétition cette licence possèdera le sous type : professionnel ou amateur et correspondra à une catégorie d'age . en fonction de cette catégorie d'age le prix changera

j'avais pensé à crée trois tables :

type_licence(id , libelle_licence)

sous_type(id , libelle_sous_type)

cat_age ( id , libelle_cat )



Comment puis-je mettre une table prix en fonction de ses trois paramètres ?



Merci d'avance !

[escartefigue]

Bonjour,

Est-ce que vos tarifs sont gérés à date ?

[mourareaupro]

Bonjour,

Est-ce que vos tarifs sont gérés à date ?

Bonjour , Concernant le mode de calcul du prix d'une licence j'ai en ma possession un document de cotisation des joueurs par exemple pour la licence compétition " amateur " le prix est basé sur la catégorie d'age ! Les cotisations se font à l'année

exemple :

Senior : 112,50 €

U20 : 93,75 €

U15 et U17 : 60 €

U7 , U9 , U11 , U13 : 22,50 €

Pour une licence compétition " professionnel "

Joueur de nationalité française :500 €
Joueur de nationalité étrangère : 750 €

[escartefigue]

Du ça peut donner ce MCD
Pièce jointe 237654

Et le MLD
Pièce jointe 237659

A une licence, sont associés un et un seul type, un et un seul sous-type et une et une seule catégorie
De même pour les tarifs
Comme ces attributs sont FK dans licence et dans tarif, il est facile de trouver le tarif pour une licence

[mourareaupro]

Merci beaucoup escartefigue , en effet après mur reflexion de mon coté se matin je me suis dis pourquoi pas faire une table " tarifs " avec les clés étrangères type_licence_id , sous_type_licence_id , categorie_age_id , et renseigner le montant selon le ficher des cotisations en ma possession .

je dois donc dans ma table licence rajouté tarif_id c'est bien cela ?

j'aurai donc une table licences :

-nom
-prenom
-datenaisse
-type_licence_id
-sous_type_licence_id
-cat_id
-tarif_id

arrête moi si je me trompe

de plus j'ai aussi des cotisations que doivent le club auprès de la fédération , un club avec le statut compétition doit payer à l'année 500 euro , un club avec le statue "loisir" doit payer 200 euro ,

j'ai donc une table club :

-nom
-numerostrucutre
-adresse
-cotisation_id
...

et une table cotisation

-id
-type_cotisation_libelle
-montant
-periode (365)-default

suis correcte dans mon raisonnement ? mille fois merci en tout cas pour ces précieuses informations !

[escartefigue]

Merci beaucoup escartefigue , en effet après mur reflexion de mon coté se matin ...

Ne pas confondre mûre réflexion et mur réfléchissant

je dois donc dans ma table licence rajouté tarif_id c'est bien cela ?

Oui, comme c'est le cas dans le MLD que je vous ai communiqué
Commencez toujours par le MCD, comme ça les FK apparaissent tout naturellement là où elles sont nécessaires, lors de la génération du MLD et/ou du MPD

j'aurai donc une table licences :

-nom
-prenom
-datenaisse
-type_licence_id
-sous_type_licence_id
-cat_id
-tarif_id

Nom, prénom, date de naissance sont des attributs d'une personne, pas d'une licence, donc vous ne devez pas les mettre dans l'entité-type licence.
Vous devriez avoir PERSONNE 0,n --- Posséder --- 1,1 LICENCE
Avec PERSONNE (id, nom, prénom, date de naissance....) et LICENCE (id, n°, date d'émission...)
Votre modélisation implique de répéter les attributs de la personne chaque fois que cette personne prend une nouvelle licence, ce n'est pas correct.

de plus j'ai aussi des cotisations que doivent le club auprès de la fédération , un club avec le statut compétition doit payer à l'année 500 euro , un club avec le statue "loisir" doit payer 200 euro

C'est quoi l'attribut période(365) dans cotisation ?

[mourareaupro]

Ne pas confondre mûre réflexion et mur réfléchissant


Oui, comme c'est le cas dans le MLD que je vous ai communiqué
Commencez toujours par le MCD, comme ça les FK apparaissent tout naturellement là où elles sont nécessaires, lors de la génération du MLD et/ou du MPD



Nom, prénom, date de naissance sont des attributs d'une personne, pas d'une licence, donc vous ne devez pas les mettre dans l'entité-type licence.
Vous devriez avoir PERSONNE 0,n --- Posséder --- 1,1 LICENCE
Avec PERSONNE (id, nom, prénom, date de naissance....) et LICENCE (id, n°, date d'émission...)
Votre modélisation implique de répéter les attributs de la personne chaque fois que cette personne prend une nouvelle licence, ce n'est pas correct.


C'est quoi l'attribut période(365) dans cotisation ?

Je me doutais bien que je fessais fausse route , il faut que je crée un entité personne !

par contre dans mon application je voudrai avoir une fiche de saisie pour un licencié donc avec la table personne avec nom , prenom , photo , date naissance , type licence , sous type licence , cat_age ect ... a quoi va me servir cette table licence ?

l'attribut période c'est pour la validité de la cotisation , la cotisation est valide 1 an , l'année suivante le club doit re payer ca cotisation . je n'e sais pas comme modéliser ces données .

[escartefigue]

Je me doutais bien que je fessais fausse route , il faut que je crée un entité personne !

Oui mais aussi une entité licence

par contre dans mon application je voudrai avoir une fiche de saisie pour un licencié donc avec la table personne avec nom , prenom , photo , date naissance , type licence , sous type licence , cat_age ect ... a quoi va me servir cette table licence ?

Non, vous aurez 2 tables PERSONNE et LICENCE comme décrites dans ma réponse précédente.
Type_licence, sous_type... ne seront pas dans la table PERSONNE mais dans la table LICENCE
Une règle à laquelle il ne faut jamais déroger : tout attribut d'une table doit dépendre fonctionnellement de l'identifiant de cette table
Le type_licence par exemple ne saurait dépendre d'une personne : si une personne change de licence l'année suivante, elle peut très bien changer de type, or c'est toujours la même personne. CQFD

l'attribut période c'est pour la validité de la cotisation , la cotisation est valide 1 an , l'année suivante le club doit re payer ca cotisation . je n'e sais pas comme modéliser ces données .

Si toute cotisation est valable un an alors inutile de stocker cette durée, par contre, vous devez connaitre la date de paiement de la dernière cotisation de chaque club et le montant payé pour vérifier si chaque club est bien à jour de ses cotisations

Question subsidiaire : il me semblait que, au moins pour certains sports, les cotisations du club vers la fédération étaient proportionnelles au nombre de licenciés du club, je me trompe ?

EDIT : pour ce qui concerne les photos des personnes, selon le type de donnée, il peut être préférable de les stocker dans une nouvelle table spécifique (pour des raisons de performances)

[mourareaupro]

Oui mais aussi une entité licence


Non, vous aurez 2 tables PERSONNE et LICENCE comme décrites dans ma réponse précédente.
Type_licence, sous_type... ne seront pas dans la table PERSONNE mais dans la table LICENCE
Une règle à laquelle il ne faut jamais déroger : tout attribut d'une table doit dépendre fonctionnellement de l'identifiant de cette table
Le type_licence par exemple ne saurait dépendre d'une personne : si une personne change de licence l'année suivante, elle peut très bien changer de type, or c'est toujours la même personne. CQFD


Si toute cotisation est valable un an alors inutile de stocker cette durée, par contre, vous devez connaitre la date de paiement de la dernière cotisation de chaque club et le montant payé pour vérifier si chaque club est bien à jour de ses cotisations

Question subsidiaire : il me semblait que, au moins pour certains sports, les cotisations du club vers la fédération étaient proportionnelles au nombre de licenciés du club, je me trompe ?

Bien reçu du coup pour vérifier si la cotisation est bien à jour je rajoute un champ date_cotisation , montant ?

effectivement , cependant dans mon cahier des charges la cotisation est applicable en fonction du statut du club , le club doit ensuite payer les licences de son club !

Du coup je dois vérifier que les cotisations des licences du club sont bien à jour aussi dans la table licence je devrai rajouter la date de validité je suppose ?

Enfaite pour faire simple même si l'organisation est quelque peu complexe voila pourquoi je demande de l'aide aujourd'hui , un club peu enregistrer des licences pour des joueurs , le club doit ensuite payer les licences à la fédération . le paiement des licences donne lieu à un bordereau unique et donne lui à une facture .

Je doit donc rajouté licence_id dans la table bordereau somme nous d'accord sur se point ? ensuite je rattache bordereau_id dans la table facture ?

[escartefigue]

Non, le n° de licence ne peut pas être attribut de la table bordereau, car un bordereau concerne plusieurs licences et peut être qu'une licence concerne plusieurs bordereaux (si la même licence est conservée plusieurs années, il faut bien la repayer chaque année).

Il s'agit donc d'une relation n,n et donc vous devriez avoir, au niveau conceptuel

LICENCE 0,n --- Concerner --- 1,n BORDEREAU

Ce qui donne les 3 tables suivantes
LICENCE (id, numéro, date d'émission...)
CONCERNER (id_licence, id_bordereau)
BORDERAU(id, numéro, date, montant...)

[mourareaupro]

Non, le n° de licence ne peut pas être attribut de la table bordereau, car un bordereau concerne plusieurs licences et peut être qu'une licence concerne plusieurs bordereaux (si la même licence est conservée plusieurs années, il faut bien la repayer chaque année).

Il s'agit donc d'une relation n,n et donc vous devriez avoir, au niveau conceptuel

LICENCE 0,n --- Concerner --- 1,n BORDEREAU

Ce qui donne les 3 tables suivantes
LICENCE (id, numéro, date d'émission...)
CONCERNER (id_licence, id_bordereau)
BORDERAU(id, numéro, date, montant...)

merci beaucoup pour votre réponse,
concernant la facture, une facture correspond à 1 bordereau et 1 bordereau correspond à une facture , relation 1,1 , exact ?

[escartefigue]

Oui ou peut-être 1,1 d'un coté et 0,1 de l'autre je n'ai pas bien compris dans quel ordre sont établis bordereau puis facture ou facture puis bordereau, en tout cas, prévoyez le cas échéant que l'un puisse exister sans l'autre (mini zéro donc)

[mourareaupro]

Oui ou peut-être 1,1 d'un coté et 0,1 de l'autre je n'ai pas bien compris dans quel ordre sont établis bordereau puis facture ou facture puis bordereau, en tout cas, prévoyez le cas échéant que l'un puisse exister sans l'autre (mini zéro donc)

Très bien merci ,

Voila ma base de donnée :

licences(id , type_licence , sous_type_licence , categorie_age , prix )
personnes(id , nom , prenom , ... , licence_id )
categorie_ages(id , libelle_cat)
type_licences(id , libelle_type )
sous_type_licence(id , libelle_sous_type )

cependant j'ai vue que vous avez préférer plutôt crée une table tarifs héritant des clefs étrangères type , sous type , cat . pourquoi ne pas directement renseigner le prix dans la table licence selon les type , sous type , et cat sélectionne ?

[escartefigue]

J'ai préféré créer une E-T TARIF, car le prix n'est pas en dépendance fonctionnelle de l'identifiant de l'E-T LICENCE, toutes les licences qui partagent le meme type, sous type et catégorie ont le même tarif à un instant "t"
Ce choix vous permettra de passer plus facilement à une tarification à date si besoin, le MCD devenant alors :
LICENCE (id_licence, numéro, id_personne FK) 1,1 --- Tarifer --- 0,n TARIF (id_tarif, code_tarif) --- 1,n Tarifer (prix) --- 0,n CALENDRIER (Date, jour_sem)

[mourareaupro]

Très bien , concernant l'entité licence dans mon cahier des charges une personne est forcément une licence et non une personne possède une licence. Puis-je dans ce cas supprimer ma table personne ?

[escartefigue]

En ce cas votre cahier des charges est faux car vous avez mentionné plus haut que la licence dépend notamment de la catégorie d'âge, or, l'âge varie.
Donc selon les années, la licence d'une même personne va changer. On a donc bien une relation PERSONNE 1,n --- Posseder --- 1,1 LICENCE

De plus je répète encore une fois, que les attributs de la personne (nom, prénom, date de naissance, etc...) ne dépendent pas fonctionnellement de l'identifiant de la licence, donc même si vous aviez une relation 1,1, il serait légitime d'avoir 2 entités-type différentes.

[mourareaupro]

[QUOTE=escartefigue;8926058]En ce cas votre cahier des charges est faux car vous avez mentionné plus haut que la licence dépend notamment de la catégorie d'âge, or, l'âge varie.
Donc selon les années, la licence d'une même personne va changer. On a donc bien une relation PERSONNE 1,n --- Posseder --- 1,1 LICENCE

De plus je répète encore une fois, que les attributs de la personne (nom, prénom, date de naissance, etc...) ne dépendent pas fonctionnellement de l'identifiant de la licence, donc même si vous aviez une relation 1,1, il serait légitime d'avoir 2 entités-type différentes.

Oui mais aussi une entité licence

Très bien , de plus la base de donnée doit contenir des dirigeants qui doivent eux aussi avoir une licence du coup se sera la même methode que pour l'entité personne , la table dirigeant aura ( id , nom , prenom , fonction_id , licence_id ) c'est bien ca ?

Du coup si je récapitule mon architecture j'ai la base de donnée suivante :

personne ( id , nom , prenom , licence_id )
licence(id , numero_licence , type_licence_id , sous_type_licence_id , cat_age_id , tarif_id )
CONCERNER (id_licence, id_bordereau)
BORDERAU(id, numéro, date, montant...)
tarif(id , type_licence_id , sous_type_licence_id , cat_age_id , tarif_montant)
type_licence(id , libelle_type)
sous_type(id , libelle_sous_type)
cat_age(id , libelle_cat)
facture(id , numero , bordereau_id) ?
CALENDRIER (Date, jour_sem)

somme nous d'accord ? je nage un peu je vous avoue !

[escartefigue]

Très bien , de plus la base de donnée doit contenir des dirigeants qui doivent eux aussi avoir une licence du coup se sera la même methode que pour l'entité personne , la table dirigeant aura ( id , nom , prenom , fonction_id , licence_id ) c'est bien ca ?

Surtout pas, un dirigeant est une personne, donc c'est la même table que personne, par contre, cette personne a un rôle particulier, celui de dirigeant
Vous devez donc modéliser
PERSONNE (id, nom, prénom, etc...) 0,n --- Exercer (Date début, Date fin) --- 0,n ROLE (id, code, nom, libellé, date de début de validité...)

Bien sur, la relation doit être porteuse d'attributs date, car le rôle peut changer dans le temps

Dans la table des rôles, vous pouvez avoir dirigeant, administrateur, secrétaire etc...
La cardinalité mini de zéro coté personne vous permet de n'avoir aucun rôle pour les simples adhérents

A vérifier, car c'est impactant sur la modélisation, une même personne peut elle exercer plusieurs rôles à la même date

[escartefigue]

somme nous d'accord ? je nage un peu je vous avoue !

C'est par ce que vous sautez les étapes, l'erreur c'est de réfléchir sur les tables en 1er, alors qu'il faut commencer par la modélisation conceptuelle, c'est à dire le MCD.

[mourareaupro]

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

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

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 .

il ne me reste plus que modéliser une entité Personne qui correspond à tout les acteurs du systeme d'information et faire une autre table STATUT ( id , libelle qui peu prendre joueur , dirigeant )

pour faire simple a la base j'avais ce mdc