Discussion :

[Tamzoro]

Bonjour,

J'aimerais avoir plusieurs avis sur une analyse de gestion d'un club sportif, il y a 4 entités (Personne, Seance, Type de Sport, Paiement). Cet exercice n'est pas une leçon que je dois remettre, mais je me pose des questions sur un futur projet assez similaire.

Donc nous avons 4 tables:
- la première table est l'entité personne avec 3 champs id, nom, prenom
- la seconde table est l'entité seance avec 4 fields id, date_seance, heure_debut, heure_fin
- la troisième table s'intitule type de sport avec 3 champs id, type_sport, prix
- le quatrième table se nomme paiement avec 3 champs id, date_saisie, mode_paiement



Je suis bloqué sur un petit point, admettons qu'une personne (on va l'appeler Jeremy) suit 3 séances de Tennis le prix est de 10 € la séances par jour (c'est un exemple):
le 01 04 2019 (date_seance) | 10:00 (heure_debut) | 12:00 (heure_fin)
le 03 04 2019 (date_seance) | 10:00 (heure_debut) | 12:00 (heure_fin)
le 04 04 2019 (date_seance) | 10:00 (heure_debut) | 12:00 (heure_fin)

Dans mon formulaire (futur CRUD), j'aimerais entrer les 3 séances avec le montant total (donc 30 €) dans une seule et unique ligne d'enregistrement.
Je vois pas trop comment faire ça, car je bloque entre la table seance et le paiement.

Qu'en pensez-vous?

D'avance merci

[escartefigue]

Bonjour,

Le problème c'est que vous mélangez des notions MCD (votre schéma), MLD (les tables) et traitement (le formulaire)

Procédons dans l'ordre en commençant par le MCD. Celui-ci doit être la conséquence de vos règles de gestion, or vous ne les avez pas fournies.

Vu le MCD on peut déduire les règles de gestion suivantes

R01a : une séance est concernée par un et un seul type de sport
R01b : un type de sport concerne au moins une séance
Déjà une remarque : R01b vous interdit de connaitre une type de sport tant que vous n'avez pas créé au moins une séance pour ce type. Ext-ce bien ce qui est souhaité (en général, pour les typologies, on utilise une cardinalité 0,n de la typo vers sa relation)

R02a : pour une séance il y a au moins une personne inscrite
R02b : une personne est inscrite à au moins une séance
Là encore des remarques : avec des cardinalités mini de 1 pour chaque "patte", vous ne pouvez ni créer une séance tant que personne ne s'y est inscrit, ni une personne tant que celle-ci n'est pas inscrite à une séance. Pourquoi-pas mais à confirmer.

R03a : une personne effectue zéro à plusieurs paiements
R03b : un paiement est effectué par une et une seule personne
Ces règles R03* sont à priori cohérentes, mais vous ne précisez pas de contrainte d'intégrité fonctionnelle éventuelle telle que : la personne qui paye doit elle être celle qui s'est inscrite à la séance ?

L'association entre SEANCE et PAIEMENT ne va pas (sauf explications contraires et donc règles de gestion écrites et validées ) : vu qu'une session concerne plusieurs personnes et qu'un paiement n'est effectué que par une personne, une seule personne paye donc pour tout le monde

A confirmer aussi, ce que votre MCD ne permet pas, c'est la possibilité éventuelle de payer plusieurs séances

Dans l'entité-type paiement, il manque le montant et éventuellement la devise
Dans l'entité-type paiement, il ne faut pas mettre d'attribut mode de paiement, mais créer une relation 1,1 vers une entité-type "MODE_PAIEMENT"

Une fois les règles de gestion complétées, on pourra corriger le MCD. Ce n'est qu'ensuite que les questions relatives au "comment" - et notamment votre question sur le paiement de plusieurs séances - devront être posées

[Tamzoro]

Bonsoir escartefigue,

Je vous remercie tout d'abord pour le temps que vous avez consacré à m'expliquer certains points flous et à vos corrections.

R01a : une séance est concernée par un et un seul type de sport
R01b : un type de sport concerne au moins une séance
Déjà une remarque : R01b vous interdit de connaitre une type de sport tant que vous n'avez pas créé au moins une séance pour ce type. Ext-ce bien ce qui est souhaité (en général, pour les typologies, on utilise une cardinalité 0,n de la typo vers sa relation)

Effectivement, je vais modifier la cardinalité à 0,n

R02a : pour une séance il y a au moins une personne inscrite
R02b : une personne est inscrite à au moins une séance
Là encore des remarques : avec des cardinalités mini de 1 pour chaque "patte", vous ne pouvez ni créer une séance tant que personne ne s'y est inscrit, ni une personne tant que celle-ci n'est pas inscrite à une séance. Pourquoi-pas mais à confirmer.

Je confirme, si une personne n'est pas inscrite et n'a pas payée, elle ne pourra pas suivre la séance.

R03a : une personne effectue zéro à plusieurs paiements
R03b : un paiement est effectué par une et une seule personne
Ces règles R03* sont à priori cohérentes, mais vous ne précisez pas de contrainte d'intégrité fonctionnelle éventuelle telle que : la personne qui paye doit elle être celle qui s'est inscrite à la séance ?

Oui, c'est obligatoire. La personne qui paye c'est celle qui va suivre la séance.

L'association entre SEANCE et PAIEMENT ne va pas (sauf explications contraires et donc règles de gestion écrites et validées ) : vu qu'une session concerne plusieurs personnes et qu'un paiement n'est effectué que par une personne, une seule personne paye donc pour tout le monde

Non, non, non... Surtout pas... Chaque personne paye ça propre séance...

A confirmer aussi, ce que votre MCD ne permet pas, c'est la possibilité éventuelle de payer plusieurs séances

En effet, c'est là où je bloqe...

Dans l'entité-type paiement, il manque le montant et éventuellement la devise
Dans l'entité-type paiement, il ne faut pas mettre d'attribut mode de paiement, mais créer une relation 1,1 vers une entité-type "MODE_PAIEMENT"

En fait, je récupère le montant depuis la table "type de sport" vers le "paiements" en passant par la table "séance".
Je vais également rajouté une table "mode_paiement"

Une fois les règles de gestion complétées, on pourra corriger le MCD. Ce n'est qu'ensuite que les questions relatives au "comment" - et notamment votre question sur le paiement de plusieurs séances - devront être posées

Je vous remercie pour m'avoir aidé à améliorer mon MCD, voici ma version finale...



Pensez-vous que je vais devoir ajouter une entité supplémentaire concernant le paiement de plusieurs séances?

D'avance merci

[escartefigue]

R02a : pour une séance il y a au moins une personne inscrite

R02b : une personne est inscrite à au moins une séance

Là encore des remarques : avec des cardinalités mini de 1 pour chaque "patte", vous ne pouvez ni créer une séance tant que personne ne s'y est inscrit,
ni une personne tant que celle-ci n'est pas inscrite à une séance. Pourquoi-pas mais à confirmer.

Je confirme, si une personne n'est pas inscrite et n'a pas payée, elle ne pourra pas suivre la séance.

Ce que vous n'avez pas compris c'est l'autre aspect de ma remarque précédente, à savoir que vous ne pouvez créer une occurrence de SEANCE que lorsqu'une PERSONNE se présente pour s'inscrire
C'est la première inscription qui crée la séance. Il est peu probable que ceci corresponde à votre souhait.
Donc de personne vers séance : 0,n si vous voulez pouvoir créer une personne même si elle n'est pas encore inscrite à une séance, sinon 1,n
Et de séance vers personne : 0,n très probablement, ce qui vous permet de proposer des séances même si personne n'est inscrit (ne serait-ce que pour tenir compte de la disponibilité des encadrants par exemple), 1,n sinon

Ces règles R03* sont à priori cohérentes, mais vous ne précisez pas de contrainte d'intégrité fonctionnelle éventuelle telle que : la personne qui paye doit elle être celle qui s'est inscrite à la séance ?

Oui, c'est obligatoire. La personne qui paye c'est celle qui va suivre la séance.

D'accord, en ce cas, il faut ajouter une Contrainte d'Intégrité Fonctionnelle (CIF) symbolisée par une flèche allant de l'association "payer" vers l'association "inscrir"
Avec

* "payer" = association entre "personne" et "paiement"
* "inscrire" = association entre "personne" et "séance"

(ajoutez des noms à vos associations sous forme de verbes à l'infinitif, ce sera plus clair )

Dans l'entité-type paiement, il manque le montant et éventuellement la devise

En fait, je récupère le montant depuis la table "type de sport" vers le "paiements" en passant par la table "séance".

Ca ne va pas, si une personne paye plusieurs séances, il faut pouvoir saisir le montant
D'ailleurs ,il peut arriver qu'une personne qui doit 100€ vous envoie un chèque de seulement 50€, refusez vous le paiement en ce cas ? peu probable. A confirmer la encore
De plus, qui dit paiement, dit facture, or vous n'avez modélisé ni la facture ni les lignes de facture.
Dans votre cas, la ligne de facture représentera la séance : un ligne par séance et la facture vous permettra donc de consolider plusieurs séances en un seul paiement comme souhaité
Il faudra préciser si l'inscription suffit pour facturer ou si c'est la présence effective à la séance qui compte, voire un mix des deux... encore des règles de gestion à préciser
Encore une fois, il faut supprimer l'association entre séance et paiement. Le paiement n'est pas relatif à une ou plusieurs séances, mais à une facture, c'est réglementaire !

Pensez-vous que je vais devoir ajouter une entité supplémentaire concernant le paiement de plusieurs séances?

Non, ceci est du ressort du traitement et n'impacte en rien le modèle de données

Je vous remercie pour m'avoir aidé à améliorer mon MCD, voici ma version finale...

Ben non pas finale compte tenu de ce qui précède.
Pensez aussi à supprimer l'attribut mode_paiement dans l'entité-type "paiement" et à ajouter le montant (voire la devise) compte-tenu de ce que j'explique plus haut

[Tamzoro]

Ce que vous n'avez pas compris c'est l'autre aspect de ma remarque précédente, à savoir que vous ne pouvez créer une occurrence de SEANCE que lorsqu'une PERSONNE se présente pour s'inscrire
C'est la première inscription qui crée la séance. Il est peu probable que ceci corresponde à votre souhait.
Donc de personne vers séance : 0,n si vous voulez pouvoir créer une personne même si elle n'est pas encore inscrite à une séance, sinon 1,n
Et de séance vers personne : 0,n très probablement, ce qui vous permet de proposer des séances même si personne n'est inscrit (ne serait-ce que pour tenir compte de la disponibilité des encadrants par exemple), 1,n sinon

Ok merci pour cette précision je n'avais effectivement pas compris ainsi.

D'accord, en ce cas, il faut ajouter une Contrainte d'Intégrité Fonctionnelle (CIF) symbolisée par une flèche allant de l'association "payer" vers l'association "inscrir"
Avec

* "payer" = association entre "personne" et "paiement"
* "inscrire" = association entre "personne" et "séance"

(ajoutez des noms à vos associations sous forme de verbes à l'infinitif, ce sera plus clair )

Je ne connaissais pas le CIF, je vais me documenter un peu plus sur ça à l'avenir.
Là je vais pas ajouter la contrainte d'intégration fonctionnelle, je ne sais pas le faire sur JMerise, mais je note ce que vous avez mentionné.

Ca ne va pas, si une personne paye plusieurs séances, il faut pouvoir saisir le montant
D'ailleurs ,il peut arriver qu'une personne qui doit 100€ vous envoie un chèque de seulement 50€, refusez vous le paiement en ce cas ? peu probable. A confirmer la encore

La personne doit pouvoir payer intégralement le montant pour pouvoir suivre le cours.

De plus, qui dit paiement, dit facture, or vous n'avez modélisé ni la facture ni les lignes de facture.
Dans votre cas, la ligne de facture représentera la séance : un ligne par séance et la facture vous permettra donc de consolider plusieurs séances en un seul paiement comme souhaité

Ah ok merci, donc je crée une table "facture" je là relie à paiement et je coupe ma relation entre seance et paiement c'est bien ça?

Il faudra préciser si l'inscription suffit pour facturer ou si c'est la présence effective à la séance qui compte, voire un mix des deux... encore des règles de gestion à préciser

Il s'agit de la présence uniquement

Encore une fois, il faut supprimer l'association entre séance et paiement. Le paiement n'est pas relatif à une ou plusieurs séances, mais à une facture, c'est réglementaire !

Ah voilà merci beaucoup j'ai ma réponse.

Ben non pas finale compte tenu de ce qui précède.
Pensez aussi à supprimer l'attribut mode_paiement dans l'entité-type "paiement" et à ajouter le montant (voire la devise) compte-tenu de ce que j'explique plus haut

Voici ci dessous un autre aperçu, cela vous semble correcte?

[SQLpro]

Votre MCD n'est pas bon. il faut décorréler les paiement des factures (balance) les factures devant être associées aux personnes.

A +