Discussion :

[desireles]

bonjour à tous,

voila je dois présenter un travail technique de réalisation d'une base de données, suivi d'un oral pour expliquer bien sur, pour juin .

le sujet : gestion d'une classe de maternelle

ce que cette base devrait faire : (attention il faut s'accrocher!)
-table enfants ( nom,prénom,adresse,dae de naissance ...)
-table parents ( nom,prenom,tel,adress, relation avec la table enfants(j'imagine) )
-table code postal
-table semaine (jours)
etc

la problématique :
l'enseignante doit pouvoir avoir la liste de ses enfants, connaitre leur presence, s'ils font ou pas la sieste, les repas qu'ils prennent (collation,diners chaud ou tartines), s'il sont propre(oui/non)

ensuite pour elle meme:
une table activités reprenant les activites qu'elle fait, et chaque activites aboutirait au final sur des travaux ou exercices a faire dans le domaine choisi.

bon j'ai crée ce qu'il me semblait être toute les tables mais au final quand je regarde les relations, je crois qu'il y a moyen de simplifier tout àa , c'est énorme.

je mets en annexe ce que j'ai pour que vous visualisiez mieux.

je recherche de l'aide pour réaliser cela, je ne cherche pas à ce qu'on le fasse pour moi mais un coup de pouce pour me mettre sur la voie ou dumoins de quoi démarrer correctement.

toute aide sera la bienvenue

d'avance merci à tous

[f-leb]

bonjour,

en effet, faut simplifier tout ça...

Français, Maths, Eveils techno., Religion, etc. sont des Disciplines (ou matières comme tu veux).

Discipline(iddiscipline, nomDiscipline, ...)

savoir-parler, savoir-ecrire, savoir-... sont des savoir-faire

par exemple peinture, dessin, bricolage, je ne sais pas ce que tu mets dedans. Ce sont aussi des savoir-faire à acquérir ou bien des activités reliées à des disciplines.
Tables SavoirFaire, Activité, etc...

il faut commencer par débroussailler de ce côté.

[jimbolion]

desireles,

Une partie de ta solution pourrait être prise en charge en utilisant la technique des Meta données, regarde ce sujet :

http://sqlpro.developpez.com/cours/m...n/metadonnees/

En plus, des spécialistes en modélisation sur le chat (forum Base de données) pourront t'aider à bâtir l'ossature de ton modèle. Sans nécessairement te fournir la solution, ils te donneront de bons conseils.

A bientôt donc,

JimBoLion

[desireles]

[f-leb]

C'est le jour et la nuit d'un coup, jimbo ne serait pas passé par là... par hasard

Si j'ai bien compris l'idée, Je suggérerais bien encore :
T_releves(idReleve, ..., #EnfantRepas_FK, ...)

au lieu de :
T_releves(idReleve, ..., #Enfant_FK, #Repas_FK, ...)

[jimbolion]

Fab,

Y aurait t-il une signature ? Je vais encore m'attirer les foudres d'Argy

Si j'ai bien compris l'idée, Je suggérerais bien encore :
T_releves(idReleve, ..., #EnfantRepas_FK, ...)

Effectivement au bout de trois heures, on a oublié qu'on avait recréer cette entité !
Merci (1 index au lieu de 3 super !)

Et puis SemaineNo dans T_Releves plutôt que SemaineN°

JimBoLion

[desireles]

merci à tous pour vos précieux conseils , j'avance bien plus vite et je comprends mieux

[desireles]

f-leb on préfère garder dans T_releves , enfant_FK ET repas_FK , pour une gestion plus précise , maintenant si le fait de mettre enfantrepas_FK on peut gérer les 2 séparément, ok , mais suis pas sur .

[desireles]

suite de mes aventures , je recherche de l'aide pour attaquer mes formulaires correctement maintenant que les relations sont au point

d'avance merci à tous et bonne soirée

[desireles]

oups je déplace le sujet dans IHM ce sera plus logique , je clos ce sujet encore merci

[f-leb]

Un "relevé" est effectué pour un enfant ayant pris un repas si j'ai bien compris.

T_releves(idReleve, ..., #Enfant_FK, #Repas_FK, ...)
Il est possible alors de prendre un couple (enfant, repas) qui ne figure pas dans la table TJ_EnfantRepas. Et pas conséquent de facturer un repas qui n'a jamais été pris. Ceci peut être évité par le jeu de l'intégrité référentielle en référençant directement TJ_EnfantRepas.idEnfantRepas.

Après comme la saisie se fait par l'intermédiaire de formulaires, on peut s'arranger dans les listes déroulantes ou autres pour sélectionner des couples (enfant, repas) valides. C'est sans doute par commodité de programmation au niveau de l'IHM que jimbo a retenu cette solution.

Ou alors il y a peut-être des cas où on a le droit d'avoir un couple (enfant,repas) dans T_Releve qui ne figure pas dans TJ_EnfantRepas

[f-leb]

Quelle est la signification et le type des champs : sieste, propre, datefinsieste, datepropre ?

[jimbolion]

f-leb, desireles

Après l'Après-midi hier à St-Tropez , dans un gymnase , je reprends donc le fil de la discussion.

F-Leb, tu fais une excellente remarque sur l'utilisation de la clé #EnfantRepas_FK dans la table T-Releves. J'ai rapidement rectifié en assurant que tu avais raison (comment ai-je pu passer à côté). Le fonds du problème est plus complexe, et Desireles a mal retranscrit notre discussion (ou peut-être me suis mal exprimé ?).
Il est vrai que dans notre discussion nous avions élaboré une architecture, et en avançant dans la réflexion (Desireles reprends tes notes), il a été établi qu'un relevé serait effectué chaque semaine (la clé repas et la clé jour ne doivent donc pas être inscrite dans cette table). Ceci explique donc l'erreur de Desireles dans le modèle (j'ai mal relu et pas vu la faille effectivement).

Donc reprenons l'explication :

Un relevé est établi en début de semaine pour l'ensemble des repas pris par un enfant durant la semaine précédente. L'ensemble des repas pris par un enfant durant une période est fourni par les tables suivantes :

Tj_EnfantsRepas(identifiant, repas et jour) sachant qu'un enfant peut prendre de 1 à n repas (disons plutôt plat) par jour et la table T_Repas(identifiant, nom et prix).

La responsable en saisissant la période début et fin pourra donc établir la liste des repas pris par un enfant sur cette période. Cette requête sera filtrée par enfant, bornée par les dates avec un regroupement (somme) des repas pris sur la période. Quelque chose de très simple somme toute. Chaque ligne de la requête venant alimenté la table T_Releves avec donc les informations suivantes (Identifiant Relevé, Numéro du releve, Numero de la semaine, Montant global, Identifiant de l'enfant...) Donc si un enfant n'a pas pris de repas dans la période, la ligne ne ressortira pas.. Si un enfant n'a pris aucun repas, le relevé ne sera pas édité sur la période. Cette requête alimentera donc la table T_Releves (type Insert).

Le champ Calendrier_FK comme clé primaire servait juste à identifier la date d'impression du relevé (autant réutilisé la table des jours) mais dédoublonné avec la valeur DateImpression. Autant chosir la dateImpression dans le cas ou l'impression se fait un jour non scolarisé.
Donc l'erreur de Desireles (petite mais qui fait débat) est d'avoir crée une relation entre T_Repas et T_Releves sur la Clé ID_Repas <-> Repas_Fk (relation qui n'a pas lieu d'exister).

Ceci dit, en posant des questions, on doit prévoir le cas suivant : Peut-on imprimer un relevé sur deux semaines consécutives ? (imaginons une période de vacances avec un jour la semaine suivante). Pour cela t_releves accepte la période (DateDebut et DateFin).

Un rappel également, la table T_Paiements ne peut être en relation directe avec les relevés (les conditions de paiement n'étant pas liés directement à un relevé) à cause des versements successifs non rapprochables de certains parents (situation financière ou autre...). Le reste à verser sera donc calculé entre la somme des relevés et la somme des versements déjà perçus à l'instar d'un gestion de stocks (somme des Qtes entrées + stock initial - Qtes sorties). En réfléchissant un peu plus le modèle sur la partie relevés devrait ressembler à cela (pour parfaire le modèle on va rajouter un entête de Relevés évitant de redonder la date début et fin pour chaque élève). L'impression du relevé permettra d'afficher le détail des repas pris par chaque enfant sur la période, voire éventuellement un relevé global avec sous total pour les membres d'une fratrie (si souhaité).

En espérant que cela puisse être plus clair :

JimBo

[desireles]

Quelle est la signification et le type des champs : sieste, propre, datefinsieste, datepropre ?

c'est pour connaitre les enfants qui font ou pas encore la sieste et ceux qui ne nécessite plus une couche , car l'instit perd un temps fou pour cela et en cas de remplacement elle peut dès lors communiquer les infos de sa classe presicément à sa remplaçante , et le reste c est à titre informatif sur l'évolution de l'enfant pour son évaluation lors des réunions avec les parents