Bonsoir Rachelle,
Les dates peuvent jouer un rôle important dans votre système.
(Q1) Je suppose qu’un étudiant passe plus d’un an dans une école. Qu’en est-il ?
(Q2) Supposons que la réponse à (Q1) soit positive. En fin d’année scolaire, alors qu’un étudiant de l’école E1 n’a pas encore effectué sa dernière année, peut-il quitter l’école E1 et passer à l’école E2 ?
Envoyé par
Rachelle
Il faut savoir les paiements relatifs à chaque étudiant au cas d'un responsable financier pour plusieurs étudiants.
En l’état, votre diagramme ne permet pas de prendre cette règle en compte : l’association entre PAIEMENT et RESPONSABLE_F doit être supprimée et remplacée par une association entre PAIEMENT et ETUDIANT. Comme on sait déterminer le responsable financier d’un étudiant, on sait pour chaque paiement quel responsable financier mettre en face d’un paiement.
(Q3) Supposons que la réponse à (Q1) soit positive. D’une année scolaire à l’autre, un étudiant peut-il changer de responsable financier ?
Concernant les modes de paiement : si la table PAIEMENT concerne les paiements effectués, on doit d’abord savoir quel sera le mode paiement choisi au départ par le responsable financier : par chèque, espèces ou virement. Autrement dit, la table PAIEMENT devrait être en relation avec de responsable financier, ou bien en relation avec l’étudiant au cas où le responsable financier aurait plus d’un étudiant à charge et choisirait un mode de paiement distinct par étudiant, ou encore si d’une année à l’autre, le mode de paiement pour un étudiant pouvait changer d’une année à l’autre.
Supposons donc que les modes de paiement ressortissent aux étudiants (si vous préférez que ce soit aux responsables financiers, faites-le savoir, en expliquant).
Si les paiements sont prévus d’être effectués par chèque, on peut enregistrer le numéro de compte (et autres données bancaires) dans une table ad-hoc, appelons-la par exemple COMPTE, et définir en outre une relation avec une table BANQUE dédiée au nom des banques :
[ETUDIANT]--0,N--------0,1--[COMPTE ]--0,N---------1,1--[BANQUE]
Ce qui s’interprète ainsi :
Les paiements concernant l’étudiant E1 peuvent être effectués par le compte C1, lequel détermine la banque B1.
Un étudiant est associé au plus à un compte et l’association est optionnelle. Un compte peut être utilisé pour plusieurs étudiants.
Au besoin, on peut conserver la trace des numéros de chèques dans une table attachée à la table COMPTE.
Pour tel autre étudiant, les paiements ne sont pas prévus d’être effectués par chèque, mais par virement : là encore, on peut prévoir le raccordement d’une table ECHEANCIER à la table ETUDIANT. A supposer qu’on ait des échéances mensuelles, avec des dates ou des montants qui ne sont pas constants :
[ETUDIANT]--0,N--------1,1--[ECHEANCE]
Si les échéances sont toutes identiques (même jour, même montant) :
[ETUDIANT]--0,1--------1,1--[ECHEANCE]
En tout cas, selon ce scénario, la table MODE_PAIEMENT n’est pas nécessaire, mais peut vous simplifier la vie au niveau des requêtes SQL...
En ce qui concerne les frais : pourriez-vous être plus explicite ? Suivant leur type, les frais ont des montants différents, mais ces montants s’appliquent-ils de façon uniforme aux étudiants ? Pourriez-vous raconter la vie des paiements en relation avec ces frais ?
Envoyé par
Rachelle
Comment je peux savoir si les règlements de paiement effectuer sont a jour et sans retard
La table PAIEMENT est porteuse d’un attribut Date_pai. Normalement vous devriez pouvoir la comparer avec la date du jour et, pour chaque étudiant, calculer un solde réel par rapport à un solde théorique.
Partager