Gestion de notes d?élèves?
cestlogique
Membre
Hello!
ça fait un moment que ma petite feuille Excel bourrée de macros commence à me courir. La plupart des programmes de ce style sur le net sont pour PC et ceux pour mac ne me satisfont pas...
Bref, j'ai décidé de me lancer. Ma conception de la gestion des notes est calquée sur la vraie vie: un élève passe un certain temps dans un établissement et dans des classes de cet établissement dans lesquelles il obtient des notes, dans une ou plusieurs matières.
J'ai du mal à concevoir l'architecture que devra avoir la base de données: un élève pouvant parfaitement partir et revenir, ses notes doivent être conservées au fil du temps. On peut par ailleurs ne plus avoir un élève pendant un an mais avoir envie d'établir un graphique de sa progression tout au long des deux années (même discontinues) où on l'a eu.
Il faut donc qu'un élève soit propriétaire d'une série de notes correspondant à des devoirs, mais on doit aussi avoir un tableau de devoirs contenant les notes de tous les élèves l'ayant fait. L'élève doit-il contenir simplement la note et une référence au devoir auquel correspond la note ou les notes doivent-elles être conservées dans le tableau du devoir qui ne contient que des références vers les élèves?
Je suis un peu perdu: j'ai lu quelques articles sur SQL et la possibilité de créer des références croisées.
Merci pour vos conseils!
ça fait un moment que ma petite feuille Excel bourrée de macros commence à me courir. La plupart des programmes de ce style sur le net sont pour PC et ceux pour mac ne me satisfont pas...
Bref, j'ai décidé de me lancer. Ma conception de la gestion des notes est calquée sur la vraie vie: un élève passe un certain temps dans un établissement et dans des classes de cet établissement dans lesquelles il obtient des notes, dans une ou plusieurs matières.
J'ai du mal à concevoir l'architecture que devra avoir la base de données: un élève pouvant parfaitement partir et revenir, ses notes doivent être conservées au fil du temps. On peut par ailleurs ne plus avoir un élève pendant un an mais avoir envie d'établir un graphique de sa progression tout au long des deux années (même discontinues) où on l'a eu.
Il faut donc qu'un élève soit propriétaire d'une série de notes correspondant à des devoirs, mais on doit aussi avoir un tableau de devoirs contenant les notes de tous les élèves l'ayant fait. L'élève doit-il contenir simplement la note et une référence au devoir auquel correspond la note ou les notes doivent-elles être conservées dans le tableau du devoir qui ne contient que des références vers les élèves?
Je suis un peu perdu: j'ai lu quelques articles sur SQL et la possibilité de créer des références croisées.
- Quelle est selon-vous la meilleure technologie de bases de données, implémentable en Cocoa (sauvegardable en local et non sur un serveur)?
- Comment fonctionnent les référencements croisés? J'ai lu la doc d'SQLite mais
1) j'ai pas tout compris
2) je n'ai rien trouvé sur les références croisées ou foreign keys' - Quelle serait selon vous la meilleure architecture de données pour ce style de projet?
Merci pour vos conseils!
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Bonne idée ton programme, même si ça semble très flou encore.
Mon père est instit, et j'avais pensé un jour à p-e développer une petite appli au moins pour gérer facilement les notes des élèves et les bulletins. Je ne m'y suis pas encore attelé.
Pour les données, tu penses qu'une BDD est nécessaire ?
Je dirai que niveau "quantité d'infos" , plutôt non, mais pour faire des tris et des requètes plus compliquées, ça peut être pratique. A vrai dire, je ne sais pas jusqu'où on peut aller de ce côté là si on utilise pas de BDD mais que du XML ???
Si tu passes par une BDD, je te conseille MySQL, simple (enfin à notre niveau on fait pas des reqûetes de 10 km de long), et rapide. Pour les requêtes croisées, avec la clause WHERE, on fait déjà pas mal de dégats et ça devrait te suffir.
QUI dit MySQL, dit serveur local mysql, enfin, c'est rapide à installer... plus contraignant si tu veux distribuer ton appli.
Si tu attends un peu, tu auras tout prochainement droit au Framework cocoa MYSQL de Bru (ce w-e si tout va bien) qui permet de communiquer avec sql via Cocoa. Hein, je peux le dire Bru, hein ?!
Voilà , sur ce mon lit m'appelle en ce vendredi soir.
:adios!:
je suis de l'avis d'oxitan concernant l'utilisation d'une bdd. Est ce vraiment utile ou n'est pas plutot utiliser un marteau pilon pour écraser une mouche
A moins que tu veuilles t'exercer à Â l'utilisation de SQL dans une application cocoa.
Et pour ton souci d'analyse, je pense que le diagramme de classe doit être de 2 éléments: élève et devoirs. Note étant l'attribut d'un devoir. Tu pourras toujours faire une sélection des notes d'un élève via la sélection de ses devoirs.
En fait je ne tiens pas du tout à utiliser à tout prix une BDD.
Mais il y a deux problèmes: si j'ai un élève pendant plusieurs années, pour suivre ses résultats (et ne pas avoir à resaisir ses données personnelles) il doit rester dans un seul et même fichier et avec le jeux des redoublants on ne peut pas scinder le tout en périodes de 2 ou 4 ans. En fin de carrière, quand j'aurai 70 ansÂ
Deuxièmement, si les notes sont des objets d'un devoir, comment changer un élève de classe sans perdre ses notes? Il y a donc aussi un troisième élément: la classe.
J'abonne un élève à une classe, cette classe a une série de devoirs pour un certain trimestre, chaque élève a une note pour chaque devoir.
Les notes sont-elles stockées dans le devoir de la classe, ou dans l'élève sous forme de série? En respectant un ordre précis qui correspond à celui des devoirs c'est problématique si un devoir change de place ou disparaà®t, on peut alors utiliser un identifiant unique pour chaque devoir?
Bon je suis toujours aussi perdu!! Comment stockeriez-vous les données? Comment gérer ces données croisées en xml??
Merci pour toute suggestion!
Quelque soit le format de stockage que tu envisages il me semble que quatre tables sont envisageables:
- id de la classe (Unique)
- Nom de la classe
.../...
- id de l'élève (unique) (il peut y avoir des homonymes et un élève peut changer de nom ...)
- Nom
- Prénom
- id de sa classe
.../...
- id unique
- Titre du devoir
- Matière
- Date
- id De la Classe ayant fait ce devoir
- id du devoir noté
- id de l'élève
- note
Lorsque tu veux toutes les notes d'un élève tu cherches dans la tables des notes celles avec l'id de l'élève, tu retrouve au besoin dans la table des devoirs la date et la matière etc...
Lorsque tu veux les notes d'une classe tu cherches dans la table des devoirs ceux ayant l'id de la classe et pour chacun tu récupères dans la tables des notes celles ayant l'id du devoir.
Cette construction a néanmoins 2 gros défauts:
- elle n'historise pas la constitution des classes qui sont donc volatiles. Si tu veux garder en mémoire les élèves ayant appartenus à une classe donnée il y a 4 ans .../... pas glop
Il te faut une table de plus avec:
- id de l'élève
- id de la classe
- date d'entrée dans la classe
- date de sortie de la classe
Et puis ça dépend de ce que tu appèles classe: est-ce 5ème ? ou 5ème B de la saison 2004-2005 ?
Tu peux par exemple avoir une table des "Classes Génériques" genre 5ème:
- id de la classe générique
- non générique
Et une table des classes physiquement constituées
- id de la classe réelle
- id de la classe générique
Autre défaut de ma proposition de 4 classes:
Y'a des recoupements d'info mal venus à mon sens.
Tu peux récupérer les notes d'une classe en cherchant les notes des devoirs d'une classe ou en cherchant les notes des élèves de la classe ...
A mon sens c'est ici une fragilité inutile dans la cohérence des données mais bon c'est un premier jet et j'ai essayé de faire simple (comment ça ? ça se voit pas ? ;D )
Si tu as plus de détails sur tes besoins n'hésites pas à être plus précis, je penses facilement pouvoir te proposer plus compliquer ;D
Parce que, pour ce qui est du XML dans ce cas...
Voilà qui me donne de bonnes pistes. Cela fait germer quelques idées dans mon esprit.
Comme tu le dis, les recoupements d'info c'est pas génial, c'est pourquoi j'avais pensé à une BDD. Mais restons dans l'OO et raisonnons en termes de dictionnaires et de tableaux...
Tu proposes la classe d'un côté et l'élève avec id de sa classe de l'autre. Je verrais plutôt Classe avec id de ses élèves (on pourrait en ajouter ou en enlever à loisir) et à‰lève avec id de SES classes, toutes celles qu'il fréquentera au fil du temps.
Plutôt que de faire une table Devoirs et une table Notes, je verrais un objet Devoir, contenant un id unique et des propriétés comme id de la classe concernée, intitulé, date, coefficient... et un tableau d'objets Note. Chaque objet Note contient l'id d'un élève de la classe en question et la note proprement dite.
Avec Classe = groupe constitué pour une période donnée, par des élèves pouvant provenir de divisions différentes: ex. 4eBC regroupant en 2004-05 la moitié des 4eB avec le tiers des 4eC...
[tt]
CLASSES (array)
Classe1: (object)
uid: (string)
nom: (string)
autresPropriétés...
à‰lèves: (array) (ayant fait au moins 1 devoir)
uid: (string)
uid: (string)...
Périodes: (array)
Période1: (object)
numéro: (NSNumber)
intitulé: (string) ex. "1er Trimestre"
Devoirs: (array)
Devoir1: (object)
idClasse: (string) *
diversesPropriétés...
Notes: (array)
Note1: (object)
idà‰lève: (string)
note: (NSNumber)
Note2...
Classe2...
* Sûrement inutile si contenu dans l'objet classe correspondant.
à‰LàˆVES (array)
à‰lève1: (object)
uid: (string)
diversesPropriétés...
ClassesFréquentées: (array)
uid: (string)
entrée: (date) (modifié si arrivé en cours d'année)
sortie: (date) (modifié si parti en cours d'année)
à‰lève2...
[/tt]
Que penses-tu de cette structure? Est-ce viable? Y a-t-il des défauts cachés?
Pour ta proposition plus compliquée, n'hésite pas: je suis preneur aussi! 8)
Merci et à bientôt.
D'une façon générale une table incluse (un array dans un arrays) est "privée" à chaque élement de la table globale et ne permet donc pas les tris et sélections globales.
Pour ce qui est des tables incluses contenant des références uid sur les élèves celà implique tout de même que la table élèves existe idépendament non ? à ce moment ça peut coller. Tu récupère l'uid des élèves dans la table incluse de la classe puis retrouve son nom etc.. dans la table des élèves.
Mais comment fais tu si tu veux obtenir la liste des classes ou a été un élève donné ?
La structure table incluse empèche ici de remonter le lien dans l'autre sens.
Même remarque pour les devoirs si tu as besoin de savoir quelles classes ont proposé ce devoir à leurs élèves etc...
Pour en rester aux classes et aux élèves par exemple, tu gardes le maximum de flexibilité en gardant leur 2 tables séparées et en créant une troisième table totalement indépendantes contenant les références aux classes et aux élèves. De cette façon si tu veux savoir quels sont les élèves d'une classe tu recherche dans la "table des références" tous les enregistrements contenant l'uid de la classe et tu lis dans chacun l'uid des élèves.
Et si tu veux savoir à quelles classes à appartenu un élève tu recherche dans la "table des références" tous les enregistrement contenant l'uid de l'élève et tu lis dans chacun l'uid des classes.
Evidemment tu peux compliquer les choses en ajoutant par exemple une date de validité de chaque enregistrement de ta table des références. Comme ça tu peux filtrer l'appartenance à une classe dans n'importe quelle période ou au contraire sortir en un clin d'oeil tous les élèves ayant été dans cette classe lors des dernières années écoulées etc ...
C'est assez compliqué là ? ;D
En tout cas c'est à mon sens le type de structure qu'il faut penser dès le début sinon gare au casse tête si un utilisateur de demande d'implémenter des tris et recherches auxquels tu n'avais pas songé au départ
Tu as raison Oxitan, sql est plus adapté à mon sens aussi, mais en XML c'est faisable tout de même en extrayant chaque table à la lecture du document ...
Oui, c'est pour ça que j'ai donné aussi la structure de la table élèves qui contient des objets "élève".
Si, apparemment tu n'as pas du tout vu ma structure élèves: chaque élève a un tableaux Classes fréquentées qui contient les uid des classes.
Là , je crois que la question ne se pose pas, étant donné que chaque devoir est unique, une seule classe peut le proposer.
Là je te suis, c'est vrai qu'une table indépendante sera utile notamment pour les recherches.
Oui, c'est pour ça que je me renseigne avant. Je ne voudrais pas non plus être obligé de tout refaire en SQL par la suite, donc il va falloir que je me décide une bonne fois pour toutes.
Merci en tous cas du temps passé à me répondre ClicCool! ;D
Si j'avais vu, mais je pensais que tu présentais là 2 alternatives.
Faires coexister ces 2 référencements est, à mon sens, une erreur qui t'expose au mieux à des complications dans la maintenance des références et au pire à des incohérences dans tes références croisées.
Bref plus de complications et moins de sécurité qu'zn maintenant les tables indépendantes
Me revoici après quelques jours d'absence...
Sous quelle forme dois-je implémenter cette table? Un dictionnaire où je pourrai chercher par clef (uid de l'élève par exemple) ou bien par valeur (uid classe); ou alors un tableau d'objets persos, ou quoi? Quelle est la meilleure solution, notamment du point de vue de la rapidité de la recherche?
Sur le format de document: Je pense maintenir une base d'élèves indépendante et avoir ensuite un document par année scolaire. Est-ce trop contraignant pour l'utilisateur? (Nécessité d'avoir ces deux fichiers dans un seul dossier... Mais je pourrais les stocker en aveugle dans un sous dossier d'application support comme les fichiers Address Book par exemple.)
D'une manière générale, vaut-il mieux un flux encodé et décodé ou un format xml? Dans quels cas est-il judicieux de créer des documents bundles comme le rtfd ou les sauvegardes Address Book?
Quelles sont les trucs à savoir pour créer un format de fichier évolutif mais qui n'empêche pas la "backward compatibility"?
Désolé pour ce harcèlement de questions et merci à quiconque voudra bien me donner des pistes!!
perso je verrais chaque table en array de dictionnaires pour ce qui est des données à sauvegarder.
Mieux, un array d'objets persos contenant chacun le dico à sauvegarder plus des propriétés "volatiles" de gestion qui peuvent t'être utiles et pouvant elles même être dans un 2 ème dico.
Pour ce qui est de la rapidité de recherche, soit elle n'est pas fondamentale parce que les tables sont modestes soit il vaut mieux une base sql qui se chargera des recherches et tris.
Mais dans ce cas tu fais l'impasse sur les recherche-tris-comparaisons inter-années non?
Ne peut-il être utile de visualiser les résultats d'un élève, redoublant par exemple, sur plusieurs années ?
Dans la mesure du possible essaies de tenir le plus indépenante possible tes routines d'accès de recherche et tri de façon par exemple à pouvoir tout sauvegarder en html puis d'évoluer vers une base sql sans trop de réécriture.
En sql la compatibilité ascendante est quasi assurée.
Dans un format xml aussi du reste.
Tes problèmes de compatibilités par contre apparaà®trons dès que tu auras besoin de modifier la structure même des données en ajoutant un champs, modifiant un autre voire si tu as finalement besoin de "sortir" certaines données d'une table pour créer une toute nouvelle table
Je ne pense pas que je ferai souvent ce type de recherches, mais bien sûr pour les autres utilisateurs éventuels... La table élève contiendra la liste des classes fréquentées qu'on pourra alors ouvrir simultanément ou dans un présentation spéciale étudiée pour visualiser des comparaisons. On pourrait aussi mémoriser une simple moyenne annuelle directement dans l'élève pour pouvoir faire des bilans rapides sans avoir à extraire les données. J'ai aussi pensé à une fonction qui créerait une sorte de résumé par classes ou groupes et par années ou trimestres.
Je pense quand même garder les données de notes séparées par années de manière à alléger le tout et à limiter les risques de corruption ou de perte de données.
Merci encore pour les infos.
Mais bon, c'est pas en Cocoa.
Mais c'est compatible Windaube.
Merci pour cette piste que je ne connaissais pas. ça a l'air séduisant mais l'app de P. Freney ne gère pas les coefficients, par exemple, alors qu'elle a toutes sortes d'autres caractéristiques intéressantes mais peut-être moins fondamentales...
Je pense que j'ai vraiment envie de me faire ma propre app qui aura forcément tout ce que je recherche, même si ça risque de prendre du temps pour la réaliser. J'aimerais gérer les sous-matières, pouvoir conserver les sous-notes (par ex. 2 notes sur 10 qui ont donné une note sur 20...) et plein d'autres choses qui correspondent à ma pratique personnelle et donc difficiles à trouver réunies dans une app de tierce partie.
Le plus dur sera la gestion des données, mais surtout par la suite la gestion de l'impression, à laquelle je n'ai pas encore eu l'occasion de me mesurer: pouvoir imprimer des tableaux récpitulatifs un petit peu personnalisables en fonction des besoins...
Je suis en train de pondre la structure des données, je la posterai ensuite pour obtenir votre avis. Je pars sur du xml.
Alors là je te rejoint à 100%
Régulièrement des esprits chagrins me soulignent que j'aurait gagné à prendre du tout fait et, fauta avouer qu'au fil des ans ça me prends pas mal d'heures de travail.
Mais y'en a qui jouent aux jeux vidéos, d'autres qui brodent ou font des mots croidés ou des casse-têtes, moi c'est le code mon truc
Alors les heures passées dans une passion ça vaut bien les jeux résaux et c'est au bout du compte plus productif non ?
Et puis je n'ai jamais regrété et en plus la structure de mes tables reste fonctionnelle plus de 15 ans après leur création. Jamais je n'ai eu à revenir sur cette structure au fil de mes releases. (hors mis l'ajout d'une table ou d'un champ dans une table)
Pour ça je te recommande encore, cestlogique, de rester le plus ouvert possible dans tes choix de structure.
Pour ce qui est de commencer à travailler avec xml c'est tout bon. Ca ne t'empèchera pas de basculer sql au besoin plus tard.
En plus avec Tiger et XCode 2.0 une gestion des collections bien plus puissante (Cocoa Data Management et Core Data Concept et autres gateries indexation recherche dans du xml
Alors accroches toi cestlogique
Merci pour tes encouragements ClicCool!!
Mais, dis-nous, quelles sont les tables et applis que tu as créées? (Pure curiosité 8) )
22 Tables et jusqu'à plus de 50 000 enregistrements par table.Â
Les app de Freney ne sont que des exemples de ce que l'on peut faire avec 4D. Tu te fabriques toi-même ta propre appli.
Mais bon, je ne voudrais pas avoir l'air de faire de la concurrence à Cocoa ! >:D
Deux questions : lorsque j'ai commencé à utiliser Cocoa pour gérer et enregistrer des données, je les archivais en .plist, ce qui me permettait d'aller vérifier avec Property List Editor que tout fonctionnait bien.
Les .plist, c'est du xml ?
Les .plist, c'est vachement gourmand en ko, par rapport à un [NSArchiver archiveRootObject: maListe toFile: monFichier], non ?
Oui Tiff, les .plists sont au format .xml
Par contre je ne sais pas si c'est plus gourmand en taille que le format "wavelett bin" utilisé par la classe NSArchiver....
Mais il est vrai qu'il est bien plus facile de lire un fichier .xml dans le Property List Editor. Les fichiers .wbin utilisant un encodage particulier, il faut avoir au minimum le fichier d'interfaçage de la classe encodée, pour pouvoir décoder les objets contenus dans le .wbin
Ouah ! je faisais du wavelett bin sans le savoir ! :brule: D'où vient ce nom de format ?
De mémoire, les mêmes données prenaient environ 5 fois plus de place dans un .plist que dans un .wbin. Il m'est arrivé une seule fois de faire la comparaison. Par contre, à l'ouverture de l'appli, je ne sais pas quel est le plus rapide à charger.
Ben en faites c'est "wavelet" et pas "wavelett". J'ai découvert ça un jour, en faisant une demande d'info sur un fichier que j'avais généré avec NSArchiver, et en type c'était marqué Mac Wavelet Bin. Bon j'espère que je ne dis pas de bêtise, car je n'ai pas réussi à réitérer l'affichage de ce type dans les infos. Sinon le wavelet, c'est un format de compression extrêmement efficace utilisé en audio/vidéo. C'est un format plus efficace que le JPG, pour dire ! Apple a apparemment décliné cet algorithme pour sa classe NSArchiver.
Ce que je ne comprend pas, c'est que c'est un algorithme destiné à traiter des signaux, donc je vois pas le rapport avec les classes...Peut-être que finalement le Mac Wavelet Bin est une méthode bien particulière de compression pour NSArchiver...Si quelqu'un en sait plus là -dessus, qu'il fasse signe.
Voici un lien pour ceux que ca intéresse (attention vaut mieux être matheux)
http://electron.mit.edu/~gsteele/wavelets/
ça tombe bien
Super, des transformées de Fourier, ça me rappelle mon jeune temps.
Un énorme merci pour ce lien. :adios!:
[Edit]
Ce qui m'embête, c'est le "not necessary to reproduce the data exactly", alors que je m'en sers pour enregistrer des arrays de strings. Je suppose que l'archiver est capable d'assurer l'intégrité des données malgré la compression.
[Edit] Ah oui, au fait, wavelet veut dire vaguelette, ce qui a priori correpond plus à des signaux du type sinusoidal que numérique. Alors effectivement, où est le rapport avec les variables d'instances ?
Juste pour info, les "wavelet" (ondelettes en français) sont aussi utilisées en analyse de signal temp-fréquence, (Cependant cette analyse est beaucoup moins fréquente que la FFT et le tiers d'octave).
Voilà pour les infos qui n'ont pas grand chose à voir avec Cocoa :sors:
Génial! Et tu as réussi à porter le tout sous Cocoa? Au début, tu l?avais créé avec quoi?
Hélas non
J'ai commencé cette base sous 4d et à ce jour toutes mes tables n'ont pas encore migré sous Cocoa.
Certaines sont encore "emprisonnées" dans la structure 4D originale.
Et c'est justement ce pourquoi je quitte progressivement 4D. Les tables d'une base y sont encapsulées dans un seul fichier et le partage d'information d'une table est donc impossible à une autre application que celle qui exécute la base. C'est ce qui conduit l'appli et ses données à enfler démesurément au fur et à mesure qu'on veut exploiter les renseignements figurant déjà dans la base.
Par exemple il me fallait pouvoir gérer mes rendez vous en fonction des données du dossier patient (fréquence des controles nécessaires, habitudes horaires des patients, épuisement de leur stock de médicament prescrits, etc...) Et Paf voilà la base qui s'enrichi d'une table RdV-Actes.
Après j'ai voulu exploiter ces données pour automatiser ma comptabilité, et paff une table nomenclature en plus ...
Et toutes ces belles données appartiennent alors à mon appli 4D, pas moyen de les partager ! L'effet "boule de neige est garanti
Mon but est d'exploser mon appli "usine à gaz" et une séries d'appli partageant gentilment les mêmes tables. (genre appli de consultation, appli agenda, appli compta, appli Pharmaco etc ...) un peu comme mail sait tirer parti des données du carnet d'adresse.
En ce moment je m'attaque au "noyau dur" des dernières tables si intimement liées qu'il va me faloir les faire migrer toutes d'un coup.
Qui plus est ce sont les tables les plus vitales tant du point de vue valeur des données que du point de vue obligations légales de sauvegarde et encryptage.
C'est la plus grosse modification de mon informatisation depuis 15 ans
Le plus dur est la gestion des liens entre tables et surtout l'indexation que je ne sais pas faire
Je me donne encore 18 mois pour être totalement autonome et pouvoir me passer totalement de ma base 4D.
Et en primme je n'aurais plus à acheter la licence de mise à jour de 4d
Mais avec ce 4D il est impossible d'exporter les données brutes par exemple sous forme de fichier texte?
Mais les tables une fois exportées ont perdues leurs liens avec les tables non encore exportées.
Pour les tables souvent lues mais rarement modifiées ça va encore, je conserve un exemplaire sous 4D pour les fonctions internes ayant besoin de ses infos et le synchronise de temps en temps les contenus.
Jusqu'à une synchro par jour ça va c'est gérable.
Mais pour le "noyau dur" faudrait une synchro plusieurs disaines de fois par jour !
A moins de sortir le noyau dur d'un bloc, mais là ça représente beaucoup beaucoup de boulot pour écrire les softs devant les utiliser ... gérer les interfaces, gérer les données avec les champs autoIncrémentés, les contrôles d'intégrité référencielle, ... parfois j'ai l'impression d'essayer de réinventer la roue